Hacker News Reader

Comment by auto | Hacker News Reader

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...

View on HN

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.)

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.

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

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...

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.

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.

"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. ]

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.

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...

> 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 :]

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.

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.

Reply on news.ycombinator.com