> I can get away with a less powerful shell as long as it has tab
> completion. Tab completion just saves so much time.
Directly typing into a shell is a red flag. ie. a shell is just another REPL
and should be driven by your editor.
This a) documents your work, and b) toggles the developer bit
On lut 11 11:47, Daniel Littlewood wrote:
> I wonder whether there are any text-editing (particularly
> code-editing) workflows people have had success with which combine
> many small programs, rather than using a single monolith.
I highly recommend vis (https://github.com/martanne/vis). I've been
> Jonathan Bakke wrote:
> Daniel Littlewood wrote:
> > From the other end, there is always ed.
>
> I use ed. Each tool is specialized, though.
>
> I prefer vi-like editing for fixing typos. Having visual feedback
> drastically reduces errors from commands like sed.
You might like se[1]. It's a s
On Fri, Feb 11, 2022 at 3:47 AM, Daniel Littlewood
wrote:
> ...
> From the other end, there is always ed.
> Unfortunately I don't have much experience with it, and it's not often
> discussed, so I can't tell whether it could do the "integration" step.
>
> I wonder whether there are any text-edi
pt., 11 lut 2022 o 12:56 Daniel Littlewood
napisał(a):
>
> Hi all,
>
> I wonder whether there are any text-editing (particularly
> code-editing) workflows people have had success with which combine
> many small programs, rather than using a single monolith.
Here you go:
https://c9x.me/edit/
Dan
> The dependancy on tree-sitter is specficially what made me uninstall neovim
> and switch over to vanilla vim.
You can use the same syntax files you use with Vim on Neovim; you don't have to
use tree-sitter. There is no dependancy.
Hi,
AFAIK, neovim is trying to offload some of it's stuff
(autocomplete/linting) to a language server via LSP. They're also
offloading syntax highlighting to tree-sitter.
But I highly doubt that this is what you're looking for when you're
talking about a "unix-like" editor. The dependancy on tree
My impression so far with acme is that it fills the "IDE" gap much
more than the "text editor" gap. I watched a screencast by Russ Cox
(https://www.youtube.com/watch?v=dP1xVpMPn8M) and the appealing
features were mostly around co-ordination of windows rather than the
contents of the windows themsel
On Fri, 11 Feb 2022 11:47:56 +
Daniel Littlewood wrote:
> I wonder whether there are any text-editing (particularly
> code-editing) workflows people have had success with which combine
> many small programs, rather than using a single monolith.
On development machines there are two places wh
> Acme looks extremely neat. Mouse
> chording is a strange concept (which doesn't play nicely with my
> laptop mouse)
This is something that I fundamentally disagree with the designers of
acme on, actually. I think that mouse "chording" or mouse-based
shortcuts of any kind are slow and wasteful of
On Fri, Feb 11, 2022 at 03:26:12PM +0100, Sebastiano Tronto wrote:
> Hello,
>
> > I would like to share my project I've been using and tweaking over the
> > years:
> >
> > sfeed is a RSS and Atom parser (and it has some format programs).
> > [...]
>
> Thank you Hiltjo for this nice piece of sof
On 22/02/11 11:47, Daniel Littlewood wrote:
> It seems to me like the obvious alternative workflow would be, rather
> than to have a single monolithic program for the general job of
> "editing text" (which is really lots of jobs pretending to be one),
> one might have a program for syntax highlight
Thanks for the suggestions everyone. Acme looks extremely neat. Mouse
chording is a strange concept (which doesn't play nicely with my
laptop mouse), but the idea of building an IDE around customised short
shell commands is really appealing. As for text editing specifically,
the idea of piping a bu
13 matches
Mail list logo
