Moving fast with the core Vim motions | Hacker News Reader

Moving fast with the core Vim motions

barbarianmeetscoding.com

425 pointsmooreds265 comments

We've got younger guys on my team that hem and haw about the fact that we only have vim on our hardware implementation (SAMA5 busy box), and straight up don't understand why I basically can't use VSCode without the extension, and this article hits on so many good points. Vim is extremely expressive, and everyone ends up using it in slightly different ways. For me, my movement tends to center around:

- 'e' and 'k' rapidly, or 'h' and 'b' rapidly to move left and right, or using 'f'/'F' and a target character, with '0' and '$' as needed

- For vertical movement, I tend to use ctrl+'d'/'u' to move the document up and down in chunks, then specific line numbers, as well as marks (usually at most 2-3, with 'a', 'b', and 'c') to hold on to specific areas, or I just end up remembering line numbers and jumping to them.

- Lots of yanking and deleting to specific targets, be it hori or vert

There's plenty more beyond that, but that really is the "crux" of my vim usage, and from what I've seen watching over the shoulders of many programmers over the years, it makes me way faster than most. Programming isn't about typing speed, but my work is often in doing large refactors in enormous codebases. I need to be able to move around as close to the speed of thought as possible, and I have never found a tool that comes anywhere close to providing that ability as vim.

Also, any chance I get to plug the greatest StackExchange answer ever, I will: https://stackoverflow.com/questions/1218390/what-is-your-mos...

vscode with the neovim extension is awesome... almost perfect.

I've asked this before but I'll ask it again. Usually when people say they don't like vim plugins for other editors, they say that the plugin doesn't do everything they need. What features of vim are people missing in the plugins?

I've been using vim and vim bindings for like 3 years now. I've occasionally ran in to something that the plugin doesn't handle well but I can work around it with a custom binding. This has only happened a handful of times. I'm genuinely curious about what features of vim I've been missing out on!

IME, these people just haven't put as much effort into it as they've put into their custom VIM/emacs configs. There might also be a sunk cost fallacy aspect to it as well

But there's nothing in VIM that I'm not able to do in VSCode. Especially when you realize you can very very easily bind VSCode commands to keys in VIM. It starts to feel like a superpower.

you can do that in the neovim vscode extension too though and everything else is faster in spades.

from my neovim config:

nnoremap <silent> zc <Cmd>call VSCodeNotify('editor.fold')<CR> nnoremap <silent> zo <Cmd>call VSCodeNotify('editor.unfold')<CR>

> What features of vim are people missing in the plugins?

The feature of not having your editor made by an evil greedy corporation. Oh, and also startup time and memory usage.

it’s literally neovim in normal mode but when in insert mode it’s vscode basically. there’s weird edge cases when you try to replicate all of vim’s features without it being actual vim. it’s faster too. it can use almost any neovim plugin too as it’s, again, actually neovim doing the hard work.

For me, it's more about the plugins that are missing, like Telescope. Being able to filter a buffer or project to a search term and go one by one through them seeing the context is huge. (If you know Emacs, Ivy can do similar)

But there are some things that aren't quite right. It may be down to config, but it's frustrating when you use a key binding you expect to work that doesn't work the way it does in just vim. I can't name any specifics because I only use vscode for debugging sometimes.

I just really find visual debuggers to be a modern miracle.

I’m a veteran, but I run into that every time. I use nvim and pycharm.

Are there new developments that could change my mind? I love the idea of all of this.

I've had great luck with nvim-dap and nvim-dap-ui.

vimspector is a cool DSP for vim.

https://github.com/puremourning/vimspector/

use vscode with the neovim plugin. it has visual debugging built in and you can bind whatever command in vscode to a command in neovim if you want.

I only use vim for editing, but I reach for Chrome or VS Code for my debugging - I don't love the UI, but I don't do it that often and it's fine enough

> I reach for Chrome

Did you check the Vimium extension for Chrome?

https://chrome.google.com/webstore/detail/vimium/dbepggeogba...

lol, here's me 13 years ago on that repo filing an issue about google reader support (!)

https://github.com/philc/vimium/issues/82

anyway, yeah I'm aware of it haha

edit: my fork is still alive! Here's a commit from 2011 that I never filed a PR for that includes a news.yc submission keyboard shortcut for vimium: https://github.com/llimllib/vimium/commit/59e3d7f7aa01bb032d...

I use nvim-dap for python and go multiple times a week. It's basically the same as VSCode's debugger and I'm a huge fan.

Using DAP (debug adapter protocol), you should be able to run a debugger similar to what most GUI editors have in any editor with client support.

All of that but now I rely even more on searching a few characters to move around and do a lot of edit I make with :<,>s//g or :%s//g with the plugin that shows the result in realtime called traces.

Vim regex is not the best and there's an option to change but I got used to it. Recommend http://www.vimregex.com/

gv is quite handy when you want to reselect last to rerun a command on it too

I don't have a problem using both in their more or less default configuration.

I use vscode for editing code without any special keybinds and just a couple of plugins for syntax highlighting. I use vim for everything else in the terminal window (also without plugins). I don't experience any speed difference or difficulty switching between the two.

Yeah I'm going to say something blasphemous... they're about the same. Vim is just slightly jankier, but more mature/capable.

Moving text is great in vim but being embedded in the terminal means all the powers of the shell are one ! away as well that makes it faster to do things… need a quick syntax check !node -c % , or need to run a command !ruby %

It’s just faster when you are connected shell… and unlike vscode - vim is pushing 30 and the shell environment 40, I see very little reason the shell and vim will substantially change in the next 40 years… but I guarantee vscode will look very different… so learn a tool for life that will be just as powerful tomorrow as it is today

> Moving text is great in vim but being embedded in the terminal means all the powers of the shell are one ! away as well that makes it faster to do things…

Quite true.

Also, partial buffer manipulation can be done with external programs via range constraints. For example, to reverse sort only the first 5 lines of in buffer, one can execute this ex[0] command:

  :1,5 !sort -r

0 - https://man.freebsd.org/cgi/man.cgi?query=ex&apropos=0&sekti...

I like to use vi as a kind of IDE for shell commands, because you can, for example,

!}somecommand

to pipe a paragraph through that command, or

1G!Gsomecommand

to pipe the whole editing buffer through that command, which is also equivalent to

:1,$!somecommand

which I find less obvious as a way to do that, even though it makes sense historically in terms of ed and ex.

You can also, in vim, use u and ^R to undo your pipe transformation and redo it, so you're basically then doing a series of shell pipe transformations with interactive history.

If you need to generate text with a shell command instead of pipe existing text through it, you can use

:r!somecommand

