It’s hard for me to imagine making a transition like this by choice. I know ed pretty well, but that’s because I’m an old school sysadmin and back in the day being comfortable with line editing was the ONLY way you could rescue ailing systems sometimes when curses or some wacky termcap/terminfo wrinkle was raining on your parade and you needed to edit some critical config file to get the system booting again.
That aside, why not ex? It represents the same kind of line editing features as ed, but offers a seamless real time upgrade path for when you’re sick of punishing yourself and just want to get some actual editing done? :)
I’m really under the impression of reading “from Vim to Notepad”, where the author only states that “Vim has too many features (?), so using notepad is better, hey, I even adjusted my workflow to accommodate for the lack of features!”.
I don’t understand. Why not just use vim with the limited set of features you know?
Solid case of procrastination. Developers get bored like anyone else. When the thing they are working on gets boring, they may compensate with something that feels personal, their editor, workflow, window manager…
It’s a healthy behavior to some degree.
A hour spent automating a two hour worth of repetitive tasks is great. Two hours would be okay.
I would worry a bit if a developer in my teams wouldn’t even try or decided to spend a year in ed.
I agree, to me, to do a comparison with tennis, it’s a bit like saying that forbidding you to run to catch the ball, you need to get much better at predicting your opponents moves. OK, that’s an exercise, why not, but we can’t say it makes you better at playing tennis, you’re better at predicting, but you should still use vim^W^Wrun while you play tennis.
I wanted to use an editor that didn’t have features that were constantly distracting me from what’s important: writing code.
This is exactly why I stopped using Vim too. In my case the “features” often had to do with color schemes and other stuff that my perfectionist brain couldn’t put down despite knowing they weren’t a value-add.
One of my favorite revelations/changes in my time using vim is to pick a color scheme that colored no syntax. The one I have now only changes the colors on string literals and comments. Getting rid of the unicorn vomit has resulted in vim being a lot less distracting for me.
DISCLAIMER: I’ve done very little testing on it outside of my own system, so it may require some tweaking to get it working, I had to play around with the background color so it worked in my xterm with and without reverseVideo on (I like to toggle between them). I don’t think it works in gVim or MacVim. Hell, it may only work in neovim on OpenBSD for all I know.
If you want something more reliable, then I would highly recommend acme-colors, which I based my scheme on.
I wanted to use an editor that didn’t have features that were constantly distracting me from what’s important: writing code.
The distraction is a discipline issue, not a tooling issue. Using worse (ed is measurably worse than vim in almost every way) tools just reduces your productivity while simultaneously missing an attempt to improve your discipline (which is useful in every area of life).
Trying to optimize your environment to reduce distractions seems like a useful life tip. Most people who are addicted to YouTube, Facebook, or cigarettes can’t just use self discipline and sheer willpower to stop. Actively removing the source of the problem is a great way to handle the problem.
…the difference being that all of those things actively make your life worse in addition to being distracting, in contrast to vim’s features making you more productive - not to mention that the difference in magnitudes of the distractions are massive. Resisting the desire to spend all of your time learning new vim features is completely and categorically different than trying to stop smoking.
Also, vim features don’t come to you via some sort of Clippy-like assistant. You have to actively seek them out.
If you’re in a state where you can’t resist that, then not only are you likely having discipline issues with much more serious things (such as with eating and exercising - both of which are extremely important), but this “solution” would dictate that you also change your choice of programming language to something very simple with few features (e.g. Lua or BASIC) to “focus on what’s important”.
You might have heard of kakoune and how it’s a bit like vim, except that verb and object are reversed. One interesting and rarely-mentioned consequence is that you can do manipulation that is very close to what is described in the structural regexp document.
Consider this hypothetical structural regex y/".*"/ y/’.*’/ x/[a-zA-Z0-9]+/ g/n/ v/../ c/num/ that they describe. Put simply, it is supposed to change each variable named n into num while being careful not to do so in strings (in \n for example).
This exact processing can be done interactively in kakoune with the following key sequence:
S".*"<ret>S'.*'<ret>s[a-z-A-Z0-9]+<ret><a-k>n<ret><a-K>..<ret>cnum<esc>
It looks cryptic, but it’s a sequence of the following operations:
S".*"<ret> : split the current selection into multiple, such that the patterns ".*" are not selected anymore
S'.*'<ret> : same, but with '.*'
s[a-z-A-Z0-9]+<ret> : select all alphanumeric words from the current selections
<a-k>n<ret> : keep only the selections that contain a n
<a-K>..<ret> : exclude all selections that contain 2 or more characters
cnum<esc> : replace each selection with num
And the nice thing about being interactive is that you don’t have to think up the entire command at once. You can simply do it progressively and see that your selections are narrowing down to exactly what you want to change.
kakoune is definitely the best replacement to vim I’ve seen so far. But I enjoy the advantages of IDEs too much to switch (things like autocomplete, goto definition, catching errors while I type, etc.)
Hopefully the Dance extension to vscode will become stable over time, and I can give it another shot.
I wish for something that has the object/verb ordering that kakoune does, but with the same plugins that vim does. I tried kakoune for a week and loved using it, but my workflow was broken and I found it was taking me a lot longer to get productive again as I tried finding some replacements for plugins I depend on in vim (and either not finding anything, or often finding a broken/incomplete alternative).
Here’s a short list of the plugins I use the most, losely in order of how much I depend on them
deoplete (better [IMHO] autocomplete)
ale (linting)
fzf.vim (lots of integration with fzf)
vimwiki (formatted note taking/organization)
gitgutter (indicate changed/new/deleted lines not staged/committed)
colorizer (changes hex text color codes to match the color they represent)
file-beagle (nice file browsing within vim)
indentline (I write a lot of python, visual indication of indention helps during long sessions)
I don’t recall which plugins I wasn’t able to find replacements for in kak.. I should give it another go soon since I really do like kak’s philosophy with object/verb.
vim + plugins all the way, since I can run that setup basically anywhere (e.g. headless remote systems, etc). I also conditionally enable some plugins based on the file type I am editing.
If anyone is interested in an updated version of sam, here ya go. Sadly I haven’t been able to give it the time it deserves lately, but it works well enough.
I like ed because for small edits the session usefully appears in my terminal scroll-back, unlike software that uses a visual screen approach. Also because of the looks it garners from younger (or perhaps merely less eccentric) engineers.
I always had some interest for the UX around line editors since I discovered ed. When I had to work with notebooks (Jupyter & Co.), I wished than each cell would be a mini-line editor.
I found it very appealing without knowing why. Maybe it is the fact that all your editing history is in front of you. Maybe it is just that it feels so weird with our big screens now. I just feel that their is an experience to extract from them that did not percolate to the more modern visual editor. I can’t pinpoint exactly what yet.
Back in ‘17 I used ed(1) for a few months at work. It was inconvenient, because I was dealing with an unfamiliar codebase, but it was a very fun experience. I set about writing one in assembler mid last year but never finished it, because I realised my line iteration function wasn’t going to work. I did manage to get: file loading, auxv parsing, line buffering (linked list mapped to a resizable buffer of lines).
It’s hard for me to imagine making a transition like this by choice. I know ed pretty well, but that’s because I’m an old school sysadmin and back in the day being comfortable with line editing was the ONLY way you could rescue ailing systems sometimes when curses or some wacky termcap/terminfo wrinkle was raining on your parade and you needed to edit some critical config file to get the system booting again.
That aside, why not ex? It represents the same kind of line editing features as ed, but offers a seamless real time upgrade path for when you’re sick of punishing yourself and just want to get some actual editing done? :)
I’m really under the impression of reading “from Vim to Notepad”, where the author only states that “Vim has too many features (?), so using notepad is better, hey, I even adjusted my workflow to accommodate for the lack of features!”.
I don’t understand. Why not just use vim with the limited set of features you know?
Solid case of procrastination. Developers get bored like anyone else. When the thing they are working on gets boring, they may compensate with something that feels personal, their editor, workflow, window manager…
It’s a healthy behavior to some degree. A hour spent automating a two hour worth of repetitive tasks is great. Two hours would be okay. I would worry a bit if a developer in my teams wouldn’t even try or decided to spend a year in ed.
I agree, to me, to do a comparison with tennis, it’s a bit like saying that forbidding you to run to catch the ball, you need to get much better at predicting your opponents moves. OK, that’s an exercise, why not, but we can’t say it makes you better at playing tennis, you’re better at predicting, but you should still use vim^W^Wrun while you play tennis.
This is exactly why I stopped using Vim too. In my case the “features” often had to do with color schemes and other stuff that my perfectionist brain couldn’t put down despite knowing they weren’t a value-add.
One of my favorite revelations/changes in my time using vim is to pick a color scheme that colored no syntax. The one I have now only changes the colors on string literals and comments. Getting rid of the unicorn vomit has resulted in vim being a lot less distracting for me.
Yes! I turned syntax highlighting off completely before I stopped using Vim and my current, preferred editor doesn’t even support it.
Which vim colour scheme are you using? I would really like to try this
I made plaintext a “colourless” scheme for vim.
DISCLAIMER: I’ve done very little testing on it outside of my own system, so it may require some tweaking to get it working, I had to play around with the background color so it worked in my xterm with and without reverseVideo on (I like to toggle between them). I don’t think it works in gVim or MacVim. Hell, it may only work in neovim on OpenBSD for all I know.
If you want something more reliable, then I would highly recommend acme-colors, which I based my scheme on.
This is truly amazing. It’s really pretty to look at and feels nice to read. Thank you for making this.
I use nofrils for the reason mentioned above.
Nice thank you!
I use this one: https://github.com/andreypopp/vim-colors-plain
Thanks!
The distraction is a discipline issue, not a tooling issue. Using worse (ed is measurably worse than vim in almost every way) tools just reduces your productivity while simultaneously missing an attempt to improve your discipline (which is useful in every area of life).
Trying to optimize your environment to reduce distractions seems like a useful life tip. Most people who are addicted to YouTube, Facebook, or cigarettes can’t just use self discipline and sheer willpower to stop. Actively removing the source of the problem is a great way to handle the problem.
…the difference being that all of those things actively make your life worse in addition to being distracting, in contrast to vim’s features making you more productive - not to mention that the difference in magnitudes of the distractions are massive. Resisting the desire to spend all of your time learning new vim features is completely and categorically different than trying to stop smoking.
Also, vim features don’t come to you via some sort of Clippy-like assistant. You have to actively seek them out.
If you’re in a state where you can’t resist that, then not only are you likely having discipline issues with much more serious things (such as with eating and exercising - both of which are extremely important), but this “solution” would dictate that you also change your choice of programming language to something very simple with few features (e.g. Lua or BASIC) to “focus on what’s important”.
I did this once, but with sam
It didn’t really stick, but structural regular expressions almost kept me around.
You might have heard of kakoune and how it’s a bit like vim, except that verb and object are reversed. One interesting and rarely-mentioned consequence is that you can do manipulation that is very close to what is described in the structural regexp document.
Consider this hypothetical structural regex
y/".*"/ y/’.*’/ x/[a-zA-Z0-9]+/ g/n/ v/../ c/num/that they describe. Put simply, it is supposed to change each variable namednintonumwhile being careful not to do so in strings (in\nfor example).This exact processing can be done interactively in kakoune with the following key sequence:
S".*"<ret>S'.*'<ret>s[a-z-A-Z0-9]+<ret><a-k>n<ret><a-K>..<ret>cnum<esc>It looks cryptic, but it’s a sequence of the following operations:
S".*"<ret>: split the current selection into multiple, such that the patterns".*"are not selected anymoreS'.*'<ret>: same, but with'.*'s[a-z-A-Z0-9]+<ret>: select all alphanumeric words from the current selections<a-k>n<ret>: keep only the selections that contain an<a-K>..<ret>: exclude all selections that contain 2 or more characterscnum<esc>: replace each selection withnumAnd the nice thing about being interactive is that you don’t have to think up the entire command at once. You can simply do it progressively and see that your selections are narrowing down to exactly what you want to change.
There’s also vis, which explicitly sets out to support structured regex.
I can vouch for vis, I use it. Great editor!
kakoune is definitely the best replacement to vim I’ve seen so far. But I enjoy the advantages of IDEs too much to switch (things like autocomplete, goto definition, catching errors while I type, etc.)
Hopefully the Dance extension to vscode will become stable over time, and I can give it another shot.
Kakoune has a pretty slick LSP plugin if the languages you work with have language servers available.
FWIW I just spent a whole hour trying to install it on Linux and failed. And let’s say I’m not exactly a noob.
To constrast, it took me only 10 mins to get it to work on neovim, and I’m equally unfamiliar with its ecosystem.
Everything you described is available in Neovim’s built-in LSP client or in one of the many LSP plugins for Vim.
I’m not sure I get it. Neovim has a kakoune mode?
I was referring to the “advantages of IDEs” (autocomplete, goto, diagnostics, renaming, documentation, etc.)
I wish for something that has the object/verb ordering that kakoune does, but with the same plugins that vim does. I tried kakoune for a week and loved using it, but my workflow was broken and I found it was taking me a lot longer to get productive again as I tried finding some replacements for plugins I depend on in vim (and either not finding anything, or often finding a broken/incomplete alternative).
Really curious now what vim plugins you use? I’ve never tried any plugins, so not sure what they can add
Here’s a short list of the plugins I use the most, losely in order of how much I depend on them
deoplete (better [IMHO] autocomplete)
ale (linting)
fzf.vim (lots of integration with fzf)
vimwiki (formatted note taking/organization)
gitgutter (indicate changed/new/deleted lines not staged/committed)
colorizer (changes hex text color codes to match the color they represent)
file-beagle (nice file browsing within vim)
indentline (I write a lot of python, visual indication of indention helps during long sessions)
I don’t recall which plugins I wasn’t able to find replacements for in kak.. I should give it another go soon since I really do like kak’s philosophy with object/verb.
Interesting. Quite a few of those seem almost like adding IDE features to vim. Curious on your take on vim+plugins vs IDE with vi mode?
vim + plugins all the way, since I can run that setup basically anywhere (e.g. headless remote systems, etc). I also conditionally enable some plugins based on the file type I am editing.
If anyone is interested in an updated version of sam, here ya go. Sadly I haven’t been able to give it the time it deserves lately, but it works well enough.
https://www.gnu.org/fun/jokes/ed-msg.html
Glad to see there are other “ed heads” out there.
Good article. I wish more time was spent on the ed-specific tricks that the author found, and what’s easy in ed but harder in vim.
I like
edbecause for small edits the session usefully appears in my terminal scroll-back, unlike software that uses a visual screen approach. Also because of the looks it garners from younger (or perhaps merely less eccentric) engineers.I always had some interest for the UX around line editors since I discovered ed. When I had to work with notebooks (Jupyter & Co.), I wished than each cell would be a mini-line editor.
I found it very appealing without knowing why. Maybe it is the fact that all your editing history is in front of you. Maybe it is just that it feels so weird with our big screens now. I just feel that their is an experience to extract from them that did not percolate to the more modern visual editor. I can’t pinpoint exactly what yet.
I switched to vi from vim, and feel a lot of similar energy. No visual mode makes you lean more heavily on regex for one.
Back in ‘17 I used ed(1) for a few months at work. It was inconvenient, because I was dealing with an unfamiliar codebase, but it was a very fun experience. I set about writing one in assembler mid last year but never finished it, because I realised my line iteration function wasn’t going to work. I did manage to get: file loading, auxv parsing, line buffering (linked list mapped to a resizable buffer of lines).