I found myself coming home to vim recently, as well—I just now call it [helix](https://helix-editor.com).
Cuteness aside: for all the awesomeness that a tailored vim setup provides, I haven't been able to keep one stable since a decade ago, when I used an ubuntu desktop for work. Maybe I'm just getting old, but Helix's batteries-included approach to reimplementing vim has resulted in a much better experience for me in practice, even though it's lost me some features in theory (I miss you, vim-fugitive!).
> And my hands can't even tell it's not vim…mostly!
How? Helix is <noun> → <verb> whereas Vim is <verb> → <noun>. I'm used to deleting entire sentences using `das`, but the order is completely the opposite in Helix.
Legit—`da` and `di` are the ones that trip me up the most.
Edits much simpler than that are often the same keystrokes as vim (`A`, `C`, `.`, `/`, etc), and those much more complicated would have kicked me into visual mode anyway.
I like the idea of using "<motion><verb>" instead of "<verb><motion>".
Though, when I was first trying it out, enough of helix's keybindings conflicted (or were different).. it definitely takes a bit of effort to adjust. (e.g. I like vim's `$` to go to the end of line, but helix uses this for "filter through shell command". Helix uses gh/gs/gl instead of 0/^/$; which is arguably nicer).
Oh come on now that's can't even be close. Surely vim supports and order of magnitude more languages than vscode at least. I actually haven't found one without vim support yet, including a dozen assembly languages, verilog & vhdl, various horrible proprietary scripting languages and so on.
Does vscode use vim syntax and script files to try and match that or something?
The (clearly a bit facetious) question was not "is it possible to implement syntax and script files" but "is VSCode able to read vim's syntax and script files", as the ability to do something isn't equivalent to something already having been done.
It's a very high percentage for syntax highlighting itself (which is most of Vim's focus) if you include the deep extension library. The primary tokenizer VS Code uses for syntax highlighting is based on the TextMate Grammar format [1], which is a pretty wide industry standard of sorts today. A lot of grammars have already been expressed in TextMate Grammar format at least somewhere. The TextMate Grammar format is conceptually very similar to vim's: it mostly keys off of simple regular expressions to define token boundaries. The biggest difference is that TextMate Grammars are expressed as declarative JSON files and vim syntax grammars are expressed in vimscript. The vast majority of vim syntax grammars are very easily convertible to TextMate, though vimscript is Turing complete and there are some strange ones out there.
Today VS Code also allows for Language Server processes to entirely delegate syntax highlighting as well, if you do need a very custom turing-complete tokenizer. (More accurately, it is included so that Language Servers can share the tokenizer work they are already doing as part of their parsing and processing efforts rather than duplicate that effort in a TextMate Grammar.)
Wrapping a TextMate Grammar in a VS Code extension is one of the easiest types of extension to build for VS Code, it's just the grammar JSON file and a couple lines added to an appropriate package.json file added to a ZIP file that then ostensibly resembles an npm package.
Deeper projects such as Language Servers start to get complicated quickly, but also are where a lot of power that VS Code has that vim is starting to import the other direction: many neovim users rely on Language Servers ostensibly built for VS Code first for an increasing number of language features.
I love vim modal keybindings more than Vim, I don't really use actual vim much at all, certainly not for coding. Luckily most editors / IDEs have Vim support
This was my experience as well. I really tried to use the vim plugin for vscode but there were too many behavior differences between it and native vim. And VSCode just has too many features that I've grown to love that I just find myself learning the native VSCode bindings and using those most of the time now.
I miss VIM, I really do, but I really only use it these days if I need to ad-hoc modify an individual file while I'm in a terminal somewhere.
I use it but it's typically a source of problems to the point that I have to save everything and restart my session. You can have very, very little custom neovim configuration present. My vimrc checks if it's inside of VSCode and does nothing but I still frequently encounter problems. Weekly, at the very least. I'd love to get outside of VSCode fulltime but where I work today uses Docker for development and it's a complete pain in the ass to connect text editor plugins with services running on a remote host. VSCode has this out of the box, so it wins. My next job, I'll be sure to press for this level of detail about the development experience.
I've heard plenty of people say this and I just don't understand it. I use vim bindings in VS Code 95% of the time but the 5% of the time that I use real vim, it all works exactly the same
Admittedly it's been a while since I tried vscode, but when I did my experience was that vim's functionality is a superset of what's available in the plugin. Especially if you learned on the plugin, vim would generally work the same as vscode.
The issue was the other way--there was functionality missing in the plugin, or sometimes when you tried to compose more complex operations they didn't work or worked strangely, etc.
Like, if you're used to working in C you won't see the advantage of a C++ compiler, but if you've spent 15 years working in C++, you're gonna feel pretty hamstrung by a C compiler.
Can you give me an example of something that doesn't work correctly? I'm not an expert but I'm pretty sure I know all of the movements and basic verbs and they all seem to work fine to me. I believe you that there are missing features but I'm wondering what I'm missing out on
I've got the VSCodeVim extension installed, some other people have mentioned one that is backed by the neovim folks so maybe that one is better.
imap/nmap don't seem to work -- I think I'm an intermediary vim user in the sense that I don't have all the shortcuts memorized. So it can be useful to just throw together a macro to encode an idea like "change the parentheses to brackets around this variable and then go to the next search result."
I'm sure there's a built-in command for this sort of thing but I don't have it memorized, so what I'll sometimes do is just perform the transformation manually once, keep track of which keys I hit, and then nmap that to some random key.
Before, my gripe was that visual mode didn't work, but they added that (yay!).
Are you familiar with vim q macros? It's a similar thing but you don't need to use maps/remaps to use them: q<letter> to start recording and q (in normal mode, so <Esc>q sometimes) to stop recording. Then you can rerun the macro with @<letter> (or @@ is rerun the last macro). (Even fun things like <count>@<letter> work to rerun the macro a number of times.)
VSCodeVim seems to support q-macros just fine. The lone silly missing bit is that VSCodeVim makes it slightly tougher to save/reuse q-macros than proper Vim [1]. In Vim those letters are the exact same "registers" as copy/paste so that you can record a macro to register 'a' with `qa…<Esc>q` and then if you want to save that macro for later you can just paste it into a document somewhere `"a` (paste register a) and pull the macro back in with the right motion and yank to the register you want (`<motion>ya`). VSCodeVim unfortunately uses separate registers for now and it is a bit more work to save/restore q-macros.
When I was a novice first starting vim I was given great advice that I followed for many years: avoid custom mappings. It's tough to learn vim if you confuse its mappings.
When I was an intermediate user of vim for several years I had drastically custom mappings because I thought I knew enough and knew better. I thought I had a good excuse, too: I was using a different keyboard layout and I might as well remap everything.
As an aged user of vim, I can't call myself "advanced" or an "expert" user I don't think, I've returned to the wisdom of the sages: avoid custom mappings. I still need some moderate remappings for my keyboard layout but have come back around to "the less I remap, the better".
You can do equivalent configuration with the extension settings but I can see how not having imap/nmap could be annoying. However, macros work just fine. I use them all the time. Press q and then another letter to start recording a macro for that register. Press q again to stop recording. Then you can type @<letter> to replay the macro
1. When opening a file that is already open in another editor in another terminal, Vim gives me many options, but it doesn't give me the option to kill the other process (or ask that process to save its buffer and exit).
2. My .vimrc should really follow me around automatically. Too often I find myself installing a new machine and missing my settings. I don't know how it should be implemented, but this is something that should work. Edit: if SSH can pass the DISPLAY variable around, then it could do the same with (a key to) .vimrc. Once a .vimrc is associated with an account, it will stay there, so if I log into the machine from the console, I should have my .vimrc (this also happens to the .Xauthority file, although less useful). This could also apply to other settings, of course. And it would be even better if my Vim binary followed me around too, but this is perhaps too futuristic.
A .vimrc is literally one file, and we've come up with lots of solutions for moving dotfiles around easily. Some jank, some not. But it is a hundred million miles out of scope for vim to implement some kind of sync. That would require accounts, databases, all kinds of tedious details an OSS project does not have the resources or volunteers to do.
Invoke your local editor and edit the remote file. Additional benefits: no lag or delay in your buffer and editor, and you can save locally should the remote session crash.
(This presumes a direct SSH connection, e.g., no bastion host, though that can be addressed via tunnelled connections.)
I don't disagree, but some of the great parts about vim are its self-sufficiency and reliability. It's awful when your editor won't open because it's trying to write a log message to a drive that was disconnected or checking for updates but the network is extremely congested.
One could make a command to check some central registry (or, what the hell, maybe a .vimrc blockchain) but typing that command would be about as much work as the curl/wget/git solutions proposed elsewhere.
Hm. At first I was pretty reluctant about settings "following" users, but a good Vim feature might be built-in syncing to some web service (DAV, S3, git, etc.). Run some function when you start (like fetchsettings) that will query for endpoint, username, password, and boom.
Something like that would be a bit better than what I'm doing now, which is just keeping a dotfiles repo that lives on github. Since password authentication is no longer allowed, and I need certain config stuff in there to stay relatively private, I have to do the public key dance to get started. The one benefit there is allowing diverging changes on different machines, and good control of what you push back to the store.
> When opening a file that is already open in another editor in another terminal, Vim gives me many options, but it doesn't give me the option to kill the other process (or ask that process to save its buffer and exit).
One potential risk with that is that it looks just at PID files, which may or may not be Vim. If you have a left-over swap file from a week ago after a reboot with PID 666, that PID can now be anything (including another unrelated Vim process!) It's actually kind of tricky to implement that reliably.
That said, you can probably implement something like that through the SwapExists autocmd.
Your second point seems more like some system design issue rather than a Vim issue per se. The problem also exists for your zshrc, tmux.conf, htoprc, and lots of other things. I don't think it's something Vim really needs to solve, but rather the system.
I had to do it several times over the years, even have a shell file that would install all the plugins straight from git. The process take no more than 5 minutes and I'm right at home in the terminal of the new machine.
I’ve setup nix home-manager such that, if I clone my dotfiles repository and setup home.nix (link it into place and make any machine-specific edits necessary), then home-manager will install a predictable version of vim, clone my plugin manager into the right place and symlink my vimrc into the right place. Then, on first launch, all my plugins install themselves and I’m ready to go.
The problem is that whenever you want to do a quick tweak, you have to do a `home-manager switch`, which can take a good 15 seconds or so. It's not the end of the world, but it's a very annoying bit of friction. It's particularly painful if you're trying to quickly test out changes that you're not confident of and iterate.
This is compounded by the fact that home-manager currently doesn't work properly with the new flake based profiles (https://github.com/nix-community/home-manager/issues/2848).
Yeah, I don’t have home-manager generate configurations for vim. I have home-manager generate a symlink to my version-controlled vimrc. This way I get the quick setup benefits of home-manager without the slow reload times.
I’ve found #2 is just not that practical. Too many plugins just aren’t that portable because they depend on underlying binaries (LSP support in Neovim for example).
Maybe minified, portable vimrc but even then, it makes me wonder, why not just copy all your dot files for your user?
I'm not sure what you mean by "automatically" but there's no reason you can't put your configs in a remote git repo and git clone/git pull if you have a new home directory or if you want to update your config, respectively.
for #2, Take your .vimrc. Put it on your personal domain or github or whatever. Make it publicly accessible. Use a unique combination of words in comments so it shows up in the search results for "goobleydook salamander".
> What is the benefit of using Vim proper these days?
Not that much, objectively. Many people enjoy its low resource usage, but most developers use machines perfectly comfortable with VSCode & Jetbrains. There's the startup time, which I don't really see as an issue for other than quick ad hoc file edits. Some people just like to stay in the terminal. It's mostly a matter of individual taste/preference.
The one thing I would point to as a real (if minor) benefit is the UX consistency - since everything is a buffer, keybindings are the same for plugin-enhanced UI elements as they are in regular file buffers. Even though I'm an nvim user, tbh I'd much rather have a true GUI, if they had been better and more consistently designed.
I have used emacs, IntelliJ, VSCode etc in the past (some for lengthy periods). I settled on nvim, not because it's particularly superior (and I'd prefer to ditch the terminal legacy), but just for the sake of settling on one thing I get to know well, and that I'm pretty sure will be around for longer than I will be. I have other things I'd like to spend my attention budget on.
In my experience vim emulation is great, almost as good as using native vim for keybindings, navigation etc but still not so comfortable. Like cuddling someone you love wearing blizzard clothing - better than no cuddle for sure but not the cuddle you'd choose as your favourite.
Depending on what you're doing, the native vim plugins might well be vastly better. I swear by YouCompleteMe as a wrapper for clang-complete for navigation of a C codebase. The autocompletion is pretty good too. I Haven't seen anything better with any other editor/ide vim key bindings or not.
I'm sure if you work hard enough at your s-exepression configs emacs can be as good if those are the keybindings you know and love. But why look elsewhere? <- Not rhetorical, genuine question - have you found a reason?
I don't know what I don't know, so that's why I ask. My JetBrains IDE does so much out of the box, I figure people give up all these features for a reason. Beyond vanity and too much free time, of course.
I was an ardent JetBrains user for years, and still enjoy their software. But I transitioned fully to NeoVim and there just isn’t anything I had to give up. It took a little more modification but the initial cost resulted in a much faster editing process than with GoLand. I have every single feature I regularly used with GoLand, but my editor is faster to load, consumes less memory, and I can progress at-least-as fast, if not faster by now.
Yeah I found Java really needs full ide support and yes that absolutely qualifies as a blizzard where I'm cuddling up to vim bindings on whatever the team chose for their ide. Eclipse wasn't all bad last time I did this but I'm someone who doesn't enjoy Java as much as some other languages in part for this reason - people who disagree with that aren't wrong.
But I've also never tried to use vim as a java ide and it could be great for all i know..?
That's exactly what I don't like about it. I'm a simple guy; I like simple editors. I will spend more time turning off things in JetBrains and VSCode that I find distracting and annoying than I will spend on setting up Vim to add some features I want like LSP support.
For me, I'm not interested in Vim's modal editing. But I use Neovim daily (mostly in insert mode like a noob). The reason for this is that Neovim blows every other text editor out of the water in two areas: time to launch, and multi-language syntax highlighting.
If I'm in the command line and I want to edit a text file, VS Code takes 4 seconds. Neovim takes 400ms. I installed vim-polyglot and it has syntax highlighting for even weird config files. I don't understand why no one is competitive with Vim by these metrics.
- I love the keybindings, but the draw for me is mostly in the way it handles splits. Being able to say "split this window horizontally/vertically with this other file" in very few keystrokes is the best thing since sliced bread to me
- That said, I do love the keybindings, and I've not found a single vim emulation that doesn't feel wrong within a few minutes of usage. It's very, very difficult to get a realistic vim emulation mode, to the point that I'd rather not try to use it in another editor
>>What is the benefit of using Vim proper these days?
1. Editing files on machines, where you can't use vscode remote editing.
2. Leetcode grinding. Many companies allow only vi for onsite interviews. Some companies will prevent you from using features of vi like ctrl-n and macros. So might want to practice with the bare minimal feature set.
3. General text heavy lifting, if you are aware of how to use Macros.
Hey, so this article is 12 years old. VSC didn't exist yet (2015).
I used vim because it was installed by default on just about every modern Linux server, so as an admin it was much simpler to just use vi (less easy to fat-finger a config file due to the modal).
But I wasn't porting my personal config around 100's of Linux servers, unless when absolutely necessary [not every admin wants the same config].
As far as having a huge ecosystem with vi - has anyone actually done a comparison of number of 'things' that make up an ecosystem and active users between VSC, emacs, vi?
I know reddit isn't a good sample size, but looking at subbed users:
- vscode 95k
- vi 151k
- emacs 62k
I'm not doubting that vi would have the larger community, but I'd have expected emacs to be larger than vscode on reddit but it is not.
He was barking up the wrong tree too, as HTML indentation is controlled by 'indentexpr' and not 'cindent' or 'smartindent' (and was in 2011 too). These options are kind of legacy from back when Vim was mostly just an editor for C code and before there was anything like VimScript so indentation had to be in Vim itself, rather than a runtime file.
It's unfortunate; I still see people confused by it today.
now someone needs to write nvim version of this, because some plugins have arguably better alternatives (fzf, nvimtree), you have ton of lsp clients, each with their own blows and whistles, treesitter and plugins a working on top of its tokens, also there are far more options to disguise vim as the slickest gui editor you've seen
Cuteness aside: for all the awesomeness that a tailored vim setup provides, I haven't been able to keep one stable since a decade ago, when I used an ubuntu desktop for work. Maybe I'm just getting old, but Helix's batteries-included approach to reimplementing vim has resulted in a much better experience for me in practice, even though it's lost me some features in theory (I miss you, vim-fugitive!).
And my hands can't even tell it's not vim…mostly!