Commands that I like to use in this context include tac, rev, tr, cut, grep, and sed (although using sed this way is a little silly since the substitutions I'm doing are normally also available natively inside of vi itself).

A simple example that I like a lot is

1G!Ggrep .

which removes all empty lines from the current file. ("Line 1 go to line, pipe from here to result of movement go to end of file, command 'grep .' [print lines that match 'any character']")

The classic ed/ex way to do this is

:1,$g/^$/d

which is just as many characters, but which requires lots of explicit thought for me, while the "1G!G grep ." version seems to no longer require explicit thought at all. ("For lines 1 to last line, repeatedly match ^$ [line beginning immediately followed by line end], delete matching lines.")

Does :% not work in vi as an abbreviation of :1,$ ? The classic :%s/foo/bar/ generalises to :%!somecommand .

It does, thanks for the reminder!

> For example, to reverse sort only the first 5 lines of in buffer, one can execute this ex[0] command:

> :1,5 !sort -r

Interestingly enough, you don't even need an external program for that. You can do the same thing with

    :1,5 g/^/ m 0

The g command allows for effectively looping over matching lines as opposed to operating on them all at once. The /^/ matches every line and since I'm using 1,5 for the address, it still only matches the first five lines. The m command moves a line (in this case, 0 which is the beginning of the buffer).

Since it executes it one line at a time, it moves the first line to the beginning of the buffer, then the second line (which places it above the first line), then the third line (placing it above the second line) and so on.

Your command doesn't sort, only inverses the initial order. It's equivalent to

  :1,5 !tac

It's better to learn tools that will improve over time rather than being stuck with all the design mistakes of the past (for your example, selecting "synt" from a command palette that autoselects node or ruby depending on your file is more powerful than having to remember individual invocations)

changing != improving

And a program can be improved even without it being changed substantially.

but not changing = !improving

(that's why you had to add the "substantially" qualifier)

> but not changing = !improving

Correct, but vim is changing. Latest release happened 9 hours ago, and in the past week there have been 17 commits pushed to master by 7 authors[1].

Also, there are a dozens of high-quality plugins that are in constant development.

> (that's why you had to add the "substantially" qualifier)

I was quoting the parent comment in which you originally replied (quoting again):

    I see very little reason the shell and vim will substantially change in the next 40 years…

[1] https://github.com/vim/vim/pulse

> there have been 17 commits pushed to master by 7 authors[1].

And there are 17 thousand commits overall, yet a lot of fundamental issues remain unresolved, so I guess I'd argue that in many cases a program can NOT be substantially improved without substantial changes (again, not universally!, some crash/perf wins are "free" in that they can change nothing in the program's user-facing behavior)

So I see a lot of reasons for the shell/vim to substantially change, and thus stability in this regard is a negative, not a positive, hence my comment that it's better to use tools that improve better (though you're right that improvement is not a given for a change)

I used Vim almost exclusively for a long time but am currently using vscode and I actually low-key hate the command palette. It's not always consistent (if you type return too fast you sometimes get a different command! Crazy) and I am never quite sure what it will execute, which means I lose time and focus waiting and double-checking.

Return issue seems like VSCode specific? Does it manifest in Sublime?

You also lose time on double checking typos in the term command (and it's harder to focus since unlike front&center palette this command is tucked away at the bottom), except you have no additional validation from a preselected set, so you need to remember the full command invocation precisely

And you can add special unique symbols to command names to make search unambiguous

You also get a hint re keyboard shortcut, unlike with the term command, so if you execute it often enough, you might switch to a faster and more predictable method

I think the return thing is a classic issue of autocomplete systems: what do you do if the user hits return (or decides to) and some characters are not yet reflected in the UI showing the current suggestion? Whatever you do there'll be misunderstandings.

I have a fairly high typing accuracy on physical keyboards, in particular when I'm in a focused state, so I actually don't double-check editor commands most of the time -- I let them fail, which happens rarely, and only double-check them the second time.

And yes, in practice I use shortcuts mostly (although either vim extension shortcuts or custom ones, usually, because many shortcut don't work as is in the vim extension, so the command palette hint is useless to me as well - but I don't hold vscode responsible for that).

It's a classic issue of slow autocomplete systems, why should there be any perceptible delay for such tiny data sets?

If you don't double check, it's most likely that you use it for something you're certain about, so it's more like a key chord rather than a search bar? In that case for these frequent commands it might make sense to add those unique symbols/letter combos (some extra Unicode symbols can help here) so that the fuzzy algo will never trip

And not showing currently active shortcut for a palette command is just another bad UI implementation, that kind of info should be centralized/anyways up-to-date so you can use it in palettes or menus or what not

And in newer versions of vim you can even run a terminal inside a vim buffer. Use :term to get started. ^w N to go from terminal insert mode to buffer mode where you can treat all terminal contents as regular text. Useful when you want to grab bits of program/script output and put it into a different buffer, or search the output with / and ?. You can also paste register contents directly into the terminal command line, e.g., if you have a text file with a list of long file names, you can yank one into register a with "ayy, move to the terminal window and do a cat ^w"a to cat the file name. (Or just yy to yank and ^w"" to paste in term if you're in a hurry). Handy in some circumstances.

vim is still very hostile to multilingual users with multiple keyboard layouts. You have to switch to a Latin layout before using any commands and switch back in order to input command arguments or go back to text input. Yes, remaps do exist but that's still a partial solution that doesn't work in all contexts. Nah. I can use a slightly less capable editor that keeps commands cleanly separated from the input language. Another issue is that commands are utterly unergonomic, requiring lots of rapid Shift presses/releases, and mistakes can lead to destructive consequences.

> Another issue is that commands are utterly unergonomic, requiring lots of rapid Shift presses/releases

Curious. Unergonomic compared to what? Given your comment about separating commands and input language, I assume you’re using a non-modal editor, which usually rely more on modifiers than Vim.

Personally, I haven’t found any ergonomic non-modal editor, where I by “ergonomic” mean no RSI pain even after heavy usage. For me, the fact that editing in Vim is comfortable is its main selling point (more so than its speed).

> mistakes can lead to destructive consequences

I do often make mistakes, but I can’t remember the last time I accidentally did something so destructive in Vim that I couldn’t just undo it normally.

I'm not referring to keyboard ergonomics in my comment; I just can't input some of the required key sequences reliably and without making mistakes (not good at playing the latest Zelda game with its key combos either).

For example, I'm sometimes transposing characters, e.g. q: instead of :q, or :w! command instead of :w !command, that sort of thing. Undoable, of course, just not with a simple u.

Modifier-based shortcuts in other editors and IDEs appear to be more forgiving.

Wow, this is fascinating to hear. Other than the standard baseline of not touching the arrow keys, I use vim pretty differently:

- 'j' and 'k' to move up and down, with '{' or '}' or even something like '20j' to move quickly

- 'w' and '$' and '0' to move horizontally, with things like '5w' to move quickly

I also rely heavily on 'v' and ctrl+'v' to select arbitrary shapes of text for yanking/deleting. I'm not sure what the exact takeaway is from comparing our styles, but it's interesting to realize about how much of coding comes down to just navigating up/down/left/right.

I agree with your last couple paragraphs almost verbatim though! That StackOverflow answer is exactly the reason I decided to try vim and stuck with it.

The verb/noun nature of vim makes it so easy to enter a flow state. The text editor fades into muscle memory, and you can surf waves of code with no bottleneck between mind and machine. (To write this comment, I actually had to open a random file and navigate around it while watching my hands — it's been years since I've thought about it!)

I might be a perfect complement to the grandparent.

I use w b $ and ^ to move horizontally. I like using w and b because then I can hit cw to make a small change. For vertical (I don't really think in terms of horizontal and vertical, I think about it as a streams of "words" and "spaces") I usually do a search (/ or ? to go up or down) or for some files I do 20j like you. Shamefully, I do sometimes use the mouse out of habit from other programs.

I can't remember the last time I used f.

f I use second most. It has so many uses all of which could be done with / command, but definitely you come to prefer f. I use f( to scan forward to the next open paren. Then I use di( to delete in parens for example to remove the arguments. Uppercase F does the same but backward up the text. Often I use f, to go to a comma. df, to delete up to the next comma as in removing just 1 argument. The only draw back is that f does not have any repeat shortcut like n for next or . for reapply, those do nothing for f. I should mention also that f works on a single line at a time unlike /

After this I am going to try to work in f to my routine.

The only issue is (content warning: controversial remap) I have ; nnoremap'd to : and : to ; so it would be awkward to advance multiple matches. I would hate to lose my one key :, but perhaps there is a workaround if f is useful enough (for those unfamiliar, with / or ? you use n to go to the next match).

I specifically avoided making that ; and : swap for decades as tempting as it has always been. Repeating with ; is just too useful.

However, I'm using Doom Emacs these days (with evil, of course) and while it emulates vim's command mode with colon, it's designed to drive most "commands" with space as a sort of leader key. I could imagine space being a nice remap for : in vanilla vim since it does nothing in normal mode.

I use both vim and doom-emacs almost daily and jump between the two. I like using <spacebar> to call command mode in vim to do things like :tabe or :bd or :ls etc. (I have <leader> set to , ). I have this remap in my .vimrc > cmap w<space> :w<cr>. This allows <space>w<space> to write the buffer. The second space acts as <cr> meaning I don't need to press <enter>. Lovely.

Now, turning to doom-emacs, SPACE is the modal for getting the list of next available commands. To save a buffer in doom-emacs I use SPACE w SPACE. Et voila, the same muscle memory works for both. BTW I also set up :ww to write/quit so SPACE W W does this in both editors. Well, it works for me!

That sounds great! It actually only dawned on me that I could have a setup like you describe as I was writing my comment above. Thanks for sharing your details!

The only downside for me, and I've been reluctant about this for years, is I ssh into a lot of Linux machines that usually just have the standard stuff and default configs. This has kept me from experimenting with a lot things so as to keep my muscle memory also standard (thus avoiding i.e.: zsh, extensive .vimrc with plugins, etc).

Isn't dt, to delete up until and df, to include. I'm guess either you have config or it's so ingrained in muscle memory that there is a mismatch between what you type and what you think it is.

When I played piano there was a point where I could play a piece without thought but couldn't parse the sheet music or know what my fingers were doing anymore.

> The only draw back is that f does not have any repeat shortcut like n for next or . for reapply, those do nothing for f.

Boy, do I have news for you :) ; will repeat an f/t/F/T motion forwards, and , will move back. Having it separate from n/N means that they have a separate history and you can combine them to repeat motions.

Also, if you’re not bound to using Vim without plugins, then the CleverF plugin lets you repeat with f/F instead of ;/,

It’s IMO easier to hit f again than to reach for the semicolon, and moreover this frees ; and , for usage in your own mappings (e.g. leader and localleader)

> The only draw back is that f does not have any repeat shortcut like n for next or . for reapply, those do nothing for f.

As I just learned browsing through the book linked in this thread, there is!

Use ; to go to the next match or , to go to the previous one.

Great find.

cf) - change everything to the closing paren

df: - delete to the next colon

2f, - move cursor forward to the 2nd comma

I find cause to use f fairly regularly.

Oh! I do df but for whatever reason I don't think of it as using f.

Muscle memory is a weird thing.

Note that cf) will change everything up to and including the closing paren.

ct) (change to) will change everything from the cursor up to, but not including the paren.

But if you're trying to change everything in parens, you can simply use: ci(, regardless of where your cursor is as long as it's somewhere in a matched set. ci{, ci[, etc... also work. I find it pretty useful when working with code that uses a lot of those.

I have 2 use cases for cf), but I don't use it a lot in the end:

One is when inside a parenthesis, and wanting to really delete till the closing parenthesis. But that would leave an unbalanced open paren. So in this case, I use ct) most of the times.

The other is when the cursor is before the opening parenthesis, and I want to delete the whole block. In that case, I found c% to be easier to me. The advantage being that it works with other delimiters ({[]}) handles nesting better, and it's multiline friendly.

If instead of c%, we speak about d%, another plus is that dot (.) will repeat the generic command, so

    if (is_foo()) {

      return 1;
    }

can be cleared with `d%.` from the beginning of the first line.

ca( and ci( might be what you’re looking for.

Yep, good point. They are useful when you want to change the whole text inside the delimiters (and IME, it's most of the times), but they do different things than cf( because they also change/delete text behind the cursor.

The % approach works only on one direction.

`c])` is also pretty handy when you're within a bunch of parentheses. For instance,

    if funca(funcb(red, green), funcc(blue, yellow)) {
                                ^

If you are where the arrow is, `c])` will change the second argument. If you were on the comma before it, `d])` will remove all but the first argument.

And all of that works after pressing v so you can see what you are about to delete or change before doing it.

Quite helpful if you have multiple of the same character and you want to go beyond the first one without needing to count.

I usually go for “ciw“ to make changes from wherever I am in the word. It lets me use w or e because I’m not usually paying attention to which one I’m smashing. :)

My own usage is very close to yours.

{ and } pollute your location list! So your C-o will also jump through points where you pressed them. Also, for terse (whitespace-wise) codebases, they become useless. I used to use them a lot but now I use C-u/C-d for most vertical movement (and {} in those super rare cases where whitespace is just right).

To move horizontally, simple 'f' might be faster quite often (some prefer combining it with leap-like plugins like flit if using nvim).

Interesting. I almost never use ctrl-o except if I navigate to another file and want to go back, happens intentionally and by accident but in any case rarely.

I never used it either before I started seriously using neovim for Rust development with a near-perfect LSP. You quite often 'gr' (go to reference), to check what some function does or how something is defined, then gr again and again.. and at some point you need to go back (yes, there's gi and c-t etc but C-o is less specific and works in many other cases; you can also set marks and harpoons and the like but most of the time you don't).

Interesting. I thought neovim is the reason I don't use ctrl-o, because it has floats. With my config I can gd to go to definition (and then sometimes ctrl-o back) but often do gpd to peek it in a tiny mini window.

By the way even without { and } which I never used really my ctrl-o history seems to be too verbose, I wonder what I am doing wrong.

I kind of settled on vim as console editor in Linux but it will never replace good ide for me, and modern ides are getting/having vim mode for navigation, making then even more compelling.

* Do you want autodetect indent and tab rule in file? Install plugin.

* Do you want to automatically insert matching closing parenthesis - rebind keys (half baked solution) or plugin.

* Vertical scrollbar? Plugin

* Autocomplete code using lsp? Dance with plugins or copy paste literal screens of configs for nvim

* Want nice looking theme? Plugin! (Gruvbox in my case)

* Install and manage plugins? 3rd party Plugin for that too, with init code that will clone it itself from GitHub

* Wrap long lines by whole words if possible? No default setting, I guess I need to search for plugin for that too.

List goes on and on, and it is just I’m looking at my vimrc and recalling why I added or another thing. And there are many things which I decided to just to not care about, because it requires too much time to get it work

Parent mentioned refactorings, but trust me, no matter what typing/navigating speed is, the standard refactorings in modern ides (that I bet cover most of typical refactoring work) will work faster and more correctly than manually doing the same. Even basic things like projectwise method rename or extracting something to parameter.

Almost every quality of life improvement that is standard in modern ides require tinkering with vim.

That’s mostly true, but then one day you want to use an external filter, or a custom set of snippets that doesn’t suck at editing them, or make the next line align correctly after “(“ and there’s no plugin for that in your ide. And, more importantly, it’s a pita to create and publish one. It’s not better or worse, some people like off the shelf availability, some like local fine tuning. Would be nice to have a full union, but ides suck at local customization that wasn’t trivial or planned in advance.

Added: I hate both worlds now. Where’s an editor that is full of modern features and at the same time easily programmable?

The last great effort with resources, experts, etc. was VSCode. If they can't nail it, can it be done?

VSCode seem to have a lot of things done very right, but i don’t want to focus too much on it in vim topic.

Emacs

v29 looks promising :)

Maybe 10x, but I’m not willing to switch yet myself, I need C-[ for Esc.

https://10xeditor.com/

Given amount of the extensions that vscode has I feel that local customization is solved problem for it. But it is rather exception

VSCode plugins still take a massive effort to write in comparison to vim/neovim where you could basically do everything in your vimrc.

> Added: I hate both worlds now. Where’s an editor that is full of modern features and at the same time easily programmable?

An IDE plugin for Vim rather than a Vim plugin for IDEs?

> Added: I hate both worlds now. Where’s an editor that is full of modern features and at the same time easily programmable?

What about an editor with

- LSP and treesitter support built-in

- Scriptable with Lua, a common and well-supported embedded language

- Regular and remote plugins can be written in NodeJS, Python and Ruby for starters

- Built-in terminal emulator

- Uses XDG directory layout

- Plugins run as separate processes

- API for accessing core editor features

- UI and core editor are decoupled; all UIs are plugins

- Multiple UI clients can connect to the same editor server

This and a lot more is on the Neovim page [1].

[1]: https://neovim.io/doc/user/vim_diff.html#nvim-features

nvim is in my setup scripts with dotfiles and is picking up my vim config per my init.vim. But still - look about actual setting up it [1], [2], where [1] stragight says "if you need autocomplete, you need plugin for that". I obviously can do it, but I just don't want to... Batteries should be included in $CURRENT_YEAR.

It is probably missed, but I use vim everyday, as text editor for many years. My .vimrc on github is 3 years old, and only because I moved it there from bitbucket and didn't bothered to preserve history. I'm not against it.

It was that original comment that I answered, was saying that vim is effective/better for IDE specific tasks (e.g. large refactorings, that inititial comment that I've replied), and after many years of using vim I strongly believe is rather ignorant and shows not understanding of power and features of modern IDEs.

[1]: https://github.com/neovim/nvim-lspconfig

[2]: https://alpha2phi.medium.com/neovim-for-beginners-lsp-part-1...

Guilty as charged but complaints about "tinkering with Vim" kind of miss the point to me. Tinkering isn't a bug, it's a feature. Vim was designed in the UNIX philosophy of small tools that allow you to modify them to your needs.

Also, modern IDE layers for Neovim such as LunarVim or AstroVim make managing plugins trivial.

Nothing about vim is “small tool”. Maybe it was 40 years ago, but now it feels much more bloated and with too much tech debt accumulated during the years.

In what way is it bloated? IIRC, the executable is less than 2MB, and without plugins it uses about that much memory too.

GP mixed up vim with emacs.

You forgot vim-runtime that is another 35mb and hard dependency on Debian.

But I was rather saying that if a program has 600 pages dense manual (vimbook) it is certainly far from Unix philosophy of small utility doing one thing.

Damn, it has built in file explorer and remote editor (netrw).

It strikes me that that’s roughly 0.05% of the RAM on my desktop.

You can install vim-tiny on Debian, which I believe doesn't install the runtime files.

Size is not really a good indication of "bloat" IMO. There are 683 syntax highlight files, 7.8M in total, but you don't load most of that and it's just "idle" bytes on disk. Same for indent files, ftplugins, etc.

You could also save ~5M by not shipping translations, but is that "bloat"?

It's useful these things are shipped, and in the scenarios where you care about 35M of diskspace you probably don't want a full Vim anyway (and you can use vim-tiny).

I wasn't speaking about binary size, it was the answer to message that vim is 2mb binary. Bloat is that vim, even without scripting, is huge, and, at the same time, a lot of standard things are suprisingly missing. Even author of neovim felt that

> But I was rather saying that if a program has 600 pages dense manual (vimbook) it is certainly far from Unix philosophy of small utility doing one thing.

Sorry but I think you're confusing Vim with Emacs, the editor with the unofficial motto of "a great operating system, lacking only a decent editor" because of the tendency for users to do many computing tasks inside of Emacs (like playing MP3s) that had nothing to do with editing text.

Neovim is a refactor of Vim with 30% less code. They got rid of obsolete platforms (sorry Amiga and OS/2 users) and many features that no longer made sense or were replaced with newer/better functionality [1].

[1]: https://neovim.io/doc/user/vim_diff.html#nvim-missing

Well, that's what the Neovim project is all about...stripping Vim down and removing the bloat and old technical debt. Have you tried Neovim? It sounds like it would be perfect for someone with those concerns.

vim itself isn't a "small tool", but its command-driven nature and plugin ecosystem is very much in the spirit of composing small tools to get things done. Emacs, imo, is even more so.

It still starts a thousand times faster than any IDE.

Additionally, it still uses less resources. VS Code consumes at least 1 GB of memory for just a simple project. I am not even mentioning other IDEs

Correction: AstroNvim.

Vim (Or rather neovim) now is that tool that grows with you as you age. So, as you mentioned, even I have small small things I've added and removed from my vim/neovim setup over the years as I have changed with the code.

For me personally, the benefits are worth it, because the neovim approach really works well with my way of working with editors. And the "personally" part is really important.

In my early years I have used IDEs and I was never really interested in using Vim in the first place. (I thought it was not very nice looking when I first looked at the empty screen). I only started using it because I found other IDEs (CLion, Visual Studio) and so on not very comfortable. Even now, I have tried quite hard to use VSCode due to its support for remote development which I really like as a feature. However, I keep coming back to Vim it seems.

So, for me, vim is an appropriate tool, but it might not be for you, because we might be thinking about text editing in fundamentally different ways.

I don't feel that we thinking about it differntly. It is that editing source code is much more than just editing text. And vim severely lacking as an IDE.

We don't need to associate motion style navigating and separation of command and insertion modes as something very vim specific. It is that vim is installed on every machine that I work on in like 99% of cases, and it made sense to me to learn something that is always available. But the shortcomings are very clear.

I can give an analogy of gdb. I feel that anyone who says that text mode gdb is anywhere near convenience that you get using modern IDE is suffering from stockholm syndrome. Yes, obviously it is more powerful in some circumstances, but for day to day use it is just plain inconvenient.

And that's why I said in my first post - I settle on vim as text editor, but I gave up trying to set it as an IDE, so I will never code in it, unless I'm forced to (who knows, weird job that requires vim use etc). Life is too short for that amount of tinkering.

Text mode GDB is very clunky, but it is better than any frontend I have tried. Whatever pain points it has, I can mostly work around with scripts, which isn't possible with a GUI. The worst part is that it's awfully slow for programs with a plugin architecture. If I set a pending breakpoint before starting the program, I can wait ten minutes until all plugins are loaded. I really wish I could tell it to preload some debug information at the start.

> * Wrap long lines by whole words if possible? No default setting, I guess I need to search for plugin for that too.

Shift-V:!fmt

Works on all blocks, not only lines.

I didn't mean formatting, but just "wrap lines in editor". So long lines always fit screen, without actually inserting line separators.

I was speaking about

    set wrap

but because I turn on display invisible symbols,

    set linebreak

doesn't work. Why? I don't know. Somehow IDEs can do that without issues, but the technology isn't there yet for vim, seems like.

> Do you want autodetect indent and tab rule in file? Install plugin.

https://www.kylheku.com/cgit/c-snippets/tree/autotab.c

Nice, it works well!

Some see having to install and configure a plugin as a bug, but I see it as a feature.

You can also get modern IDE features such as LSP supported renames in Vim, so it's not an either fast typing or good refactoring support, you can get both.

I don't see any of those features as improvements. Even when I had to use an IDE (java...) I never enabled any of that.

Not to detract from your general point - I definitely see the value in using an IDE with a Vim plugin, and often do so myself.

> Vertical scrollbar? Plugin

If you want scrollbars, the right solution is IMO to use a GUI Vim. I often use MacVim which is great, GVim is the obvious alternative on Linux/Windows, and NeoVim has lots of options (including, arguably, VSCode-NeoVim which is also great).

With MacVim, I can pop around randomly in a terminal and open Vim instances that run in the terminal as usual - and if I start editing something for long, I can type :gui to pop up an actual MacVim GUI window. I believe the same works in GVim.

> * Autocomplete code using lsp? Dance with plugins or copy paste literal screens of configs for nvim

I was annoyed by this as well. I then discovered that ALE (the venerable pre-LSP plugin for async linting) now has full LSP support, and it all “just works”. Doesn’t require NeoVim either. Just install the ALE plugin and put LSP servers in $PATH. ALE will find and use them. (By default, it uses standard Vim bindings like C-x C-o for completion, but you can change it.)

> * Want nice looking theme? Plugin! (Gruvbox in my case)

Vim 9.x (not NeoVim) has added a built-in Gruvbox theme named “retrobox” (both light and dark variants based on your background setting). If you don’t have it yet, you can get it as a plugin from here until your Vim updates: https://github.com/vim/colorschemes

> * Wrap long lines by whole words if possible? No default setting, I guess I need to search for plugin for that too.

There are built-in settings for this, but yeah it requires some initial fiddling to get it nice. (After that initial fiddling, I’ve been annoyed by how word wrap works in any other editor.)

The greatest SO answer ignores the core issue "But you never know exactly if you've selected what you wanted." The solution to this is switching verb-object to object-verb like kakoune/helix do, but I guess that goes too much against the "zen of vim"

My problem with object-verb is that it requires much more keymaps for motions (you need to distinguish between “move selection” and “extend selection”).

Extend selection is via the same select mode that vim already has, so that's 1 extra key prefix, and move selection is enabled by default, so regular move commands pre-select what they move over, so in some cases that's even saving you a keypress :)

Though it's not that it should be the only way to go (plenty of vim pros have adjusted), it's just visual feedback is very powerful, and lack thereof is a legitimate big challenge you shouldn't ignore in the "greatest" answer

I wonder how it would be if one attempted to make Vim’s verb-object system more visual instead? Imagine if say “dwww” would highlight the next three words in red to mark them for deletion - but until you press enter to execute the deletion, you remain in a visual-like mode where you can adjust the region you want to delete by pressing more motion keys. Similarly, pressing “yip}” could highlight two paragraph (in paragraph + next paragraph) in yellow and then yank them when you press enter.

This would kinda be the opposite of the idea in Helix/Kakoune: one automatically enters a visual-mode-like state after typing a verb that expects an object.

Interesting idea to try out and compare. Indeed the visual feedback provides the biggest value, though to me verbs "fork" from the objects, so it's more "natural" to have some selection then decide what exactly you want to do with it, delete, or replace, or ...

Why not just use visual mode to see what you're selecting?

VISUAL always extends and clears selection on mode switching, so it doesn't fit. It's a bit challenging to explain in a brief comment, so maybe check "Improving on the editing model" section https://kakoune.org/why-kakoune/why-kakoune.html#_why_kakoun...

Kids these days and their addiction to electron smh ;)

I think I’m only scratching the service with my neovim setup. But besides the plugins that make it a bit more like a full IDE I’m using some set of core commands, heavy use of visual selection and s/foo/bar etc.

I learned a lot from this guide. I didn’t know about the f and t commands. Very cool.

> Also, any chance I get to plug the greatest StackExchange answer ever, I will: https://stackoverflow.com/questions/1218390/what-is-your-mos...

You might consider posting that link a standalone entry on hacker news. That was a very great read well worth additional exposure.

> "cdd" "@c" is effectively a finger macro for me

That is pretty much how I use vi: muscle memory :]

My usage is similar. I also use all the time

- shift - v - } to select a block, or v - w to select a word. It's not strictly needed but help ensure selecting the right stuff

- ctrl i - ctrl o for navigation

I've never been able to use tabs, buffers, multiple file edition, that's just too much overhead for me. I rely on vscode for that.

That being said, I don't think using vim gives me a competitive advantage. I'm also rather proficient using standard OS shortcut. I like vim out of laziness, it minimizes hand motion, but don't make that big of a difference IMHO.

(also lots of young guys use vim too, some younger guys in my team even refuse to use vscode...)

EDIT: also vi adds a lot of value in the terminal where standard OS shortcuts don't work, at least on MacOS (i'm waiting for comments telling me how to make them work!)

You can just use nvim _as_ the terminal itself:

nvim +startinsert -u $HOME/.i3/terminal.init.vim term://bash

A post with more customizations: https://www.balajeerc.info/My-New-Favourite-Terminal-Emulato...

Wow that SO post is really good, I'm 100% keeping it in my tool belt for dropping niche articles on unsuspecting co-workers. Thanks for sharing.

"Your problem with vim is that you do not grok vi".

Yes, that StackOverflow answer (which starts with the above line) is one of the best I have ever read, on any subject, not just vim.

(However, I should mention that I have not read, say, thousands of stack overflow answers, only in the range of hundreds, because I was never a heavy StackOverflow or StackExchange user.)

Anyway, FWIW, I think that answer could described as partly explaining the "Zen" of vi(m).

And for people who are intrigued by the benefits of vi(m) mentioned by various commenters in this thread, and would like to start using it, I have a small vi tutorial, which is applicable to vim too.

Those new to vi(m), check this vi quickstart tutorial that I created.

https://gumroad.com/l/vi_quick

From the start of a Twitter subthread I wrote about the tutorial (thread unfortunately deleted later by accident - Twitter should have an undo feature like vim, heh):

[ Those new to vi / vim, hit the ground running with my short vi quickstart tutorial here:

https://gumroad.com/l/vi_quick

I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc.

Edit: Since vi is mostly a subset of vim, the tutorial works for vim too. ]

I recently learned about the `])` motion (and similarly, `]}`), and it's probably my absolute favorite.

I used to rely on e.g. `df)` to delete function parameters. The problem is that 1. it doesn't work when the function call spans multiple lines, and 2. it doesn't work if there's a nested function call.

With `d])`, Vim will delete until the next unmatched ')', regardless of which line it's on! And to think this motion is buried under "Various motions": https://vimhelp.org/motion.txt.html#%5D%29.

Edit: an example:

  // This will become my_func(foo);
  my_func(foo, MakeBar(), MakeBaz());
             ^

In most cases `di)` is what I want, deleting everything inside the current parens, forward and back. I can see use-cases for "forward only", though.

I’ve learned to favor using c instead of d if I want to edit after deleting… it keeps things in one logical command from vim’s perspective, so that I can repeat it a second time on another line by just using `.`. Using d and then i, vim treats as two commands and thus `.` only repeats the insertion.

That's a great one, I should read the docs more often...

Two very useful ones I just saw on there, for undoing movement mistakes:

`` to jump back to where you jumped from

`< to go to the starting character of the last selected visual mode region

gv to reselect the last selected visual mode region is also often handy in my experience.

Now I'm mad at you for not telling me years ago. I've been missing this functionality since forever.

I recently saw a recommendation for Practical Vim by Drew Neil (https://pragprog.com/titles/dnvim2/practical-vim-second-edit...) in an other vim thread and decided to pick it up. It's been really enlightening and provides more than just reading documentation. It also goes in depth to how the author thinks about vim motions and how to effectively accomplish your goals with them.

I'll second this. Is an excellent book. After each chapter I recommend to take your own distilled notes. After reading the book you will get a very solid base command knowledge in Vim. What I really liked about it is that you can read it without being distracted: go immediately to the computer to test things out, this is because he painstakingly took the effort to show in pages what actually happens after each time you press a keystroke. I truly appreciated this, because you can read the book anywhere and focus on Vim mechanics without the need to try everything out on the fly.

‘. to take you back to where you last made a change

You can go even a step further using the <c-o> and <c-i>.

These will allow you to go back and forward in your jumplist.

I mapped them to <Tab> and <S-Tab>, this way I can easily move to previous locations.

This is BY FAR my most used shortcut.

I didn't know `])` but `%` to jump between matching brackets seems just as good?

In These cases I'd recommend text objects. For example,

ci)

Will delete everything inside parentheses and put you in insert mode.

Even works for HTML tags with t I think.

Edit: should be ci) to preserve the parentheses.

Text objects are cool, but `ca)` would remove the parenthesis too. There's no shorter way to get to `my_func(foo);` when your cursor is at the comma, than using the motion OP indicated.

About 20 years ago I had two computers at work: a Windows PC and a Sun workstation. I used Vim on both. I knew about the vi ]] command, and I'd learned some Vim script. I thought it would be great to have a key binding to take me to the innermost surrounding curly braces, so I wrote a vim script to do this. I picked ]} and [{ as the key bindings.

One day I used the key binding and then realized a few minutes that I hadn't installed the script on that computer yet. After some searching in :help I realized that I'd not only reimplemented a feature that already exists in vim, but I mapped it to the exact same keys.

Wow this is awesome, thanks for sharing. I used to use visual mode for this edit in particular but this feels much more intuitive and faster

"Vim as a Language"[0] is a similar article I benefited greatly from back in the day.

One additional tip once you start using things like d8k: Try "set relativenumber" in your vimrc. It makes all except the current line display offsets rather than absolute line numbers.

Initially, this seems silly, but you quickly realize that if you're at line 1668 and need to delete up to line 1619, it's much more helpful to see line 1619 listed as "line 49" rather than "1619" and having to do the mental math to figure out that the command you're looking for is "d49k".

[0] https://benmccormick.org/2014/07/02/062700.html

Folks misunderstand why Vim is so popular.

Do you prefer navigating files like a startled hamster, jabbing "alt-left" incessantly? Or like a ninja, swift and accurate?

Fancy playing Whack-a-Mole, relentlessly pounding a single key? Or Tekken, delivering insane combos with a precise 9 character sequence?

Vim is about gaining mastery rather than actual efficiency. And it's great.

When claims like this are made, I'm skeptical people have retrained their minds such that "press this combination of keys repeatedly until the cursor is where you want it to be" is easier and more accurate than "mentally count the number of word boundaries your cursor is away from where you want it to be, then enter the command to get it there".

I don't disagree that vim's movement commands have greater precision, but I find it hard to believe that that precision is actually useful in practice.

EDIT: Oh, my bad, you specifically called out that efficiency is not the actual goal. In which case - yes, for "feeling like a badass", I am wholly on-board :)

People who never master vim will never know the high of pounding combo after combo and watching lines of code morph and manifest before their eyes at the speed of thought. Once you’ve experienced this, no other editor will satisfy you. Combine this with the sounds of a clicky keyboard, and it feels like heaven.

This is absolutely true but I myself converted to vscode after getting fed up with having to maintain my vimrc… I miss the combos and no, vim key bindings are nowhere near the same, there are conflicts and missing verbs and motions.

Haven’t tried embedded neovim yet. Is it the best or the worst of both worlds?

It's reasonable. You have "true nvim" managing the buffer. Most plugins will work and it sets a `g:vscode` or whatever variable so you can conditionally enable bits of your config.

Its better than any vim emulation mode that's for sure.

I've used my fair share of macros to transform text. Vim's great for that. But that's less than 1% of my work as a developer. Much more often, I'm wanting an IDE to do things like:

* Run/debug code

* Jump to a declaration of a function/variables, or find it's uses

* Extract some code as a function

* Rename a variable (and all uses of it)

I bet vim probably _could_ do all of that with the right plugins - but dedicated IDEs do it out-of-the-box. Even something as simple as indent/dedent a block of code is "click-and-drag, tab/shift-tab" in an IDE, vs. ":<range declaration>s/^[^$]/ /" in vim.

Indent? Use a code formatter or just select the lines with visual mode and press >

> just select the lines with visual mode and press >

TIL, thank you! Unfortunately it seems to think that a

I don't think anyone actually does counting like that, or at least if they did I agree it would be silly. If I have my eye on a character I'd like to get to, I usually just 'f' + character and then ';' if necessary until I'm in the right place.

The only time I use numbers to specifically target a location is when jumping to a line. I have relative line numbers turned on (line numbers are relative to the cursor) so I always know the exact number I need to type to move to the line I'm looking at.

Mentally counting words to move your cursor to right spot isn't a great way to move horizontally. I would usually do something like "/someVariable" and hop my cursor to the exact spot I'm looking for. If it's further in the line, just hit "n". It's pretty fast. But if you just need to move one word over w and b are nice.

Even with vertical movement I never count lines. Relative line numbers make it so you don't have to. Counting is not part of my vim experience.

Agreed, I do the same.

But in an IDE, that motion is "Cmd-F, <type>, Enter". Vim's not inherently superior there.

My point wasn’t that the ability to search a file is unique to vim, but that counting words to use w or b isn’t really part of the work flow.

OK, but then I'm not clear what part of the workflow is claimed to be unique to Vim, then.

I was explaining what the workflow in question is, not claiming that is was unique to Vim necessarily.

Numbers are mostly useful in macros and scripts.

There is a Vim plugin called EasyMotion, which I absolutely love, which when invoked creates a simple 1 or 2-key "checkpoint" at the start of every word on your screen, and super imposes them on the text. Then it's only a matter of looking at the point where you wanted to move, and press the two keys written there, and there you are!

It's also fairly customizable in that you can specify which characters are actually allowed (so you don't end up with very weird keys to press), and some other stuff. So every time I need to move somewhere I can't be bothered to figure out the standard keys it would take me to get there, it saves me.

Tbh I’d swap vim with vscode if it allowed to program keys with the same ease that you can imap to keys or function calls that operate like vimscript. It doesn’t matter if an editor cannot b/e/etc if you can just program alt-b/e/etc to a corresponding action. But that’s out of reach in practice in all traditional ms-style editors.

You can use Neovim in vscode which I believe makes it effectively vim (not sure if you can bind Neovim keys to vscode actions though)

It really depends on how much of neovim do you actually use. If you just use vim navigation key bindings then the VSCode neovim mode is nice. But if you are slowly curating the editor itself over time as you find new needs and implement your own new functionality, then neovim in VS Code is not really useful for you.

> Do you prefer navigating files like a startled hamster, jabbing "alt-left" incessantly? Or like a ninja, swift and accurate?

Easy: I must prefer anything that lets me work while remembering about three or four different keys. So anything that replaces a complex shortcut with "hit an easily remembered key ten times" will win hands down.

Because the alternative to whacking the key ten times isn't doing some elegant chord, it's going through a six level context menu or googling for how to do it. Yes I have programmed for 20 years and mostly in the same editors and I still don't know anything beyond the smallest handful of shortcuts for any of them.

I think the article is missing

  ctrl-y move up 1 line without moving cursor
  ctrl-e move down 1 line without moving cursor
  ctrl-b move up 1 page, placing cursor on last line
  ctrl-f move down 1 page, placing cursor on first line.

These are really useful when looking around without wanting to edit.

Thanks, didn't know about these.

I've always used ctrl-e and ctrl-y with `:set scrolloff=2` to make it a bit quicker. It was one of the first things I learned as I found ctrl-d and ctrl-u incredibly jarring and thought there must be another option.

Like TFA I only use ctrl-u and ctrl-d since it's faster than moving one line at time and not as disorienting (in my experience) as moving one full page at a time.

It's also easy to learn since it's [u]p/[d]own.

Don't forget the handy "z commands":

  z<CR>      redraw, cursor line to top of window, cursor on first non-blank
  z-         redraw, cursor line at bottom of window, cursor on first non-blank
  z.         redraw, cursor line to center of window, cursor on first non-blank

(source: :help z)

There's also H (move to the line at the top of the current screenful), L (move to the bottom line in the current screenful), and M (move to the middle line in the current screenful).

nH is also good if you want to go to line n from the top. Works in reverse with nL too :)

I tried to understand what vim/nvim is all about and why people love it so I've learned it a little bit. I grasped the Zen of VIM, it's actually very comfortable to navigate files and files tree assuming Ctrl is swapped with Caps Lock and you don't use ESC but Ctrl+] or jk/jj. BUT. But. but... VIM was shining when it was designed and created, it doesn't shine that much today, because for working with code you need things like LSP, syntax awareness etc. Thing like VS Code with Emacs cross platform keybindins AND WITH smartSelect is amazing for me.

Go to VSCode, put it into your `keybindings.json`:

    {
        "key": "ctrl+cmd+j",
        "command": "editor.action.smartSelect.expand"
    },
    {
        "key": "ctrl+cmd+k",
        "command": "editor.action.smartSelect.shrink"
    }

go to TS file and press keybinding multiple times to see how it grows/shrinks. Having Emacs keybindings like C-w, C-y, C-d (I'm using it to move char left), C-S-d (word left, S is shift, I'm using right one) and more I feel like flying through things like selecting block, expression, function, moving in and out etc. I guess Emacs people using paredit feel something similar taken to the next level.

Ideas in VIM are still brilliant, the same goes for Emacs, but they both need to reincarnate in modern skin taking pixel perfect GUIs with proper animations to the extreme. In fully multithreaded and multiprocess environment.

> VIM was shining when it was designed and created, it doesn't shine that much today, because for working with code you need things like LSP, syntax awareness etc.

This is not true at all. Nvim has built-in LSP support now, there's a huge amount of plugins you can use that integrate with LSP and they work great. I even use ChatGPT inside my vim (check out this plugin: https://github.com/dpayne/CodeGPT.nvim). The smart select functionality you mention is trivial to implement and I bet there is a plugin for this (btw, try `dit` to "delete in tag", or `di(` to delete in bracket, etc...).

I will admit that you have to spend a lot of time to configure it to your liking, not everybody wants to and I understand that.

Honestly I feel like (n)vim is going through a renaissance period lately, check out streamers like ThePrimeagen or TjDevries for some great content on how to get started.

You're defending n(vim)+plugins, not naked (n)vim and I agree it can be taken very far and can start to look like Emacs which integrates multiple external processes in single place. Actually anything can be taken anywhere with sufficient time and effort. That's the secret of transmutation. But you won't overcome the fact it uses terminal by default which I find subpar compared to pixel perfect GUIs. Terminal UIs are useful for sure, but I see them as a hidden cry of despair when people are trying to avoid touching modern GUI systems. The strength of vim (vim motions) should be stripped away and be embeddable in any other system as a leaf, not the other way around where (n)vim is in the center and other pieces are plugged into it. I know it's happening and you can use native nvim inside e.g. VSCode which is great.

I know there are tools like GVim etc, but again, they are created with high engineering effort which for some people is simply pleasant to undertake.

Again, I'm not trying to defend or favor any system, I'm actually using at the same time VSCode (for best TS intellisense), WebStorm (for refactors), nvim (for quick browsing and small config file edits) and Emacs (for Magit). My computer is my tool, not single thing inside it.

Sometimes the world can be improved. Most times it's just fine and any suggested external change should probably start from within. There are those who like letters, words, and the sound of keyboard keys. Then there are others who like pretty pictures in big buttons and the click of the mouse.

All this to suggest that perhaps you are the wrong target for text-base interfaces.

Why did you make it personal, let's focus on talking about things/ideas.

I'm not even trying to comment your guess about what "target" I am.

But but but... your posts are about you! They're just presented as though it's a problem with the tools. I'm simply holding up a mirror, using a similar language, and suggesting that perhaps you are not the target of the tools you only dabbled with and presumed to then criticize.

Thanks for becoming a mirror (although what happened was you wrote a "mirror" comment of my comment, not me), however I'm really interested in better tools. None of the tools I know fully satisfy me. GUIs are less comfortable and slower than TUIs, of course depending on task you want to accomplish. If comes to thing like Emacs w/ Magit + evil mode which is ~(n)vim and task which is text editing or even maybe code editing - can't really find anything better more versatile and fast.

I'm interested in merging all known ideas (including Smalltalk IDEs) and moving forward.

Perhaps I have higher expectations which I didn't explain anywhere. Hard to tell full story in short text comment.

I love Vim but I also am not convinced that having more "motions" makes you more efficient.

Specifically, I think the "Javascript the Good Parts" approach applies to Vim as well : if 90% of the vim shortcuts I use only 5% of the time, it's both not worth my time to invest in learning them, it's also making invest less time really mastering the best shortcuts.

So I feel like Crockford's mindset in that JS book totally applies to vim: if you can do some motion with two keys instead of one, but using a smaller set of motions that you get to know REALLY well, then trying to remember the extra shortcuts just so you can save a key is not a good investment - on the other hand it is a great way to continue to mythologize some kind of "super efficient" developer/writer whose work somehow is made better by typing faster.

Vim is complex enough as it is. I'd love to see a really opiniated "Vim : The Good Parts¨ manual - where the author collects the most useful motions, and bluntly says "these are NOT worth learning".

I feel pretty fast with just a handful of shortcuts and I learned those for maybe an hour, years ago. Somehow I can't bring myself to learn much more and I agree that the incremental gain is probably low.

Although when writing C I also tried cscope (which is more of a search in the entire repository, not really a vim motion) and it was pretty damn useful to browse code. Nowadays I mostly use grep and find.

The problem is that everyone has a different small set of shortcuts that are useful for them.

More fun with vim.

Assume you have a vim editor open with multiple files, each of which need to have their lines lexicographically reversed. Is this a contrived example? Sure, but bear with me for a moment.

A macro can do this pretty easily and could be recorded via 'q<buffer>', where '<buffer>' is a letter. But recording macros this way can be a bit opaque. Plus, having to manually invoke it for each buffer is suboptimal.

Here is one way to do the above:

- enter the desired commands on an empty line (such as :1,$ !sort -r^M:w!^M)

- review the vim commands and refine as you see fit.

- execute the following in normal mode on the same line (to load the 'a' register): 0"ay$

- execute the following ex command (to discard loading the 'a' buffer): :e!

- execute the following ex command (to apply 'a' to all buffers): :bufdo normal @a

In this example, all buffers in the vim session will have the commands in the 'a' buffer applied (reverse sort their lines and contents saved).

I've become comfortable with using vim /within a file/, what I'm having trouble with is using vim while having multiple files open (keeping track of which ones I've saved, switching between them, etc.)

My current workflow is to have multiple files open each in a separate terminal tab, but navigating between them Cmd+Shift+[ and ] feels suboptimal.

Does anyone have any great tips? I work on Java and Ruby (rails) projects most of the time.

Less of a core vim tip, but since it's vim-style: I like to use ctrl shift H and L to move L/R between tabs in whatever terminal app I'm using.

(And since I'm open to learning other tips, I'm just going to say that this is the best method possible for navigating the tabs, period)

I have taken a while but I live in split windows. Ctrl-v to split horizontally, "new" to do so vertically. Ctrl-v them h,j,k,l to navigate between splits. I have two nice short cuts that help you open files relative to the directory of the file in which ever split you are in!!

I am not a vim expert and I usually stick to a vimrc file that intake with me everywhere and I get my zen quickly. Happy to share more.

I'm using these for switching buffers:

  " Move between buffers
  nnoremap <silent> <c-l> :bn<cr>
  nnoremap <silent> <c-h> :bp<cr>

I use Vim for development with multiple files; I find that up to 9-12 open files are manageable, but more than that and the lack of a file browser impedes me[1].

Example usage:

Open files in vertical splits:

    vim -O src1.j src1.c src2.c

Open files as I need them in new tab:

    :tabe src3.c

In new tab, open two more files (as I need them):

    :vsplit src3.h
    :vsplit CHANGELOG

I've mapped Ctrl-PageUp/Down to next previous tab/next tab.

When I want to exit, I save the session:

    :mks!

When I want to restart that session:

    vim -S Session.vim

Like I said, it gets unwieldy after around 9-12 files open (typically 3 in a tab).

[1] Nerdtree messes up my splits so I don't use it.

FZF.vim is what you need, both for opening files and switching buffers.

As an exercise to the reader, I'd recommend looking up how to use vim buffers. I'm sure a web search would yield plenty that will be useful. For example you can open all the java files in a directory with >vim *.java . All the files will be loaded in vim and you can switch between them with :bn :bp. You can open the previously open buffer with :e#.

But I personally tend to use split windows and tabs. :split and :vsplit to split a window. Ctrl w and navigation keys to move between them. Each window uses buffers the same way, so within each window you can cycle between buffers, open different files, etc...

Tabs are also useful for keeping collections of similar windows organized. Unlike a lot of other editors where a single file is associated with a single tab, in vim, a tab is just another collection of windows/buffers. So you can have one tab that is split into two windows, say for a cmake file and config file, then another tab with three vertical splits, each with a different .java code file, then another tab with a log file. (:tabnew for a new tab, :tabn and :tabp for moving to next/previous tab, or just ctrl (+shift) + PgUp/PgDn depending on platform).

And the really nice thing about all this is that you can save your vim session like this with :mksession _your_session_name.vim, close out of vim entirely, then restore your session, with all it's tabs, windows, files, etc... by opening _your_session_name.vim with >vim -S _your_session_name.vim . And you have everything back just the way you left it. I use this all the time when working on various aspects of a code base; a different vim session with all the files/tabs/etc... that are most relevant to whatever I'm working on. Need to switch tasks? Save my session, and load the one for the other task and I've instantly got everything up that I need for that task.

Vim also has a built-in file browser, so you can navigate the file tree by simply "editing" a directory, e.g. :e. will edit the current directory and you can navigate the tree and select a new file to edit by moving the cursor to its name and pressing enter. Done with the file? :e# will bring back the previous buffer, which was the file navigator.

I used to use the Ctrl-P plugin, but to be honest, these days I just use an IDE with a vim plugin. Usually if I'm in a remote terminal session, I don't have more than a few files open and can get by with :bn.

I use several things to work better with multiple files, in a tree:

1. Vim sessions: saving named sessions and restoring. (With some custom commands, see below.)

2. A plugin called BufExplorer (slightly hacked, see below).

3. My own implementation of "autochdir" (current working directory follows file).

My own implementation of "autochdir" consists of:

A variable $top bound on startup which keeps track of the original directory where Vim is executed. This is assumed to be the root of the project. The absolute path to the root is available in $top, which can be interpolated almost anywhere.

  :let $top=getcwd()

The following three commands implement the behavior similar to Vim's built in autochdir:

When we load a buffer, change to its directory via "lcd" (local cd):

  :au BufWinEnter * exec "lcd " . expand('%:h')

If the file name is blank, go to the top directory:

  :au BufWinEnter * if expand("%") == "" | exec "lcd $top" | endif

If the file is under .git/, likewise go to the top. E.g., when we are editing ./git/COMMIT_EDITMSG, we don't want to be under .git.

  :au BufWinEnter *.git/* exec "lcd $top"

For helping with sessions:

:S colon command for creating a session. Argument is a name, interpreted relative to $top (defined above). For example :S foo saves a session called $top/foo.

  :command -nargs=1 S exec "mksession! " . expand('$top/') . expand('<args>')

+ command for saving the session at any time. Overrides the + which goes to the next line (never used by me). You just hit + in command mode to save the session.

  :nmap + :wa<Bar>exe "mksession! " . v:this_session<CR>

A saved session is restarted with "vim -S <sessionfile>".

My small for BufExplorer is this. The default command for launching BufExplorers menu is the Vim leader character (\) followed by "be". I found this to be obtuse so I changed it to be \ followed by \. Thus two backslashes brings up the BufExplorer screen:

  :nnoremap <script> <silent> <unique> <Leader>\ :BufExplorer<CR>

BufExplorer is a window in which you have an interactive view over the buffers. They can be shown in various orders like most recently used first. You can move around in them, hit Enter to activate the one under the cursor, d to delete, search through them, and so on. There are other buffer managers for Vim.

I used to use splits as some of the sibling comments describe. This was helped by bindings for C-j and C-k that would maximize the split when moved to (vertically). So, I had a stack of splits and I would rearrange them for relevance to each other as needed for faster switching. But it was still tedious going up and down the stack sometimes.

Then I discovered buffers which was life changing. Suddenly I could manageably switch between 10s of files and never really worry too much about closing them. Sessions are helpful too for truly long running editing and maintaining a "workspace".

The buffer pro tips are:

- Use :set hidden

- ^ to switch to last buffer

- Switch buffers with :ls which will stay visible after typing :b and you can switch by number, or you can switch by name with tab completion (even by going straight to :b). So, I can switch to IWouldRatherBeWritingSomethingElse.java with ":b IWo<TAB>".

There are plugins to make switching even easier with fuzzy finding and whatnot but the above is all vanilla vim so you can do all this on some random cloud host anytime. I can't recommend a plugin because before really settling on one, I switched my serious development to Doom Emacs which has very similar buffer semantics and switching bells and whistles.

Check out Drew Neil's awesome Vimcasts to see buffers in action. http://vimcasts.org/episodes/working-with-buffers/

Thank you, this is helpful!

You're welcome!

One small correction: Switching to the last buffer is actually C-6 not ^ (ctrl + 6 rather than shift + 6). I realized that when actually sitting at a computer whereas my comment was typed on mobile. Whoops. It's all muscle memory by now!

One I use often but haven't seen here yet is `i(` or `i{` or `it`. Basically an adverb for "inside parentheses", "inside braces", or "inside html tags".

I most commonly use it in combination with `c` to rewrite whatever was inside. For example `ci(` will automatically delete everything inside either the current parentheses or the next closest pair of parentheses and put me in insert mode.

In this same vein I also use `a`: `a(` `a{` `at`, which I use as "around [item]".

It behaves like `i` but also includes the "container", which is especially useful with html tags as you can quickly change or delete the whole tag this way.

My favourites are A and I, finding them easier to reach for over $ and ^.

I find myself stalling sightly whenever I use f, while I try to pinpoint the character to jump to. It's the only motion I am not fluid with.

They do different things though.

I also think $ and ^ are uncomfortable to reach for, so I remapped them like this.

https://jezenthomas.com/2015/05/a-function-for-moving-to-the...

This article sadly passes over one of the most important features of vim, which is its ability to work as an ascii art editor.

To begin, open a new buffer and create your canvas: "99i<space><Esc>yy99pgg0". This will make a buffer of 99x99 space characters.

To draw horizontally, press shift-R to enter Replace mode, similar to overwrite mode in Word. To fill rectangular areas, use control-v to select the first corner, use motions to select the second corner, then r<character> to replace the block with what you need. To copy and paste areas of your art, use y and p on areas you select with visual block mode. If anyone else has any tips please let me know.

I gotta give a shoutout to `gj` and `gk` because sometimes I write really stupid loooong oneliners or just use vim to edit markdown and i want to move up and down in screen lines, not real lines.

I just came across this yesterday. While I'm pretty good at keeping my code <= 80 columns, I also write a lot of markdown where lines often wrap. Remapping `j` and `k` to `gj` and `gk` is a really nice quality of like improvement :D

(If doing such a keybind, you'd want to check to make sure count is 0 or things will get wonky for you)

Type gqip with your cursor on that long line to tame it (and neighboring ones in the paragraph). ;)

Maybe a hot take but if you want to convince people to use vim show them box select and yank and replace. It's just extremely efficient and no other editor(ide) I've used really has it by default.

Or ask them to open a 100 mega byte log file in eclipse. Even Advance IDEs simply just die. Cannot count the number of times smart diffing with vimdiff and box cutting has helped me diagnose problems that were extremely subtle. Without vim I simply couldn't do that type of diagnostics

Sames true if emac or other text editors too

An epiphany I had years ago was realizing that keyboard-based commands enables semantically dense editor interaction. Specifically, vi(m?) has a large number of commands available as 1+ letter combinations. This allows for a very large set of operations usually available within 5 or less characters.

Compared to WYSIWYG editors, the theoretical efficiency difference is tremendous.

Of course, for any given person using such a powerful editor, no two usage patterns will be the same. This is a testament as to why vi(m?) has lasted so long IMHO.

But also modal editing increases the number of such combinations. And most importantly modal editing decreases the number of modified keys (control, shift, alt, meta, two of those, ...). Your lack of carpal tunnel might thank vi and VIM, if a lack of something could be a conscious thing.

> But also modal editing increases the number of such combinations. And most importantly modal editing decreases the number of modified keys (control, shift, alt, meta, two of those, ...).

> Your lack of carpal tunnel might thank vi and VIM, if a lack of something could be a conscious thing.

I totally agree regarding how using vim as a program editor helps reduce RSI[0]. Another way to reduce same which I employ is to swap caps lock and the left control key. Not only does this reduce unnatural contortions, it also facilitates easier use of common keyboard combinations in both vi and terminals, such as:

- using ^[ instead of ESC.

- using control-based vi navigation commands (^B, ^F, et al).

- using ^M instead of return (less useful).

- making terminal control characters much easier to produce (^U, ^\, etc.).

0 - https://en.wikipedia.org/wiki/Repetitive_strain_injury

Another thing that helps is the accessibility feature known as "sticky keys". Specifically it helps prevent/reduce ulnar and other deviations. The paucity of modifier keys in vim also helps, as noted earlier.

I created https://vtip.43z.one to help me learn vim one tip at a time. It's just 3 lines of vim script that if called will show you nice tip like

Use Ctrl+n to open the auto-complete menu while typing.

Press zz to center the current line in the visible window.

Use G to move to the end of the file.

    function! Vtip()
      echomsg system('curl -s -m 3 https://vtip.43z.one')
    endfunction

Second this ^.

I saw your post on Reddit and started using it. Thanks!

I wonder if eye tracking could be used as a vim motion if it becomes really good on new vr/ar headsets. Vim is already fast, but…

That will make my eye super tired. Just looking at a word doesn't need much effort but focus on very precise location in between two character is very different. Try it with for example iiiiiiiiiiiiiiiiiiii or |||||||||||.

Actually, the presence of a cursor makes it much easier. Place a cursor and looking at it vs Place the cursor by looking at a place are very different.

Dunno about eyes, but feet sure have untapped potential :p https://github.com/alevchuk/vim-clutch

I actually did not enjoy using a vim pedal in clutch or toggle mode. YMMV

Mostly because my pedal was too sensitive and so I could not rest my foot on it.

Does anyone have any screencasts to suggest showcasing people being very efficient in vim, in action (e.g. like Gary Bernhardt)?

https://youtu.be/y6VJBeZEDZU

The most amazing thing about vim is that, even as a fairly basic user, I can read an article like this, learn a ton, and still realize that I have an easier way of doing something than the author (why use 100gg when :100 exists?).

It seems no matter how much you know about vim, there's always more.

Technically yours (<Shift>, :, 1, 0, 0, <Enter>) is one more keystroke than his (1, 0, 0, g, g) if you count shift and enter. If you don't count shift, you can also do 100G. I personally prefer :100 even though its technically the most keystrokes

That's an interesting observation. I can't justify why, but : feels a lot more fluid to type than gg, even though as you say, gg has less keystrokes and still keeps you on the home row.

It's also missing H, M, and L for moving the cursor to the top, middle, and bottom of the window respectively. You can also navigate using the % command. For example, you can use 50% to scroll to the middle of the file, 75% to go down 3/4ths of the way, etc.

Not to mention using the % key for jumping to the matching bracket. Or tree-sitter for navigating scopes

I rebind all of these keys. I don't know why but I never find this useful in vim. In tmux's copy mode I use them all the time, but ya, I can't quite put my finger on why I never miss them in Vim. A long time ago I mapped `H` to `^` and `L` to `$` but it got too annoying when I'd use Vim on a server. I've met a couple of people since who have those exact mappings, though!

I think most of the movements covered work with the Visual Studio vim plugin as well.

Just in general, when using an unfamiliar editor, having a vim plugin lets you bypass having to learn (most of) that editor’s navigation and movement shortcuts.

I really like sneak which is basically like f but with two letters, works really well.

Yes, this. Single lines don't often have the same two characters in a row (or if they do, then you can get to the one you want fast with ; ). Even large paragraphs don't often have many of the same two characters.

Sneak is amazingly fast for moving around without gumming up your search history (since one can do similar with / ).

That page is really hard to read on a desktop monitor, everything is huge and wide

Not everything - the code blocks take the full width of the page and break the reading flow so hard.

Also the font title is just huge and so bold. Even on a narrow window.

This is a little off topic, but some people might find this useful. I have bindings that allow me to execute the current line or paragraph under the cursor in the underlying shell and then inject the result into the current buffer.

  "execute the contents of the current line => sx
    exe "nnoremap " . g:leader_prime . "x :call ExecuteCurrentLine()\<CR>"

Here leader_prime is just a second leader key I use: 's', but you could map the command however you like. ExecuteCurrentLine() is implemented as:

  function! ExecuteCurrentLine()
    let l:com = substitute(getline('.'), '\#', '\\#', '')
    exe "norm! mc"
    exe "norm! o\<Esc>"
    exe "r! " . l:com
    exe "norm! mr"
    exe "norm! o\<Esc>"
  endfunction

Two more mappings:

  exe "nnoremap " . g:leader_prime . "p :call ExecuteCurrentParagraph()\<CR>"
  exe "nnoremap " . g:leader_prime . "c :call ExecuteCurrentLineWithBC()\<CR>"

and their implementations:

  function! ExecuteCurrentParagraph()
    let l:init = line('.')
    exe "norm! {j"
    let l:start = line('.')
    exe "norm! }"
    let l:end = line('.')
    exe "norm! o\<Esc>"
    exe "r! " . join(getline(l:start,l:end), ' ')
    exe "norm! o\<Esc>"
  endfunction

  function! ExecuteCurrentLineWithBC()
    let l:com = getline('.')
    exe "norm! o\<Esc>"
    exe "r! " . "echo 'scale=12;" . l:com . "' | bc"
    exe "norm! o\<Esc>"
  endfunction

As written above, I type 'sx' to execute the current line under the cursor as a shell command, and then inject the result back into the buffer where I am. 'sp' does the same, but for the entire paragraph the cursor is on; this is really convenient for things like a large sql query which is more readable written over many lines. And finally 'sc' executes the current line in the bc calculator program in the underlying shell, so you can evaluate arithmetic expressions in the buffer.

Why not just use `!`?

See my reply to AdieuToLogic.

And see my reply to you :-).

> I have bindings that allow me to execute the current line or paragraph under the cursor in the underlying shell and then inject the result into the current buffer.

As @kps mentioned in a peer comment, using the built-in ex[0] '!' command can do what the vim script above does.

For example, to execute the line where the cursor is currently placed and replace the same line's content using POSIX shell:

  :. !sh

To do the same with multiple lines I like to mark the first command, then the last, and run:

  :'a,'b !sh

Where the "a" buffer is the first command and the "b" buffer is the last command in this example. There are many other ways to specify ranges too. I recommend beginning with vim's builtin help:

  :help range

And going from there.

0 - https://man.freebsd.org/cgi/man.cgi?query=ex&apropos=0&sekti...

^ What they said. (I was terse on my way to bed yesterday.)

The big benefit of `!` is that, like anything else in visual mode, it works with motion operators. I often write fragments of shell, e.g. to generate something repetitive, and run it with `!!` (doubling for the current line, same as things like `dd` or `yy`), `!}` (block), or `!G' (rest of file).

First, I don't want to type <shift><semicolon><period><space><shift><1><s><h><enter>. I want to type at most two characters, because I do this a lot. I chose sx, but really any good <leader><foo> combination would be fine. Note they're both on the same hand; I had pretty bad rsi for a couple years and was typing almost exclusively with my left hand.

Second, :. !sh eats the command. I want the command to remain in place in the buffer. Imagine you have a buffer full of useful commands that you use repeatedly with minor tweaks, and you use the output of those commands to write other bespoke commands, and so on.

Third, :. !sh leaves you sitting above the result of the command. I rarely want to be there. I want to be positioned right after the result, on a new line, like my buffer is a shell-- I see the end of the result and can immediately begin typing the next command.

>First, I don't want to type <shift><semicolon><period><space><shift><1><s><h><enter>. I want to type at most two characters, because I do this a lot. I chose sx, but really any good <leader><foo> combination would be fine. Note they're both on the same hand; I had pretty bad rsi for a couple years and was typing almost exclusively with my left hand.

> Second, :. !sh eats the command. I want the command to remain in place in the buffer. Imagine you have a buffer full of useful commands that you use repeatedly with minor tweaks, and you use the output of those commands to write other bespoke commands, and so on.

  map <leader>sx yyp:.!sh<CR>

> Third, :. !sh leaves you sitting above the result of the command. I rarely want to be there. I want to be positioned right after the result, on a new line, like my buffer is a shell-- I see the end of the result and can immediately begin typing the next command.

  map <leader>sx o<ESC>mtkyyp:.!sh<CR>'t

HTH

> None of these are my favorites but they’ll do for the time being. In the custom mappings chapter, you’ll learn how to create a custom key binding for the ultimate mid-range vertical motion.

Yeah, vim defaults are bad, so it'd be better to teach the improved keymap rather than wasting time learning the ones even author doesn't like and then learning how to remap them

It's a pity vim is so inflexible with keymaps that it ships with only one by default, making the step above harder

(also, "melodies" are chords, and the other ones are just combos)

A bit off-topic, but I only recently discovered these and found them pretty useful for navigating big codebases:

    c-w-|  zoom in a particular window
    c-w-=  zoom out

I'm wondering how many people know this and if they use it or have a better way of putting other windows at the background for a while.

What do you mean by zoom?

`cw |` is change word and then types the pipe character.

`Ctrl-W =` is "make all windows the same height & width"

`Ctrl-W |` is "set window width to N columns"

I'm a big vim user but I disagree with the notion of being faster with it. It's usually not so much the motions themselves that work, but rather the ergonomic shortcuts for everything else (like LSP functions, nvim-harpoon fzf)

Frankly, I'm just too used to the vim motions now to be good at other editors.

Lots of good stuff. I use most of these already when I am reading through files or making quick edits but in the terminal.

I have never found a use for counts. It always feels like my brain slows down. Relative line numbers helps a little. I sometimes try to estimate counts but it’s also kind of annoying.

Never really got into Vim. I grew up on Emacs a happy with my Doom-eMacs setup.

But recently discovered the Vimium extension for Chrome and wow it is a life changer! It is what I have always been looking — a noiseless way to quickly go to any tab, history or bookmark.

For me, the killer vim feature, apart from navigation of course, is macros

And here I am, hitting the numeric row "1234567" and h, j, k or l because I never leaned how to move to the beginning or end... and i can't get the muscle memory out :(

If you're actually interested in getting some of that muscle memory, my suggestion to people just getting started has always been to simply force yourself to use vi(m) for whatever you're working on and only learn one or two new things at a time. Say you've just learned gg and G to move to the beginning or end of the file. Whenever you find yourself wanting to move to the beginning or end, use your new command. Don't try to learn any more until gg and G have become second nature (or unless you find you don't really use it often enough to justify committing it to memory; it will happen). Then figure out what your next biggest slowdown or frustration is and figure out the "vim way" of doing that and add that to your repertoire. Rinse and repeat. If you do even a moderate bit of coding, it really doesn't take long to learn enough to improve your speed/efficiency. It may feel slow and frustrating at first, but in my experience, and for everyone I've "coached" on vim, it's a pretty small hump to get over if you just stick with it.

By the time you've got 20+ years doing this, you'll have a workflow that is extremely well suited to your needs/preferences. And that's the nice thing with vim; it will always have room for you to expand your skills with it, but you don't have to know even close to all of it to benefit from it. Use what fits your needs and what helps; the rest is just candy.

> And here I am, hitting the numeric row "1234567" and h, j, k or l because I never leaned how to move to the beginning or end...

To navigate I use a very reduced set of commands:

Shift-A, Shift-I (insert at end or beginning of line) o, O (insert line below, line above)

For everything else, I use /<snippet> or f<snippet>.

Try playing this: https://vim-adventures.com/

It's great for learning the muscle memory of basic motions.

The nice thing about vim is all modern IDEs have vim movement plugins. Once the movements become muscle memory you can keep using them in new environments. Nice!

They come close.. Then you start running into discrepancies which become really aggravating. I've never been a NeoVim user but probably the best solution is to embed it in an IDE rather then reinvent the wheel badly.

If a Vim plugin could analyze what I do and suggest commands I don't already use that would save me time, that would be fantastic!

I use the leap plugin quite a bit. I can look anywhere in the buffer and jump there with 3 or 4 key presses. ggandor/leap.nvim

I was in awe of a friend using vim, I asked him how someone could possess that power, he promptly gave me a license of https://vim-adventures.com/ and now I can't use any other editor that at least have a vim plugin.

Give the game a go, totally worth it if you want to ease into learning vim, after some time try and use it for everything, even if it fells slow, persist and it will be worth it.

Someone should implement an editor for Apple's Vision Pro that moves the cursor using eye tracking.

back in the university days, I could get an extra hour on my CS assignments if I went to the library and connected to the systems on a green VT100 terminal.

Vi was the only editor available, so I forced myself to learn it. Still using it to this day.

So that's what they mean when they say you need to exercise your core

Any one knows how to jump to the beginning of the pasted text?

`[ will take you to the beginning of the last changed text (including pasted) and `] will go to the end. You can also go to the last edit with g; (g, is its opposite).

Wow. Thanks for the answer. It worked. `[ is what I've been looking for so long.

I've recently discovered vim and I've been using it ever since, mostly because I don't know how to exit it.

- Obligatory joke on every vim thread.

wow, no one mentioned, gm. The middle way, all day long.

I prefer H, L, zz.

To move fast, use the mouse[1]. Trust me. I've played that game of always trying to find the most efficient way to target something on the screen in Vim. If you haven't already learned about EasyMotion, tried it, and gave it up, you probably haven't tried to perfectly optimize your movement in Vim. It's not a game worth playing. Figuring out how to navigate your screen with the keyboard is a Vim problem: editing text now is something you have to think about, a lot.

[1]There is no conclusive evidence that Vim's motions help you type nor navigate faster

Part of the appeal for me is not having to move my hand to the mouse and back.

It is simply not possible for me to disagree harder with everything you said.

I don't think at all about editing text. Using vim is so natural, and so, so much faster.

I watch my mouse-bound colleagues when they screen share on an almost daily basis. It's painful to watch. I am far faster with vim.

My impression is that Vim feels faster (busier hands) but most likely very similar actual speed to a proficient VSCode/Intellij user with shortcuts and mouse.

I find myself enabling and disabling the plugin every now and then. It feels fun until it conflicts with my VSCode use and I remember that the objective is not to use Vim but to work on the code, deliver my tasks, etc.

Hi throwaway, ask your mouse bound colleagues to rename the file they're editing, then do it faster in Vim ;) I'm just kidding, hopefully you were sweating a little though.

I'm a Vim power user as much as anyone, and multiple cursors replace 80% of complex editing tasks in Vim (and are way nicer to work with over macros, because you get instant feedback), and a good IDE replaces the next 15% of what I use Vim for. Vim is a text editor, not a code editor, and I mostly work with code.

For the other 5% of what I want to do, I don't really miss it. Like using q: (meaning q-colon). A critical shortcut to use in Vim, if you don't know it and q/ you probably shouldn't be using Vim, but I don't really miss it. In fact pressing up/down arrows in VSCode's search box and command box do the same thing, now that I think about it.

My sweet spot right now is Vim + i3 (or sway) + udxvtd and a fixed trackball on the desk

> udxvtd

Is this a typo or something really slick I need in my life? Getting zero hits on google

It might be urxvt (rxvt-unicode), a popular terminal emulator.

It’s a typo. It’s urxvt but with daemon mode: urxvtd so new terminal windows start faster.

When you first starting Vim motions you’ll be putting thought into it, because it takes time to develop your muscle memory and learning where the motions are useful. But once you get going, it feels so much faster than using a mouse.

Just being able to use a keystroke to copy or replace text inside a set of parenthesis is so much faster than clicking and dragging your mouse cursor inside the set of parenthesis.

Not sure who is collecting the data on Vim motions being faster than mouse, but just from experience it feels way faster and more satisfying than using a mouse.

its not about perfect movement. Its about keeping your hands on the keyboard, fewer keystrokes (over using arrow keys), and being more precise. The idea also isnt to think super hard about what to press next, the movements become 2nd nature, so you're barely thinking about them. sorta like when you type a sentence you dont think consciously of each character, your brain mostly relies on muscle memory to reach the keys necessary.

edit: before i get flamed, im NOT saying you NEED to use vim to be the most productive. The best devs on my team DO NOT use it. So its not necessary, but it is a lever some can pull and benefit from.

also, your quote/citation doesnt provide any value. Just because there isnt a study on vim doesnt mean it doesnt increase productivity..

Using the mouse only really works in Acme, every other editor makes you switch between mouse and keyboard way too much. The mental and temporal overhead of switching makes it severely unoptimal. Maybe it would work better using (left|right)-handed Dvorak or a Mother-of-all-Demos-style chording keyboard.

It's not one of the other. You can definitely use a mouse _and_ vim. I wouldn't recommend easymotion to anyone, a mouse is just so much better suited to that sort of behaviour. But there's plenty of motions much better suited for vim bindings, such as change the text up to the next bracket with ct( or changing the contents of a string in ci" and just e and b instead of alt arrows. I think people can just get carried away with "my hands will never leave the keyboard" but it's fantastic having the best of both worlds with vscode + neovim extension

I don't know vim. I can type reliably at around ~120wpm and ~150 if I concentrate and it's standard prose. I can't edit code as fast as VIM users and I know this is true, I keep wanting to learn VIM so I can, but I also just plain can't be arsed as it's not the bottleneck necessarily for me it just makes some editing actions more tedious not knowing VIM.

Great examples of this I see regularly watching coding streams are what look like "macros" that replay the last editing actions. Seems super powerful when replacing a word etc (and not all languages have proper support for variable renaming etc).

I do believe the arguments about using vim for productivity gains are somewhat silly. I probably spend most of my time thinking about code rather than typing/editing it. However if I want to convert a thought into code, I can do it very quickly.

That being said, using vim is just so much more comfortable. When I want to move to a certain location in a file, I don't think about what I want to do. The movement comes out of muscle memory, just like I would move my limbs to walk over a large rock in a challenging terrain. I think that comfort of being able to keep my hands on home-row and quickly jump to anywhere on the screen and beyond is what really sold me on vim. (I've been using vim for about 5 years and it probably took at least 1 year to get to this level of comfort.)

In that sense, I can fully understand (predominantly) Windows users preferring their mouse as they choice of movement - but I do look down on them with a certain sense of imagined superiority.

Oh, you said the quiet part out loud. And as a happy and content mouser, I actually used to get a bit triggered by vimmers condescending tone. But I found that I could read this thread without being either jealous or provoked. Takes all kinds.

I found easymotion is a bit disjointed, but between sneak (a two letter motion similar to f such that you can do ; and , to go next or back) and /<search> I find I can get places very quickly

It is extremely frustrating to see a post downvoted just because it is a diverging opinion, especially when it contains some of the best advice in this thread.

Indeed, for random access on screen, there is no better alternative than the mouse or trackpoint (the latter defeating the non-argument about moving your hand, since it is literally in the middle of the home row), that is what it was designed for. And if for whatever reason you don't want to use a trackpoint, install EasyMotion and map the random access motion to spacebar or another big key as I have done. It is the second best way to achieve random access on screen.

For more structured motion/editing tasks, I am perfectly happy with Vim's advanced motions on text-objects. But random access is still a very common task, and trackpoint or EasyMotion is just both faster and more "ergonomic".

> "Indeed, for random access on screen, there is no better alternative than the mouse or trackpoint"

There should be. Touchscreen. Eye tracking. With a mouse I have to go via a silly walk[1] moving my arm and scraping a chunk of plastic over a desk as a proxy for scraping a mouse pointer over the screen. With a keyboard I have to invent a magical incantation of button presses to poke the state machine and make the cursor do a silly walk over the lines/rows/words/brackets/search term/etc. from where it is to where I want it to be. Why can't I look and "go there" directly without either silly walk?

[1] https://4.bp.blogspot.com/-53TOKiAMoow/VD0EeGQ24oI/AAAAAAAAW...

Good point, touchscreen is even faster. Eye tracking may be hard to make work properly (false positives, false negatives, invalid actions...), but would indeed be the fastest.

Dan Luu has a blog post about this: https://danluu.com/keyboard-v-mouse/

Conclusion: "Unlike claims by either keyboard or mouse advocates, when I do experiments myself, the results are mixed. Some tasks are substantially faster if I use the keyboard and some are substantially faster if I use the mouse. Moreover, most of the results are easily predictable (when the results are similar, the prediction is that it would be hard to predict). [...] This result is so boring that it would barely be worth mentioning if not for the large groups of people who believe that either the keyboard is always faster than the mouse or vice versa."

Reply on news.ycombinator.com