After I learned about “ci” in vim I got hooked. All of the sudden replacing text in quotes became as simple as ci” and now I’m having a hard time to use other editors. Sometimes a little detail is all that it takes.
Just to clarify to others. In vim if you are on a word “c” starts a change and the next keystroke determines what will be changed. For example, “c$” removes text from where the cursor is to the end of the line.
Now what is new for me is vim has a concept of “inner text”. Such as things in quotes, or inbetween any two symmetric symbols. The text between those two things are the “inner text”.
For example, in this line, we want to change the “tag stuff” to “anything”.
<tag style="tag stuff">Stuff</tag>
Move the cursor anywhere between the quotes and type ci then a quote and you are left with
This is a good example of why to me learning vi is not worth the trouble. In my normal editor, which does things the normal way, and does not have weird modes that require pressing a key before you are allowed to start typing and about which there are no memes for how saving and quitting is hard, I would remove the stuff in the quotes by doing cmd-shift-space backspace. Yes, that technically is twice as many key presses as Vi. No, there is no circumstance where that would matter. Pretty much every neat Vi trick I see online is like “oh if you do xvC14; it will remove all characters up to the semicolon” and then I say, it takes a similar number of keystrokes in my editor, and I even get to see highlight before it completes, so I’m not typing into a void. I think the thing is just that people who like to go deep end up learning vi, but it turns out if you go deep in basically any editor there are ways to do the same sorts of things with a similar number of keystrokes.
There is not only the difference in the number of keystrokes but more importantly in ergonomics. In Vim I don’t need to hold 4 keys at once but I can achieve this by the usual flow of typing. Also things are coherent and mnemonic.
E.g. to change the text within the quotes I type ci”(change inner “) as the parent already explained. However this is only one tiny thing. You can do all the commands you use for “change(c)” with “delete(d)” or “yield(y)” and they behave the same way.
ci”: removes everything within the quotes and goes to insert mode
di”: deletes everything within the quotes
yi”: copies everything within the quotes
d3w, c3w, y3w would for example delete, replace or copy the next 3 words.
These are just the basics of Vim but they alone are so powerful that it’s absolutely worth to learn them.
And if you want to remove the delimiters too, you use ‘a’ instead of ‘i’ (I think the logic is that it’s a variation around ‘i’ like ‘a’ alone is).
Moreover, you are free to chose the pair of delimiters: “, ’, {}, (), [], and probably more. It even works when nested. And even with the nesting involves the same delimiter. foo(bar(“baz”)) and your cursor is on baz, then c2i) will let you change bar(“baz”) at once. You want visual mode stuff instead? Use v instead of c.
One difference is that if you are doing the same edit in lots of places in your editor you have to do the cmd-shift-space backspace in every one, while in vi you can tap a period which means “do it again!” And the “it” that you are doing can be pretty fancy, like “move to the next EOL and replace string A with string B.”
I would remove the stuff in the quotes by doing cmd-shift-space backspace
What is a command-shift-space? Does it always select stuff between quotes? What if you wanted everything inside parentheses instead?
and then I say, it takes a similar number of keystrokes in my editor, and I even get to see highlight before it completes, so I’m not typing into a void
You can do it that way in vim too if you’re unsure about what you want, it’s only one keypress more (instead of ci" you do vi"c; after the " and before the c the stuff you’re about replace will be highlighted). You’re not forced to fly blind. Hell, if your computer is less than 30 years old you can probably just use the mouse to select some stuff and press the delete key and that will work too.
The point isn’t to avoid those modes and build strength through self-flagellation; the point is to enable a new mode of working where something like “replace this string’s contents” or “replace this function parameter” become part of your muscle memory and you perform them with such facility that you don’t need feedback on what you’re about to do because you’ve already done it and typed in the new value faster than you can register visual feedback. Instead of breaking it into steps, you get feedback on whether the final result is right, and if it isn’t, you just bonk u, which doesn’t even require a modifier key, and get back to the previous state.
What if you wanted everything inside parentheses instead?
It is context sensitive and expands to the next context when you do it again.
Like I appreciate that vi works for other people but literally none of the examples I read ever make me think “I wish my editor did that”. It’s always “I know how I would do that in my editor. I’d just make a multiselection and then do X.” The really powerful stuff comes from using an LSP, which is orthogonal to the choice of editors.
In a similar way, if you want to change the actual tag contents from “Stuff” to something else:
<tag style="tag stuff">Stuff</tag>
you can use cit anywhere on the line (between the first < and the last >) to give you this (| is the cursor):
<tag style="tag stuff">|</tag>
Or yit to copy (yank) the tag contents, dit to delete them etc.. You can also use the at motion instead of the it motion to include the rest of the tag: yat will yank the entire tag <tag style="tag stuff">Stuff</tag>.
Note that this only works in supported filetypes, html, xml etc., where vim knows to parse markup tags.
For years I thought I was the only “fool” that uses a non-fancy text editor for everything (but especially programming), while my peers were using the latest IDE of the day… And if they aren’t using an IDE, then at least a featureful general purpose text editor like Sublime, Emacs, VI (clones), etc. (Although I think these, and especially Emacs, are actually IDE’s in their own right.)
Thus, it made me smile knowing that other people out there prefer to use nano (or something simpler like mcedit) as their preferred editor.
Apparently, and the reason why I think the article is still noteworthy today in 2022, the author of the article still uses nano as her editor, as can be seen from her latest article, because it seems the latest OSX just replaced the provided nano with pico…
I’ll end with a small quote from the article that I think summarizes the whole subject:
People look at me funny when they look over my shoulder and see it. I’m getting tired of explaining that yes, I found something that worked, and it still works for me. Now I’ve moved on to creating things with my tools, rather than just fixating on the tools themselves. Who cares how you do it if it works for you? Show me what you’ve done with it.
P.S.: Long ago I used to use mcedit as it seemed nicer than nano, but a few years ago I’ve written my own “simple” text editor, that I use since 2008. (Here is a link if someone is curious: sce.)
Authors of books often use ancient word processors, like WordStar or WordPerfect, because that’s what they’ve already spent the time learning. Sitting in front of their vintage computers using vintage word processors, they don’t have to think about their tools, and can focus 100% on actually writing (not that this seems to work very well for George R.R. Martin…)
Programming is much the same. If you’re most comfortable using a totally out of fashion editor, because that’s what you learned ages ago, don’t let anyone try to convince you to use anything else.
I was a vim user, then became an emacs user with evil mode, and I learned the ropes before I became a full time programmer. My colleagues are largely using vscode, but I don’t see any reason to switch, now that my setup is working great for me.
It works everywhere. VS Code’s remote extension doesn’t work on FreeBSD, definitely doesn’t work on FreeBSD/arm64, so I can’t use it for a large chunk of the development that I do. I don’t want to move between editors on a daily basis because it increases cognitive load and gives less spare brain for thinking about the code.
I have used it so much that the shortcuts that I use all of the time are completely ingrained.
The second is very much the sunk-cost fallacy. If I switched to an editor that could improve my productivity long term, then the fact that I’d probably have a few months of re-training my fingers is a relatively small cost. I’d happily switch to something better if it worked everywhere. The lack of an iOS version of something like VS Code makes me a bit nervous because most of the time I’m sitting in front of a physical computer, it’s running Windows, macOS, Android, or iOS and if I can’t install the editor on all of them then there’s a danger of needing to switch between them based on the device I’m using, but it doesn’t worry me too much because most of the time I’d want to use an iPad it would be for remote development and the browser-based version of VS Code is fine there. The limitations of the remote extension worry me a lot more because if it can’t even support FreeBSD (which, let’s be honest, is basically the same as Linux or macOS to the extent that a toolchain should care about) then there’s no chance that it will support whatever the next big thing is until long after it’s big.
I’d substitute cmake for make there. CMake might not be installed out of the box everywhere, but getting a CMake project to build on Windows is far less painful than trying to get make to work. POSIX Make is completely useless and so any non-trivial project tends to use vendor extensions. The bmake and gmake extensions are incompatible (Solaris Make, last I checked, did little beyond POSIX), so on any non-GNU platform you’re likely to need to install gmake as an optional extra anyway and at that point I’d rather have CMake and Ninja.
For what it’s worth, I wrote all four of my books in vim and typeset them using LaTeX. The publisher required me to send camera-ready PDFs (thank you crop package) and to match their in-house style as closely as possible (the only difficult bit of this was the layout of the copyright page) but then just skipped a load of the steps. Oh, and the really nice thing about doing it this way is that you give the copy editors and proof readers an immutable format so that they can’t make changes, they can just request changes and I have to review each one and apply it, so when they make a ‘correction’ that incorrectly changes the meaning I can ignore it.
They didn’t have a good process for going from PDF to HTML and so completely messed up the formatting of the ePub editions of the first one. After that, I restricted myself completely to semantic markup in the TeX and wrote a small tool that dumped it as XHTML with styles reflecting the semantics so that they could style it however they wanted (I used libclang to parse my examples, so the XHTML included things like class-name, local-variable, argument, and so on).
Charlie does all the writing himself. I know he’s tried out Scrivener and other tools on occasion. There’s a small group of volunteers who moderate his blog and provide technical support for various things, and a larger but still quite small group of beta-test readers.
If you’re most comfortable using a totally out of fashion editor, because that’s what you learned ages ago, don’t let anyone try to convince you to use anything else.
I don’t believe for many the reason to stick with a simpler editor is just due to convenience, or because they don’t want to learn new things.
For example I’ve started with the Turbo Pascal IDE, then switched to Visual Basic and Visual Studio C++ (both before .NET existed), then I’ve used Eclipse quite extensively for Java, and for some period even used the JetBrains IDE variant for Ruby, but I found that fiddling with them on each release, on each update, trying to navigate through the countless windows, pop-ups, menus, auto-complete, etc., took more time than what they were worth… (In fact from the early days of using Visual Studio I’ve disabled syntax highlighting and auto-complete, as I found them more distracting than useful.)
Thus I believe that for many the simplicity plays a key role. (At least for me it does.)
This reminded me that for years, I used the Turbo Pascal 3 editor (DOS text mode) to edit everything, including school english assignments. Took me a long time to switch to anything else, because it could launch in an eye-blink and understood the wordstar command set.
I’ve forgotten when nano fixed its bad behavior on long lines but it was after 2011. These days I never complain about people using nano, that’s 10000% cool by me.
I honestly like ed for “quick ssh sudo fix fix” stuff esp when I don’t have a working tramp setup in my emacs.
After I learned about “ci” in vim I got hooked. All of the sudden replacing text in quotes became as simple as ci” and now I’m having a hard time to use other editors. Sometimes a little detail is all that it takes.
This was extremely helpful thanks.
Just to clarify to others. In vim if you are on a word “c” starts a change and the next keystroke determines what will be changed. For example, “c$” removes text from where the cursor is to the end of the line.
Now what is new for me is vim has a concept of “inner text”. Such as things in quotes, or inbetween any two symmetric symbols. The text between those two things are the “inner text”.
For example, in this line, we want to change the “tag stuff” to “anything”.
Move the cursor anywhere between the quotes and type ci then a quote and you are left with
This is a good example of why to me learning vi is not worth the trouble. In my normal editor, which does things the normal way, and does not have weird modes that require pressing a key before you are allowed to start typing and about which there are no memes for how saving and quitting is hard, I would remove the stuff in the quotes by doing cmd-shift-space backspace. Yes, that technically is twice as many key presses as Vi. No, there is no circumstance where that would matter. Pretty much every neat Vi trick I see online is like “oh if you do xvC14; it will remove all characters up to the semicolon” and then I say, it takes a similar number of keystrokes in my editor, and I even get to see highlight before it completes, so I’m not typing into a void. I think the thing is just that people who like to go deep end up learning vi, but it turns out if you go deep in basically any editor there are ways to do the same sorts of things with a similar number of keystrokes.
There is not only the difference in the number of keystrokes but more importantly in ergonomics. In Vim I don’t need to hold 4 keys at once but I can achieve this by the usual flow of typing. Also things are coherent and mnemonic.
E.g. to change the text within the quotes I type ci”(change inner “) as the parent already explained. However this is only one tiny thing. You can do all the commands you use for “change(c)” with “delete(d)” or “yield(y)” and they behave the same way.
ci”: removes everything within the quotes and goes to insert mode di”: deletes everything within the quotes yi”: copies everything within the quotes
d3w, c3w, y3w would for example delete, replace or copy the next 3 words.
These are just the basics of Vim but they alone are so powerful that it’s absolutely worth to learn them.
Just a small correction; I think you meant “yank(y)” instead of “yield(y)”.
Haha yes thanks I really got confused :)
And if you want to remove the delimiters too, you use ‘a’ instead of ‘i’ (I think the logic is that it’s a variation around ‘i’ like ‘a’ alone is).
Moreover, you are free to chose the pair of delimiters: “, ’, {}, (), [], and probably more. It even works when nested. And even with the nesting involves the same delimiter. foo(bar(“baz”)) and your cursor is on baz, then c2i) will let you change bar(“baz”) at once. You want visual mode stuff instead? Use v instead of c.
This goes on for a long time.
One difference is that if you are doing the same edit in lots of places in your editor you have to do the cmd-shift-space backspace in every one, while in vi you can tap a period which means “do it again!” And the “it” that you are doing can be pretty fancy, like “move to the next EOL and replace string A with string B.”
Sublime Text: ctrl+f search, ctrl+alt+enter select all results, then type your replacement.
Yeah I just do CMD-D after selecting a line ending if I need to do something like that.
What is a command-shift-space? Does it always select stuff between quotes? What if you wanted everything inside parentheses instead?
You can do it that way in vim too if you’re unsure about what you want, it’s only one keypress more (instead of
ci"you dovi"c; after the"and before thecthe stuff you’re about replace will be highlighted). You’re not forced to fly blind. Hell, if your computer is less than 30 years old you can probably just use the mouse to select some stuff and press the delete key and that will work too.The point isn’t to avoid those modes and build strength through self-flagellation; the point is to enable a new mode of working where something like “replace this string’s contents” or “replace this function parameter” become part of your muscle memory and you perform them with such facility that you don’t need feedback on what you’re about to do because you’ve already done it and typed in the new value faster than you can register visual feedback. Instead of breaking it into steps, you get feedback on whether the final result is right, and if it isn’t, you just bonk
u, which doesn’t even require a modifier key, and get back to the previous state.It is context sensitive and expands to the next context when you do it again.
Like I appreciate that vi works for other people but literally none of the examples I read ever make me think “I wish my editor did that”. It’s always “I know how I would do that in my editor. I’d just make a multiselection and then do X.” The really powerful stuff comes from using an LSP, which is orthogonal to the choice of editors.
I do not disagree. For vim, as for your editor, the process is in both places somewhat complex.
Like you I feel I only want to learn one editor really well. So I choose the one which is installed by default on every system I touch.
For which I give up being able to preview what happens and some other niceties. Everything is a tradeoff in the end
In a similar way, if you want to change the actual tag contents from “Stuff” to something else:
you can use
citanywhere on the line (between the first<and the last>) to give you this (|is the cursor):Or
yitto copy (yank) the tag contents,ditto delete them etc.. You can also use theatmotion instead of theitmotion to include the rest of the tag:yatwill yank the entire tag<tag style="tag stuff">Stuff</tag>.Note that this only works in supported filetypes,
html,xmletc., where vim knows to parse markup tags.I really like that I keep stumbling on tidbits like this one that continue to improve my workflow even further.
For years I thought I was the only “fool” that uses a non-fancy text editor for everything (but especially programming), while my peers were using the latest IDE of the day… And if they aren’t using an IDE, then at least a featureful general purpose text editor like Sublime, Emacs, VI (clones), etc. (Although I think these, and especially Emacs, are actually IDE’s in their own right.)
Thus, it made me smile knowing that other people out there prefer to use
nano(or something simpler likemcedit) as their preferred editor.Apparently, and the reason why I think the article is still noteworthy today in 2022, the author of the article still uses
nanoas her editor, as can be seen from her latest article, because it seems the latest OSX just replaced the providednanowithpico…I’ll end with a small quote from the article that I think summarizes the whole subject:
P.S.: Long ago I used to use
mceditas it seemed nicer thannano, but a few years ago I’ve written my own “simple” text editor, that I use since 2008. (Here is a link if someone is curious: sce.)I still use joe to develop programs, even at work. I’ve been using it for 30 years at this point, so I no longer have to think about using it.
Authors of books often use ancient word processors, like WordStar or WordPerfect, because that’s what they’ve already spent the time learning. Sitting in front of their vintage computers using vintage word processors, they don’t have to think about their tools, and can focus 100% on actually writing (not that this seems to work very well for George R.R. Martin…)
Programming is much the same. If you’re most comfortable using a totally out of fashion editor, because that’s what you learned ages ago, don’t let anyone try to convince you to use anything else.
I was a vim user, then became an emacs user with evil mode, and I learned the ropes before I became a full time programmer. My colleagues are largely using vscode, but I don’t see any reason to switch, now that my setup is working great for me.
I still use vim for two reasons:
The second is very much the sunk-cost fallacy. If I switched to an editor that could improve my productivity long term, then the fact that I’d probably have a few months of re-training my fingers is a relatively small cost. I’d happily switch to something better if it worked everywhere. The lack of an iOS version of something like VS Code makes me a bit nervous because most of the time I’m sitting in front of a physical computer, it’s running Windows, macOS, Android, or iOS and if I can’t install the editor on all of them then there’s a danger of needing to switch between them based on the device I’m using, but it doesn’t worry me too much because most of the time I’d want to use an iPad it would be for remote development and the browser-based version of VS Code is fine there. The limitations of the remote extension worry me a lot more because if it can’t even support FreeBSD (which, let’s be honest, is basically the same as Linux or macOS to the extent that a toolchain should care about) then there’s no chance that it will support whatever the next big thing is until long after it’s big.
The more experienced I become, the more I value tool chains that are available everywhere and simple
Git pull ; vim ; make ; run
It is great to be able to deploy a simple fix this way
I feel make along with vim are unsung heros
I’d substitute cmake for make there. CMake might not be installed out of the box everywhere, but getting a CMake project to build on Windows is far less painful than trying to get make to work. POSIX Make is completely useless and so any non-trivial project tends to use vendor extensions. The bmake and gmake extensions are incompatible (Solaris Make, last I checked, did little beyond POSIX), so on any non-GNU platform you’re likely to need to install gmake as an optional extra anyway and at that point I’d rather have CMake and Ninja.
[Comment removed by author]
No doubt Martin uses whatever he likes when writing, but at least in the rest of the publishing chain Word is ubiquitous:
http://www.antipope.org/charlie/blog-static/2013/11/cmap-why-do-you-use-microsoft-.html
(Although I’m pretty user Martin has an actual staff while Stross is still very much a one-man show)
For what it’s worth, I wrote all four of my books in vim and typeset them using LaTeX. The publisher required me to send camera-ready PDFs (thank you crop package) and to match their in-house style as closely as possible (the only difficult bit of this was the layout of the copyright page) but then just skipped a load of the steps. Oh, and the really nice thing about doing it this way is that you give the copy editors and proof readers an immutable format so that they can’t make changes, they can just request changes and I have to review each one and apply it, so when they make a ‘correction’ that incorrectly changes the meaning I can ignore it.
They didn’t have a good process for going from PDF to HTML and so completely messed up the formatting of the ePub editions of the first one. After that, I restricted myself completely to semantic markup in the TeX and wrote a small tool that dumped it as XHTML with styles reflecting the semantics so that they could style it however they wanted (I used libclang to parse my examples, so the XHTML included things like class-name, local-variable, argument, and so on).
Charlie does all the writing himself. I know he’s tried out Scrivener and other tools on occasion. There’s a small group of volunteers who moderate his blog and provide technical support for various things, and a larger but still quite small group of beta-test readers.
I don’t believe for many the reason to stick with a simpler editor is just due to convenience, or because they don’t want to learn new things.
For example I’ve started with the Turbo Pascal IDE, then switched to Visual Basic and Visual Studio C++ (both before .NET existed), then I’ve used Eclipse quite extensively for Java, and for some period even used the JetBrains IDE variant for Ruby, but I found that fiddling with them on each release, on each update, trying to navigate through the countless windows, pop-ups, menus, auto-complete, etc., took more time than what they were worth… (In fact from the early days of using Visual Studio I’ve disabled syntax highlighting and auto-complete, as I found them more distracting than useful.)
Thus I believe that for many the simplicity plays a key role. (At least for me it does.)
This reminded me that for years, I used the Turbo Pascal 3 editor (DOS text mode) to edit everything, including school english assignments. Took me a long time to switch to anything else, because it could launch in an eye-blink and understood the wordstar command set.
I always go with nano when I’m on a remote machine. It’s easy, does the job and exists nearly everywhere.
Locally I can use Kate/VSCode what ever, and if requires sshfs-mount the remote site.
I’ve forgotten when nano fixed its bad behavior on long lines but it was after 2011. These days I never complain about people using nano, that’s 10000% cool by me.
I honestly like ed for “quick ssh sudo fix fix” stuff esp when I don’t have a working tramp setup in my emacs.