I love vim. I am not one of those users who has a huge number of plugins and takes part in an extended eco-system that they perhaps do not fully understand -- for the last ~20 years of my life I have been trying to learn a little more vim each time I use it. I often don't, but it just has so many surprises that when I feel frustrated, I try to work out the "vimmish" way of doing things. Occasionally I give into temptation and take this to extremes -- for example, writing macros that look like alphabet soup to make certain coding tasks easier. I'm never sure if this is really a good use of my time -- but I do enjoy it. I'm so grateful it exists -- it's everywhere, insanely fast, lightweight, and I've never crashed it.
Now, if there is one feature I would add to Vim, it would be "cat detection". I have a ginger cat that is irritatingly in the habit of jumping on the keyboard when he wants food.
You can only imagine how, in command mode, he effectively summons the textual equivalent of the Nine Hells of Ba'ator upon my open documents if I am not quick enough...
> You can only imagine how, in command mode, he effectively summons the textual equivalent of the Nine Hells of Ba'ator upon my open documents if I am not quick enough...
Honestly this is single-handed my favorite thing about vim.
Not the ability to fluently traverse through text (and apparently time).
But that you can use it for a almost decade, and still have a stranger on the internet blow your mind with simple features you didn't know existed.
There's so many of those one-off commands that are so useful, yet you've somehow never heard of them?
crazy thing with vim is every person I've seen uses a different subset of functionality, which always contains a few things I've never seen before. Which is also pretty cool in my book. No two people use vim the same way.
Am a similarly profiled (neo)vim user .. but without cat. Sometimes I catch strange letter combinations like "gqip" in my emails that baffle the recipients. Want vim keys everywhere!
A friend of mine I met through my own similar (free) library is developing this like a madman: https://kindavim.app
It costs $3/month (coffee) but for a Vim person like me I gladly pay. Making this work across macOS is a total mess and a full-time job, and it's not trivial work.
If you want a free version, I have https://github.com/dbalatero/VimMode.spoon as a Hammerspoon plugin that works pretty OK, but I'm not actively developing it and prefer the kindaVim app at this point.
Dang that’s cool, I used tridactyl a bit in web browsers and it just got too messy in a browser (in addition to the new key bindings).
In theory I support this endeavor but one of my biggest annoyances is when applications “overwrite” default/expected keybindings (looking at you excel web app).
It seems to me a large part of web accessibility is being able to navigate a computer without even a mouse (hey that’s what vim does) but I really wish there was full OS support for this (seems to be the goal for kindaVim?) opposed to a “layer”.
Certainly best of luck and cheers to the development efforts - have taken note
This is me all the time. The worst is “kkk”. I can’t remember why I type it in vim (it’s muscle memory, and I’m not at a computer to try it out), but it has really bad connotations here in the US south, so… no bueno.
Unsolicited advice for scrolling without spamming j and k:
- C-u and C-d to jump up/down
- [ and ] to go prev/next empty line (I have a macro to clear empty spaces at the end of lines so this works well for jumping functions in code)
- from the article: 50% to go the halfway point of a document
- 100gg to go to line 100
- 100k to go 100 lines down
Are there any more good ones?
Edit: occurs to me that you might have remapped kkk to escape normal mode. At one time I had done this for jj. Now I just use C-[ as it’s portable to vanilla vim setups and less of a stretch than the escape key.
The line the cursor is on is now shown in the left sidebar as 0, counting up for each line away from the cursor. So now it tells you what number to use for "10j" and "10k" to move up and down a specific number of lines.
m[a-z]
`[a-z]
Mark a point in a file into a register, and jump back to that point. Or even more interesting:
m[A-Z]
`[A-Z]
Same as above, except capital marks are global and work across files.
Also,
``
Jump back to the last place you jumped from (but only within the same file).
My only problem with relative line numbers (and I use them despite this) is working with ranges of line numbers. For instance, I'll maybe be doing some refactoring and want to see what it looks like to move lines 127,137 to my current cursor (127,137t.). With relative line numbers I have to do some quick arithmetic to sort out the range.
H, M, and L will move the cursor to the top, middle and bottom (respectively) of the screen. That is, H moves the cursor to the top visible line on the screen, L to the last line currently visible, and M to the middle. Cursor moves but text does not.
zt, zz, and zb are similar but move the text not the cursor. So, zt will take the current line the cursor is on and make it the first visible line on the screen (and keep the cursor on that line). zz to the middle, zb to the bottom.
Personally, I use [ and ] to jump around most often in code, but the above are handy when you are working with documents.
I like using L and H to go to bottom or top of screen to initiate scrolling with j or k. You can scroll up or down without moving the cursor using Ctrl-Y and Ctrl-E but I find those a bit hard to get used to.
I think I meant to write { and } (which is previous/next empty line) instead of [ and ] which can be combined like [( ]) or [{ ]} to go to the beginning and end of parentheses and curly brackets respectively. % is good for jumping between matching parenthesis... I wish there was something like this for *ml tags inbuilt (e.g., go to matching <div> <-> </div>)
Every time my fingers have to leave the home row I feel pain. Mostly from knowing that I’m likely to typo straight after, or have to remove my gaze from the screen to check my fingers and then find my position on the screen again. It really breaks flow and that flow was a big motivation for me to start using vim
Not only in the US south. In Germany, there is a health insurance called "Kaufmännische Krankenkasse", and when I first saw their name abbreviated, I wondered why it was written KKH for about half a second...
I’ve used vim for decades and have utterly failed at switching away every time I tried to. I miss everything about it too much. My only real complaint is I have a hard time using IDEs, because my vim muscle memory is too strong and despite many offering vim key bindings they never offer all the features/keys I typically use. Often missing are recording/playback, visual mode, anchors, vim’s (unique) regex syntax, buffer manipulation, etc.
In my experience it's rarely the best of both worlds, it's more of a case where the IDE becomes more tolerable.
The problem comes in when the IDE struggles to keep up, or is busy trying to move my cursor somewhere that I don't want it to be.
IntelliJ is really bad about this, I'll often type something and hit esc to go back to normal mode. Mentally I'm moving to another line using a Vim motion, but IntelliJ lags, and eventually moves the cursor to some problem it thinks I need to solve right now (and I might or might not be back in insert mode).
It's frustrating, but probably less frustrating than not using the Vim bindings. Maybe it's something with the Vim plugin, or something I've done. It's more of a minor headache as opposed to a migraine.
> The problem comes in when the IDE struggles to keep up, or is busy trying to move my cursor somewhere that I don't want it to be.
Agree completely. Even completely common Vim actions are often just way too sluggish. Not to mention I've remapped "<Esc>" to "jj", which is often unsupported by Vim extensions.
This is before even mentioning all the "helpful" features like parenthesis-completion that IDEs like to foist on me. Word processors don't try to insert matching double-quotes, why do I want an IDE to insert matched parens?
Extra kudos for mentioning on which Fish Disk (https://en.wikipedia.org/wiki/Fred_Fish) the first published version of vim could be found. I still have fond memories of poring over a list of Fish Disks and ordering those that sounded interesting by mail order. Those were the days...
I don't know exactly when I started "porting" vim into Linux on the Web (it's actually a complete rewrite in JS). It's been a few years at least. You can play with it by going to http://lotw.site/shell and then entering `import fs && vim` at the prompt.
(A tip... if you do `echo "import fs" >> ~/.bashrc`, the 'fs' command library—which contains the vim command—will be automatically imported into the current shell's execution context.)
If Vim was a GUI application (and could smoothly handle long lines), it would the perfect editor for me. Alas, the best I've seen so far is Neovim's discontinued GUI frontends.
What's wrong with the way it handles long lines? It can either wrap or not wrap depending on your configuration. Personally, I disable wrapping in every editor I use because I find it extremely off putting. I'm curious which behavior you desire and if you have any examples of editors that you think handle long lines well.
Another issue is scrolling visual lines one by one that have been wrapped. (N)vim can only scroll by literal lines, so if a line is longer than the screen and wrapped, there is no way to step through line by visual line.
That’s strange. I just tested it and both GVim on windows and vim on a vps linux terminal have no problem with going anywhere on a 170k long line. It lags a little but visually is fine.
And just in case you missed it, you may gj gk to navigate visual lines or remap j, k (and <Up>, <Down>) to gj gk to make that default.
I have a genuine question why use nvim at all if it has such issues with presenting text in a window.
Performance. I mean really long lines, not merely lines which exceed window width. Vim is a bit better at that than Emacs, but it still slows to a crawl on some large lines. Sublime Text e.g. never has any problems with long lines on the other hand, no matter how long.
With wrapping or without? I occasionally use vim to open up minified JavaScript files to follow stack traces when sourcemaps are broken. I'll open the file and do something like 515328l (go 5153281 characters to the right) to get to the correct place and have never had issues.
When we broke our sourcemaps for a bit, I was the dedicated human source map for a while and vim was an absolute life saver.
Which discontinued Neovim GUI do you mean? As far as I know, while there are lots of discontinued ones, there are also several actives ones, see [1]. The "Activity" column in the linked table doesn't always show the correct age, e.g. vimr [2] is at least three years old.
I was mostly thinking about Neovide[1], which is active, but I've read somewhere that Neovim was planning on not supporting this idea (of multiple GUI frontends) and that they were going to focus on the terminal UI. Maybe that was wrong though, since it's still listed on the Wiki you linked, and Neovide is still getting new commits.
Neovim is not developping GUIs themselves, but they are actively maintaining the API these GUIs use. It's even listed as a feature on their homepage[0].
It's still a TUI. I would like Vim to be able to e.g. draw a normal line instead of changing the background of a column of characters, when cc is set. Also not needing to patch fonts to get things like powerline. That and other things of this nature.
A GUI can draw vector graphics, like lines, arcs, arrows etc. GVim still behaves like a terminal, which just has a grid of characters to work with. Any such vector graphics is done awkwardly with fonts, which doesn't give the best result, and patching fonts is not the best UX.
Thanks for further clarification. I haven't needed such capability in a text editor, but probably I should look into what that provides.
And I don't see how such features are necessary to rule GVim as GUI. I have a fairly basic classification: TUI runs in a terminal, GUI have their own windows.
GVim is a GUI in the same way that a terminal app is technically a GUI. It is surrounded by GUI chrome and has menus and such, but you are working with unstyled plaintext as you would in any other terminal window.
Put this another way, you can tell the difference between something like vim and Emacs versus Kate and Microsoft Word. It is not necessary to get into the minutia of what makes all these text editors different to understand that they are fundamentally different kinds of applications. The former two are clearly terminal apps with GUI chrome around them, the latter two are clearly GUI apps.
Think what you're asking for is a vim interface built around arbitrary mouse usage and discovery, the latter being of utmost emphasis I presume. And yeah, it's a valid complaint that vim GUI implementers seem incapable of getting to that level and just put chrome around what is essentially a TUI instance.
Lack of mouse-led discovery likely also contributes to vim veterans being surprised that vim has this or that feature. TUI-orientation is quite tenuous when it comes to discovery of behavior. The whichkey family of plugins[0][1] is an interesting experiment in combatting this, but does nothing for the large case of commands that aren't mapped to a key by default, like the example of the 'earlier' command mentioned higher in this thread.
I use it as well, it is not 100% compatible, but all the main features that I need (basic things) works fine for me. If somebody stuck with vscode but wants vim key bindings I hightly recommend to try it.
What I noticed that people build "their own" IDE installing and configuring third party plugins and spend a lot of time to maintain this configuration. And there is no guarrantie it will be better then what is already supported in vsCode for example. So as an alternative one can go other way around and just install vim plugin.
It's just a terminal really, still a TUI. I would like Vim to be able to e.g. draw a normal line instead of changing the background of a column of characters, when cc is set. Also not needing to patch fonts to get things like powerline. That and other things of this nature.
Neovim is teen-cool, but seemingly gui was not their priority at all for years. Unless you’re trying to configure vim as vscode for some reason, don’t bother yourself and use gvim on linux/windows or macvim (mvim) on mac.
Or maybe I’m missing something here too, what “gui” means for you?
Edit: oh I see from other comments. No, this type of gui vim doesn’t do.
I don't use many plugins. But there's 2 plugins I find very useful.
* Use an LSP client plugin, whichever you prefer. It's better than any ctags circus you can do. coc.nvim is more feature rich but also heavier. Vim-lsc if you prefer more barebones.
* FZF.vim; fuzzy searching files as well as lines in same file.
On a related note, does anyone know proper parenthesis / bracket completion plugin? I never got that functionality to work as good as IntelliJ.
I was a Pathogen user for a long time, from about 2009-2020. It was a total gamechanger. I'd still use it except for the fact that with vim-plug I can more easily keep my config under version control. git submodules are a hassle.
One can add "vi.el" (approx 1985/86) and "vip.el" (approx 1986/87) to the list too. Both of these were obsoleted in 2014, but are still distributed as part of Emacs.
Just opened Emacs in evil mode, and asked it to summarize the report back to front. Noticed a cloud of black smoke in the room and emacs asking me something about trading my soul for improved keybindings.
Now, if there is one feature I would add to Vim, it would be "cat detection". I have a ginger cat that is irritatingly in the habit of jumping on the keyboard when he wants food.
You can only imagine how, in command mode, he effectively summons the textual equivalent of the Nine Hells of Ba'ator upon my open documents if I am not quick enough...