I keep trying to get into vim, but I just really enjoy multi-cursor editing in Sublime Text. The example in the article of changing multiple lines using '.' to repeat is the same as selecting the three lines in Sublime Text, entering multi-line edit mode, and then typing the change once. The same applies for replacing a single word (e.g. with Cmd+D) and/or regex replacements. Basically, I have a really easy time avoiding any repetitive commands in my normal day, so I wonder what the real advantage of vim would be for my use case. Or maybe I just don't know what I haven't yet learned...
Didn't realize I could do `di"`... that's so neat.
I always at least whip through such articles about vim as there may be something I don't use daily, but could. There always is such a thing.
I love to use all the zero-configuration things that are already present in Vi/Vim at work. IDE's are cool for devs or people who do everything from a stable workstation. I rarely have such comfort, jumping from one server to another, from one image to another. And Vi or Vim are always there. Thanks for all those hints.
You can select multiple lines in vim using ctrl-v, then do some action on all lines like inserting by shift-i, or whatever you want to do with the lines. Replacement with regex is also trivial.
I switched to Vim from Sublime Text years ago, and honestly multiple cursors and the live search and replace (especially across multiple files) were both missed until I learned how to do them in Vim just as easily.
Vim is a multi-year investment, and isn't worth it for most people.
AFAICT multi-cursor mode is not nearly as useful as vim (or keyboard macros in most editors). I don't know SublimeText but I do know, functionality of multi-cursors is often limited. For example, say I want to go to all functions calls
foo(aa, bb, c);
foo(d, ggg, hh);
foo(iiii, i, jjjj);
I want to do something to the 2nd argument on each line. add a fn(prevContents). So I search for "foo(" and then pick "put a cursor on every match". Then how do get to the first comma and the select to the second comma on each line? This is easy with vim, easy with keyboard macros, not easy with multiple cursors (that I know of). For example as soon as I press "find" so I can search for the comma I lose multiple cursors. Maybe there's a special "Search with multiple cursors" command but if so that just highlights the issue, you shouldn't need special commands, you should be able to combine existing commands. vim and keyboard macros make that easy.
For things like that, I usually make use of the C-Left and C-Right combinations to get to the same place on every line; after all, if two lines are similar enough for me to do the same thing to all of them, they very often have the same sequence of words. (Sometimes there can be issues, e.g., if one line has an extra index.) For reference, I tried your particular example, and the keystrokes look something like:
C-f, "foo\(" [open a Find dialog]
C-Enter: [foo(]XX, YY, ZZ); [Find All shortcut]
Right: foo(|XX, YY, ZZ); [move to the right side of the match]
C-Right: foo(XX|, YY, ZZ);
C-Right: foo(XX,| YY, ZZ);
C-Right: foo(XX, YY|, ZZ);
C-S-Left: foo(XX, [YY], ZZ); [select leftward]
I suppose that it's not quite as ergonomic as Vim keybindings, but it's definitely less of a departure from the usual OS text boxes.
Now, I use vim mode in Sublime, so I have already "seen the light" so to say. But that situation is probably one I'd actually be able to solve faster with multiple cursors.
What I'd do is this: Put the cursor on one of the calls, then use ctrl-d to put a new cursor at all the matches. Then use ctrl-right-arrow to move by word until the second comma, combine that with shift to select the argument and edit all of them with visual feedback to my heart's content.
In reality, depending on the complexity of the text, after creating all the cursors, I'd probably use the vim movements to get them to where I need though.
Multiple-cursor editing is a nice and cool feature, and for what it's worth there are some vim plugins to get it in vim, but let's see the alternative:
- multiple-cursor: select non-contiguous pieces of text, then edit them all at once.
- vim macro/repeat: edit a piece of text, and repeat on similar occurrences.
The vim "way" could be, `/;$` to select the trailing semi-colon, then `cgn` to edit it (enter the curly block once in insert mode, then exit with `<Esc>`), and now you can repeat on the next trailing semi-colon simply by hitting `.` (dot).
So, instead of first looping on the occurrences to get multiple cursors, then do the editing, you first do the editing on an occurrence, and you loop on the editing. There is admittedly less of a "wow" factor, but I don't think it is any less powerful.
It is way harder to use macros than to do multiple-cursor editing, especially for the kind of fast changes that happen 10 times a day. The difference is between seeing interactively exactly what you are doing and where something is going wrong (with multiple cursors), vs. recording a macro, replaying it, realizing you forgot to do something like use the correct keybinding, rerecording, etc.
I say this as a huge vim advocate, who used vim exclusively for 8 years before switching to emacs and lately to vscode.
Vim gets a lot of things right, and there's no comparison to using vim-style editing. But multiple-cursor editing is a killer feature that really does improve your workflow a lot of the time. Luckily most editors have some version of it now, though often not as good as the original and doesn't always play nicely with the various vim modes.
Yeah I used it (or something similar) when I was actively using vim. It wasn't as good as a proper IDE but was fairly good for a variety of use cases.
(I actually tried to implement my own multi-cursor plugin in vim, and got a decent amount of the way there before realizing my fundamental approach probably wouldn't work.)
Maybe because I’m also a maker I don’t expect my tools to do everything… what’s wrong with using vim for what it does very well, and then Sublime (geany, kate) when a gui is just easier?
But the way I use my editor is that I'm usually in it all day. Both for editing code, but also for personal notes, etc. So it's on all day and I spend most of my time in it.
This effectively means I have one tool that I mainline. I'll still use vim in the odd situation where I can't use my main editor, but it's usually just easier for me to open files in the editor I already have open.
. is more general as it repeats any editing action, not only insert-at-cursor.
I keep trying to get into vim
Speaking out of my 20 years experience, you probably shouldn’t. You’ll find vim a little behind sublime/vscode in some parts and will keep trying to get out of it, unsuccessfully. I came to conclusion that I wish all of the editors (vim included) separated editing from their operation and made it modular (vim-like extensions are limited to a subset of it and are really worst of all these worlds, cause only half of your habits work and none of your scripts/addons do).
Evil emacs is pervasive, vim users that I pair with are able to use my keybindings. I just have a lot more plugin power at my disposal on top of that.
Update: I guess your complaint is about a plugin ecosystem that doesn't respect vim bindings. I think you'd be impressed by what the evil community has, speaking as a former power vim user whose emacs setup is even better.
My problem with evil is that I'm still inside of Emacs and I still need to know Emacs to be useful with it. If I am keen to become an evil user, what is my path forward? I've watched videos, read "tutorials," I've tried evil, doom, spacemacs, etc. I'm always put off by the thing almost as soon as I punch `$ emacs .` into my terminal. I've got nearly 2 decades of mileage with (neo)vi(m) in my rear view mirror. I am very interested in org-mode and am willing to learn but for the life of me I can't figure out how to.
Fair enough, I haven't seen a great learning path, every question that I asked at first ended in an answer with something in emacs that I didn't know about. What the hell are helm, avy, Ivy etc? I just want to find some files.
I'm on spacemacs which I believe has given me a massive head start on a great setup. If I started from something more lightweight I would have wanted to end up where I am now, but the results on my own would have been worse.
However I admit that even the supposedly beginner friendly spacemacs still has the same problem of "find the intuitively named spacemacs layer, then start googling all the package names mentioned in the docs (which are not intuitively named), and possibly read the source", which is a big set of hurdles.
Appreciate the reply. I guess it's all perception. If I was in my 20s, I'd have the time and desire to dig into it and figure it out. Alas, I'm in my 40s and between work and family I just don't have the time for those things. Maybe when my kids are a little older...
These don’t work for me because I made a slip and added too much vim-specifics to my editing/workflow habits. Vim emulators only work for those who have 3-5 years of non-active exploration experience. Once you commit to plugins, buffer/window-related actions, scripts, hooks, heavy vimfiles setup, etc, the way back is as hard.
Edit: please don’t downvote the parent commenter, it’s a non-obvious knowledge and it doesn’t apply to everyone.
Yeah okay, I understand emulation is a subset, but surely a modern IDE takes care of most of the productivity gains you get from customization and adds a few more, like the context/AST-aware refactoring you find in Jetbrains IDEs
Edit: I spent a long time trying to make Vim more IDE-like, but found it was more productive to make my various IDEs more Vim-like, but I concede that might not be suitable for everyone
Just so we don't compare apples and oranges: The refactoring tooling in jetbrains products is unique. I haven't seen vscode or any other ide capable of reproducing this, at least not for dynamic languages.
I wouldn't use this as the basis of an argument for superiority of IDEs in general over vim.
And of course there are tradeoffs, rubymine users I worked with always complained about startup times and heavy indexing. (This was a few years back, maybe it's improved since)
I use VIm in vscode quite a lot, and I do reach for macros to refactor code a lot more than when I switch to a JetBrains IDE. But I couldn't see a benefit to using vim outside of vscode for these refactoring operations, so I'd be curious to know whether you do and what you use?
I'm not saying vim emulation has anything to do with refactoring, I'm saying that outside the jetbrains stable there are no refactoring tools worth speaking of, i.e. refactoring is not a variable in which IDEs in general beat vim.
If you can write vim macros to extract method, push up dependencies etc, then you've made vim better than most IDEs.
Yeah, I’m also leaning to just learn the heck out of vscode internals and tune it to my own needs maybe via custom plugins, instead of running behind the train. Sometimes investments just stop returning, and you have to make bold moves want it or not.
After many years of being in your camp, I finally made the switch to VSCode (well, first to Spacemacs, then to VScode).
It's true that there are a lot of things I configured specifically in vim, however, VSCode has a pretty decent vim mode that takes care of a lot of stuff (including a bunch of pretty standard stuff that most people add to vim, like adding vim-surround for example).
In addition, it has a pretty decent way to configure new commands, so most of the other stuff I missed from vim I could actually figure out how to port over to VSCode.
Totally worth it for me - it was a few months of slowly rebuilding habits and porting commands from vim, but now I have a "best of both worlds" setup.
One thing that bothered me a lot when I tried to use vscode (with the best vi bindings I could find) was that the vi bindings only actually worked within specific text areas
if I want to do something like filter things in the problems pane, I need to focus an entirely separate thing with no vi bindings so I'm forced to reach for the mouse to use that or even to just get back to a pane that supports vi bindings.
also ctrl+w closes tabs instead of being a prefix for focusing different panes
I used to have that problem everywhere. But I solved it back then by creating a set of scripts that let me use something like vim mode anywhere on the computer.
Lately I've switched to a programmable keyboard, so my actual arrow keys are int accessible via a special Layer (I hold a thumb key, and that gives me hjkl, as well as various other bindings I've created that act like vim commands).
First of all, setup is much easier. If something breaks, I can easily fix it. If I need a new language to be supported, it's usually a click then a 10 second install, and it usually suggests it for me (instead of having to search around).
It starts faster, everything works together better, no weird plugin-compatibility issues (mostly). If I need to find a command, it's easier to lookup in VSCode than Spacemacs (because the menus use a much better GUI, with fonts, highlights, etc).
If I want to switch between files, open a folder as a project, etc, it all works well, and out of the box. With Spacemacs, there isn't a good file-tree pane that I can put on the left - IIRC it comes with something like NERDTree from vim, but it never worked well for me. Partially this is the whole fonts/gui/etc limitations, partly it's because a lot of the shortcuts just don't work that well. Just quickly opening up a folder, seeing what files there are, and being able to rename a file by right-clicking on it and hitting rename is something that I don't do often, but happens once a week, and in Spacemacs, that once a week necessitated either looking it up, or fixing something.
(I was faster at doing these things with vim, in which I had way more time invested, but why I switched from vim to emacs is a similar story in many ways.)
Honestly, overall, VSCode and modern IDEs are just a much smoother, better overall experience in so many small and large ways, that I feel I am much more productive, and have to spend way less time tinkering with my editor. And much as I love to do that, I've been doing it for 10 years, and already have a decent set of knowledge about what I need and want. Getting it practically out of the box with VSCode, and having it work better, is a wonder.
(My biggest block in switching to a different editor in all this time was that I had to have a decent VIM mode, because being able to actually edit text at speed and comfort is more important than all the other features to me. But once I realized that Spacemacs' vim mode was decent, I switched to that, and then I played around with VSCode and realized the vim mode there was decent too. Definitely enough to satisfy 95% of standard text editing use cases, with either plugins or my personal mappings making up the gap.)
Makes sense. From the sounds of things, we went in very different directions because I cannot tolerate mouse use in my workflow (severe RSI that got drastically better when I switched to vim). Switching to something that requires pointing to navigate anywhere or clicking is a hard no.
From the sounds of things you're used to discovery by context clicking and menu items, and emacs' lack of such things does hurt discovery. I find the mnemonic key mappings in spacemacs to be superior to those interactions, but I'll admit: only if you can actually find them, and it does take some time to get used to the conventions.
As a developer though, I am an expert in using my editor, so I'm happy doing e.g. ",tt" to run the test where my cursor is, ",tb" to run all tests in a buffer, etc. because that knowledge pays off hundreds of times a day.
Lastly I'm not sure the distinction "modern IDE" is helpful. Neo/vim and emacs are both under very active development. Useful variables seem to be things like: package ecosystem, UX, aesthetics, responsiveness. All of those can be divided into beginner/expert and IMO emacs wins all of the expert cases, _if you are willing to put lots of time in_. For example I'll take my beautiful full screen spacemacs with the bells and whistles turned on over the looks of my colleagues' VSCode any day.
"Willingness to put the time in" of course exists in a continuum. I know fantastic programmers who gave up on the effort of emacs, and others who tell me that I'm selling myself short by stooping to spacemacs instead of rolling my own. So everyone's MMV.
> Makes sense. From the sounds of things, we went in very different directions because I cannot tolerate mouse use in my workflow
I half agree and half disagree. I also really hate having the mouse involved in my workflow.
> From the sounds of things you're used to discovery by context clicking and menu items, and emacs' lack of such things does hurt discovery.
That's part of it, but not all of it. I don't use context menus much and am also a keyboard-centric user. I rarely use menus for any common tasks.
That said, things that I do once a week, but do need to do, are often easier to do using a mouse (or rather, it's good that a better discovery mechanism exists for them).
> Lastly I'm not sure the distinction "modern IDE" is helpful. Neo/vim and emacs are both under very active development.
That's true, but that's not what most people mean. I think the 'modern' comes in in terms of UX, or at least that's at the root of things - because almost everything can be done with vim/emacs, except for fundamentally changing how they look (different fonts/colors/etc). Or changing the under-the-hood stuff (like running parallel processes).
> For example I'll take my beautiful full screen spacemacs with the bells and whistles turned on over the looks of my colleagues' VSCode any day.
I mean, obviously this is subjective. But GUIs that allow a full range of colors/sizes/etc, and are not limited to only being text buffers, do objectively allow you to do more things. And it's no coincidence that almost all IDEs/editors don't use a single font size everywhere, etc.
> "Willingness to put the time in" of course exists in a continuum. I know fantastic programmers who gave up on the effort of emacs, and others who tell me that I'm selling myself short by stooping to spacemacs instead of rolling my own. So everyone's MMV.
I mean, I used vim for about 8 years, including writing (personal use) plugins and having a very large .vimrc. I then switched to spacemacs, had a bunch of configurations there as well.
So I feel like I've definitely put in a decent amount of time getting "good" at vim (and to a much smaller extent, spacemacs).
Still, putting aside the pure text-manipulation aspects of vim productivity, just launching VSCode and opening a folder gets you way more of the way to productive coding than everything I managed to roll out using a vimrc (and does't break every time I change language/computer).
Yes. VSCode at least (haven't used Sublime in a few years) has a vim mode, which has great macro support. It's not 100% compatible with vim but it's pretty good.
It's been a while since I've used vim, but I definitely recall doing multiline editing as you describe in vim. There is a visual-block mode that does multiple cursor manipulation
Macros and replaying my last command at a new location are the biggest thing I miss from vim. With regex replace groups you can generally get close enough to the desired productivity though.
(Personally, I find vim's multiselect cumbersome to use compared to sublime/vscode's.)
You can build a macro on the fly to do some transformation for, say, a line of text, or even a function, and just repeat those manipulations. Usually they are crude combinations of vim inputs that work well enough for the situation at hand. Obviously it's not a replacement for IDE refactoring, but if you're using a vim emulator, you can do both
