I read things like this occasionally and still don't really get why? Why is the learning curve worth it?
I read things like this occasionally and still don't really get why? Why is the learning curve worth it?
> Easiest way to think of it is to think of how frustrating it is watching someone do everything with a mouse, not knowing any shortcuts. Clicking File -> Exit instead of the window's X. Or deleting a whole line of text just to change one word. Not knowing Ctrl-X/C/V.
Vim(and I guess emacs) are another layer on top of that.
I have had to do a little with Visual Studio in the past, and I feel like you spend more time learning the IDE than you do learning to code. I think I will stick with Atom and leave Vim, Emacs et al to the full timers!
Suppose you want to move a few lines of code from one function to another in a regular GUI text editor. If you select these lines with a mouse you need to be careful about exactly where you click to start highlighting and where you end highlighting. Do you start from the beginning of the first line or from the end of the previous line? Do you include the new line at the end? (Can you even?) Then, when you paste, where do you paste? Do you just put the cursor on the line you want to paste before and paste? Or do you put the cursor at the end of the line you want to paste after, hit enter and then paste? Oops, you did it wrong and now this the first line isn't indented at all, or now you have two lines of code on one line.
After a while you figure out where you need start and end the selection, and where you need to paste, but it's still easy to mess up.
This isn't an issue in vim. Using Visual Line mode selecting and pasting is super simple. 'V' to enter visual line mode, 'j' and 'k' to highlight everything you want (and 'o' to switch which end of block you're moving!), 'y' to yank (copy) or 'd' to delete. Then put the cursor _anywhere on the line_ that you want to paste after and hit 'p'.
The ease of use is one thing, but I also think it makes more sense to have an entire line be a fundamental unit. When you're editing code, you're usually moving codes around or editing single lines. I rarely copy and paste just one part of a line to another, and I think in most cases it's easier to just paste the line and change the parts I don't want.
Then, Vim automation (like doing a search/replace) seems more straightforward
It's also useful when vim is all you have (remote systems or if your X server became borked)
But Atom is fine and you shouldn't worry about it
some people don't care about those things, some people do.
However I did give vim a try eventually and use it now exclusively, but the reason I like it is comfort. Navigating around and doing operations is sooo much more comfortable now that I don't have to use a mouse or repeated key presses, plus all the many helpful shortcuts it has.
So it has keyboard shortcuts, and I guess I could add those to another editor...
Is it one of those things you just have to take someones word for it, have a go with it and see?
For example, in another editor you might have ctrl-K to delete a line (dd in vim) , but what about deleting 4 lines? in vim, it's 4dd.
Or you might want to delete from the start of a block to the end... The motion for block in vim is %, so to delete a block, you'd do "d%". Similarly, deletion to the end of the line is d$
In visual block mode (ctrl-v) you can select a bunch of text and apply an action (eg. a simple replace, which would be :s/foo/bar) on only that text.
Even if you just learn a bit at the surface, the free composability of motions with actions makes even classic vi (which doesn't even support arrow keys for moving around) extremely comfortable to use, and most of the time you don't need to twist your hands into uncomfortable chords involving multiple modifier keys.
In Emacs, deleting four lines is Alt-4 Ctrl-K, usually written M-4 C-K.
One way to delete a whole block (meaning a paragraph?) is M-h Backspace. Deletion to the end of the link is C-K.
Selecting a region is done with C-Space, running a simple replace is then M-% foo bar !
I'm not an expert with Emacs. The most useful function I use is the macros, which saves me learning many other functions. F3 starts macro recording, F4 ends it, then F4 again runs the macro. It's easy to script changes and run them in this way.
Emacs is without a doubt superior technology when compared to vim. There are perfectly usable vi clones that run on Emacs, after all. The main benefit vi has over emacs is that it's everywhere (except windows :() in some form, so even on a completely unfamiliar machine away from your highly developed dotfiles, your muscle memory still works to an extent.
The main reason I don't use an Emacs implementation of vi is that muscle memory is really bothersome to retrain, and the differences are enough to disrupt my workflow rather badly when using eg. Spacemacs. I just haven't found the benefits to be significant enough to outweigh the inconvenience of retraining myself.
There are different paradigms in development environments, Unix+a text editor is one. There are also those like Emacs, Acme, and usual IDEs. One has to choose which is better for their use. Say if you're a Mac or iOS dev maybe XCode is better for you, but if you're writing C, Perl, Python, etc., Unix & Vi is a nice environment. If you're doing Lisp, Emacs is the best environment out there (though Emacs and Vim are extensible, so they have some tooling for all the languages out there).
The latter is rather subjective. I love vim for small projects, which, being a grad student, is most of what I write. However, I prefer IDE's for large projects with multiple files and hierarchies.
One thing I have noticed however is, that once you are good at the vim keyboard shortcut "language" (as someone described it above), you tend to use other features in the editor a lot less. And if you don't use the features, you might as well just use vim neat.
... are you serious?
In almost all cases where I need to do a find/replace there are typically no more than 4-5 references that need to be updated. And I think a better way to phrase my behavior is I search, inspect the code to make sure that my change won't introduce a bug or some unintended consequence, and then replace. This may be slower, but in the grand scheme of things it barely registers on my overall productivity and if it saves even one bug from getting introduced into the code than the extra time spent probably pays for itself. If I need to update more than just a handful of references, than Sublime has a perfectly functional find/replace tool, but I have only ever really needed it maybe 3-4 times in the last few years.
To get back to the question at hand. How long does it take you to formulate these series of commands in your example? Because to me it feels like it would take longer to come up with a correct set of commands for your example than it would be to just search and replace 'by hand'. Of course if you are updating 100's of references than spending some extra time to formulate your solution makes sense, but in your example, you limited your search ~1000 loc, so presumably you are only updating a few lines, maybe a dozen at most? I understand that vim is powerful tool, but it seems to solve problems that I don't have (or that I don't consider to be problems), and I am genuinely curious as to the sort of problems and types of code bases that vim aficionados work on.
# Search and replace using a 2-variable regex
:275,1305s/two_variable_regex/first\1second\2/g
# Replace TEST_ with test_
:275,1305g!/a_regex/s/TEST_/test_/g
But, if it's too convoluted to do something like this in vim, you can instead do something like: :275,1305 !perl -ne '# substitution, then print'Someone else could do it with sed, but I prefer awk.