

I get the appeal of things like Atom and VS Code and Sublime. I don't really try to convince people that vim is better than any other thing. Also, I work in Perl a lot, which also has similar conventions for searching and replacing (though it has a more powerful regex engine with somewhat better syntax, like being able to include comments and newlines), so again, it's a skill that translates reasonably well back and forth. It's doubly useful, to me, that whatever tricks like that I pick up can be done from scripts with little to no changes (vim has a few differences, such as being able to specify which lines to replace either by number or visually or from beginning or end of file, but the matching/replacing logic is very similar). vim has very sed-like search and replace, so UNIX command line skills translate back and forth.

So.yeah, I use Atom and VS Code mostly stock, with a few plugins. I'm sure it's possible, and maybe if I ever really switch off of vim, I'll figure it out.
How to use grep in editpad lite how to#
Like, I have no idea how to "change these two words, but only if it's at the end of a line, and keep the words in between them the same" in any editor other than vim. There are some things that are a little painful (I'm really comfortable with, for example, complex substitutions in vim, but not so much in other editors), but most of the time I don't need those features often enough to have it be a major impediment. I have spent enough time writing prose (and even coding) in more standard GUI editor environments that it doesn't feel unnatural to work in that way. It is inevitably an uncanny valley, where it's not quite right, and I spend more time context switching between "real vim" and "this sort of vim" than I would just doing things the way the editor was built. I never try to make vim keybindings work in a GUI editor. Nonetheless, Moore's law has given us a world in which even very, very, slow editors are Fast Enough(tm) for most of the work, most of the time. It used to be remarkably slower than VS Code, and now it seems to be only marginally slower (though both are among the slowest in this bunch of tests, so it's faint praise to say Atom is "almost as fast as VS Code"). Even on reasonable-sized files, I notice the speed difference, and sometimes Atom or VS Code do something pathological and end up making me wait an inordinate amount of time for it to sort itself out.Īlso, Atom has improved quite a bit. There's a lot to like about the new editors, but it's a pretty big tradeoff, IMHO. Speed is one of them (the bigger one is that nearly all of my testing happens on remote servers or headless VMs, so if I want to use an edit-test-commit cycle, which I nearly always do, vim is what I have). I end up defaulting back to vim, for a variety of reasons. I've been going back and forth between Atom, VS Code, and vim, for my programming for the past year, or so.

There's such a rush to get the new shiny thing, that sometimes we don't notice what we're giving up.
