Re: [dev] Is there a text editor following the UNIX philosophy?
> 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 in your brain, so you think about reuse and safety. Literate programming has been a big win in my devops-ish world. Patrick
Re: [dev] Is there a text editor following the UNIX philosophy?
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 using it successfully for around 2 years now. It is minimal enough to have a small and understandable codebase (around 20k lines C code + some Lua iirc) and it doesn't implement unnecessary features. For example it doesn't implement window/tab management, for which you can use tmux. In its core functionality it's very similar to vim, the main difference being structural regular expressions taken from sam (a very simple and very powerful feature). Vis is also easy to combine with other programs - I've built an "IDE-like" experience by combining it with tmux (to manage buffers), nnn (for a window with the filesystem tree), Python/R interpreters for a read-eval-print loop etc. I don't see the benefit of delegating things like syntax highlighting to an external tool. It's a performance-critical functionality because it's called often and I'm pretty sure that piping large files back and forth would be slow (though I haven't tried). IMO vis strikes the perfect balance of being small and minimalist, but containing all the necessary features to be usable and efficient. Best regards, Maciej
Re: [dev] Is there a text editor following the UNIX philosophy?
> 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 screen-oriented version of ed. It can be helpful for certain editing tasks where visual feedback is wanted. Unrelated to ed, but for those who use emacs, I find mg[2] to be a productive, medium-weight editor (~15k LOC). I use the one that comes with OpenBSD. 1: https://github.com/screen-editor/se/
Re: [dev] Is there a text editor following the UNIX philosophy?
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-editing (particularly
> code-editing) workflows people have had success with which combine
> many small programs, rather than using a single monolith.
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.
For multiple changes of the same sort, though, sed is better. I write a draft
of the editing command, verify that it does what I want on standard output,
then repeat the command with it overwriting the file.
awk is nicer than sed at picking out parts of lines -- back references, in
regex-speak. For anything more than a one-line script, though, I prefer to
write something in C, but that just comes down to a question of familiarity.
Use Perl or Python, anything that you're comfortable with... but don't avoid
the right tool only because you haven't yet learned to use it comfortably. I've
tried using shell scripts for direct text manipulation -- that way lies madness
-- but collating utilities with the shell is the indispensable feature that
IDEs try to dispose of. That means learning how to use lots of utilities.
grep is better than any in-editor find tool I've used. Line numbers are the
bridge between grep and your editor of choice... between most utilities,
actually. 'find -exec grep' is better than any in-IDE find tool I've used. And
sed, of course, fills the role of replace.
An alias that runs { grep | tee tempfile } can be useful to automatically save
your searches to review later or iterate over, if repeating your search with {
grep > tempfile } is a bridge too far.
For codebases that use long lines, piping whatever to { cut -c 1 $(tput cols) }
can make all the difference.
For dumping text from my mind, I like ed. All of that chrome in visual editors
that makes it easy to figure out where you are? That's just distraction for
pure input. When done, most languages have language-specific formatting
utilities; or, just open in emacs (lisp/emacs seems better than regex/vim for
handling syntax) to clean up the visual bits, which can be scripted if you're
not looking for the full carpal-tunnel-syndrome experience.
I also like ed for commit messages. Since I perform editing in the terminal,
and since ed doesn't clear the terminal view, I can review what I've recently
done while writing about what I've recently done. Neat and nifty.
I want to use ed for complex document reviews, too: comparing code, checking
multiple sections, etc. For example, create four terminal windows. In three of
them, create a FIFO and cat it. In the fourth, open a file in ed -- and write
relevant sections to your FIFOs. But the hassle of setting them up, then the
mental overhead of tracking which is which has always been too much for me. A
someday/maybe project of mine is to write a front-end for ed that handles all
of this; basically, a macro editor/launcher, or what emacs started out as but
for visual arrangement. Heck, maybe forget the shell and code it into dwm...
hmm. A lightweight version of that is [ grep -> ed -> print given lines ],
which is similar to folding in other editors.
I've tried tags but never found those systems useful. grep is enough.
A common theme here: the way I use lots of utilities is slow, but it forces me
to evaluate similar search results and to remember locations, all of which
helps me understand and navigate a project after a bit of exposure.
For non-coding (e.g., fiction), I use the filesystem as an outliner. Use tree
to get a listing; edit chapters in chunks, then cat together for review;
maintain notes and research documents in another tree then 'ln -s' them where
relevant. Backup early and often; plain text makes this easy.
I don't do syntax highlighting. My brain might be different, but all those
colors are pretty and pleasing without being informative; they make me think I
understand more about the code than I actually do. Coding style is all that's
needed to quickly figure out what highlighting is supposed to convey. Again,
though, your mind might be different. And there is a 'cat'-like replacement
that does syntax highlighting, if slowly ... 'bat', maybe?
But mostly I just use vim, partly because most editing is fixing typos, but
also due to the difficulty of slowing down enough to learn to do things quickly.
Re: [dev] Is there a text editor following the UNIX philosophy?
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/ Daniel
Re: [dev] Is there a text editor following the UNIX philosophy?
> 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.
Re: [dev] Is there a text editor following the UNIX philosophy?
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-sitter is specficially what made me uninstall neovim and switch over to vanilla vim. - NRK
Re: [dev] Is there a text editor following the UNIX philosophy?
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 themselves. Being able to right-click a file reference (to redirect directly to a failing test, for example) is handy. It's kind of funny that they insist on using a GUI, but all of the windows are designed to render text and nothing else. I wonder whether a similarly designed program, with mouse chording replaced by customisable buttons?, and the acme windows replaced by terminals, would provide many of the gains with less weirdness. On Sat, Feb 12, 2022 at 2:30 PM Ethan Marshall wrote: > > > 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 precious time. > > When entering text, you keep your hands on the keyboard. I see no reason > why we should introduce yet another input device for simply editing or > transforming the text. This is why so many programs naturally gravitate > toward cursor-addressed, textual editing. vi is designed to keep your > fingers on the home row when moving the cursor, so touch typing is meant > to be easier. Not only is this a stroke of genius (something that I feel > Emacs never succeeded in), it also has wide, practical implications on > your editing of text. Why should I reach for a mouse to cut the previous > section of text when I can keep using the current input device? Rather > than moving my hands over an inch, instead I can not move them at all > and get the same result, the only requirement being that I press escape > first. > > The usual counter-argument for this is that the keyboard is an imperfect > device for this situation, as it was not designed for anything but > inputting characters. So - in theory - the time saved from using a > device meant for this purpose should be better. However, practice again > teaches us that this is not the case. Mice are the bane of most users' > lives when they are forced to use them for editing text. You have to > take your hand off the keyboard, move them to some arbitrary location, > correctly manoeuvre the mouse, move back to the initial position and > finally edit your text. After all this, you may have to repeat the > process to navigate to the end of the text. > > Even if the mouse were, in fact, the perfect time-saver that we are > told, it is not designed for such shortcuts and chording. The mouse has > three buttons. These were intended with three very clear purposes. The > keyboard usually has 104+ keys on it for usage in key shortcuts. The > mouse? Three. If we assume chording, a theoretical maximum of nine > shortcuts. However, to access them, you have to memorize a nonsensical > pattern of M1-M2 (Emacs style). Instead, to delete text in my silly, > inefficient visual editor, I just press d on my keyboard. > > This may just be me being a perfectionist who likes to edit back what he > has just written, or it may just be something that I feel personally > about mice, but I cannot understand why you would build an editor for > programmers which does not use keyboard bindings. > > I have tried acme and sam. Both have their benefits, and I like the some > of their ideas. I tried acme for equal to or greater than the amount of > time which I spent learning vi(m) - and I just cannot like it. > > Ethan >
Re: [dev] Is there a text editor following the UNIX philosophy?
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 where I want power, and one where I have no choice. 1) My editor. I spend all day in the editor. I want it to be very flexible. I use Emacs. But I don't use it to read mail or browse the web even though it can. 2) My shell. I use zsh. 3) I have to use chrome or firefox as a browser because of work related web based apps. I have no choice here, well no choice if I want to keep my job ;) I can get away with a less powerful shell as long as it has tab completion. Tab completion just saves so much time. Cheers, Sean
Re: [dev] Is there a text editor following the UNIX philosophy?
> 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 precious time. When entering text, you keep your hands on the keyboard. I see no reason why we should introduce yet another input device for simply editing or transforming the text. This is why so many programs naturally gravitate toward cursor-addressed, textual editing. vi is designed to keep your fingers on the home row when moving the cursor, so touch typing is meant to be easier. Not only is this a stroke of genius (something that I feel Emacs never succeeded in), it also has wide, practical implications on your editing of text. Why should I reach for a mouse to cut the previous section of text when I can keep using the current input device? Rather than moving my hands over an inch, instead I can not move them at all and get the same result, the only requirement being that I press escape first. The usual counter-argument for this is that the keyboard is an imperfect device for this situation, as it was not designed for anything but inputting characters. So - in theory - the time saved from using a device meant for this purpose should be better. However, practice again teaches us that this is not the case. Mice are the bane of most users' lives when they are forced to use them for editing text. You have to take your hand off the keyboard, move them to some arbitrary location, correctly manoeuvre the mouse, move back to the initial position and finally edit your text. After all this, you may have to repeat the process to navigate to the end of the text. Even if the mouse were, in fact, the perfect time-saver that we are told, it is not designed for such shortcuts and chording. The mouse has three buttons. These were intended with three very clear purposes. The keyboard usually has 104+ keys on it for usage in key shortcuts. The mouse? Three. If we assume chording, a theoretical maximum of nine shortcuts. However, to access them, you have to memorize a nonsensical pattern of M1-M2 (Emacs style). Instead, to delete text in my silly, inefficient visual editor, I just press d on my keyboard. This may just be me being a perfectionist who likes to edit back what he has just written, or it may just be something that I feel personally about mice, but I cannot understand why you would build an editor for programmers which does not use keyboard bindings. I have tried acme and sam. Both have their benefits, and I like the some of their ideas. I tried acme for equal to or greater than the amount of time which I spent learning vi(m) - and I just cannot like it. Ethan
Re: [dev] sfeed: RSS/Atom parser and reader
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 software. I have been using it
> for a while now and I really enjoy its flexibility. As a testament to
> how versatile sfeed is, let me share the little script that I use to
> browse my feeds [1]. It essentially just builds up on your example
>
> > #!/bin/sh
> > url=$(curl -s gopher://codemadness.org/0/atom.xml | \
> > sfeed | sfeed_plain | \
> > dmenu -l 35 -i | \
> > sed -n 's@^.* \([a-zA-Z]*://\)\(.*\)$@\1\2@p')
> > test -n "${url}" && $BROWSER "${url}"
>
> but it allows you to organize your feeds in folders and select the ones
> you want to see with dmenu (to be precise with a dmenu-based filepicker
> [2]). It then dynamically generates a sfeedrc file to show you only
> those feeds.
>
> [1] https://sebastiano.tronto.net/git/scripts/file/sfeed-browser.html
> [2] https://sebastiano.tronto.net/git/scripts/file/dmenu-filepicker.html
>
> Best,
> Sebastiano
>
Hi Sebastiano,
Thanks for sharing the example, I'm glad its useful to others and its flexible
to change to your liking :)
--
Kind regards,
Hiltjo
Re: [dev] Is there a text editor following the UNIX philosophy?
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 highlighting, a program for > completion, a facility for dispatching text to shell commands, and so > on. On the more extreme end one could even imagine separating the jobs > of navigating through a buffer (i.e. a pager) from the editing of > text. Obviously that's not a complete idea by itself, or I wouldn't be > asking for suggestions. The question of "Unix philosophy" is more nuanced than that, it should be applied in an sensible manner. It just isn't practical to bring the scope which the "thing" that "programs do well" belongs to, down to such a fundamental level as navigating through a buffer. Those buffers are better manipulated as internal structures inside a single program, rather than some (textual) representation in an input/output stream. What should and can be avoided though, are for example plugins. A text editor doesn't need plugins, it should be sufficient for its purpose. Customization could be instead implemented through patches, as in other suckless programs. A text editor should do "its thing" well, nothing more, nothing less. "Its thing" should be editing of text files. signature.asc Description: PGP signature
Re: [dev] Is there a text editor following the UNIX philosophy?
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 buffer through sed rather than a custom implemented search-and-replace utility is really interesting. Ditto spell checking. Compared with a vim-like editor, navigating through a buffer seems much more painful - but perhaps I haven't found the right strategy yet. The lack of syntax highlighting, and the ugly GUI (which can't be run in console mode) are unfortunate. About syntax highlighting in particular, my naive suggestion would be to constantly pipe the input file/buffer through a program which decorates it with appropriate ANSI colour codes, which could then be interpreted by your preferred reader. This sounds absurd in terms of performance, but I don't understand how implemented syntax highlighters do anything different - presumably new tokens can make pretty much arbitrary changes to the underlying syntax tree, and yet vim (for example) will re-highlight an entire file quite happily. Regarding "can this be done" - I can't be sure. But for "is this even useful" - surely yes? I happen to have syntax highlighting in my text editor. Why not in my shell/terminal/pager? Why should they implement them differently? I happen to have tab completion in bash, and with a vim plugin. Why are they unconnected? For what it's worth (I know this is not particularly fashionable) - I'm much more interested in separating separable features than implementing the same feature set in less code. You may be right that these are not really separable features, but if they *are* separable, then it's not persuasive to me that they can be implemented in a small number of lines. All the best, Dan
