Vim after 15 Years
statico.github.io
statico.github.io
Recently, VSCodeVim merged #1725 to add actual neovim as an editor - it's using NeoVim's embedding API so you're using neovim to edit the text file inside of VSCode's chrome, including all of VSCode's type hints and popups. Info here: https://github.com/VSCodeVim/Vim/issues/1735
There's an ongoing rewrite to make neovim also work with your existing .vimrc file: https://github.com/VSCodeVim/Vim/pull/1897
I'm really stoked that we get the best of both - for languages with first-class VSCode support we don't have to decide between a half-baked VIM plugin or using VSCode without vim... you get both!
The PR for full neovim integration is the one you linked. It's more than just making it work with your existing .vimrc file: it's making it work with most vim plugins, leveraging the neovim runtime to make macros run faster, etc.
Personally I’d prefer that to working in GUI with an embedded terminal.
If 20 years ago you would have told me we gonna have Vim inside a text editor inside a web browser I would have thought you are insane.
"Space Macs"
> As it is written, that is space then macs.
I was pretty impressed when Oni for windows handled my legitimate .vimrc (init.vim now) without any issue.
- https://github.com/bryphe/oni
- https://news.ycombinator.com/item?id=15060417
- https://www.reddit.com/r/programming/comments/5gm5wa/oni_a_i...
- https://devhub.io/repos/extr0py-oni (gif dump)
Other neovim frontends:
- https://github.com/neovim/neovim/wiki/Related-projects#gui-p...
(I tested the QT one on windows and was a bit disappointed).
I couldn't agree with this more. Also undotree [1] should be built into Vim as well. Vim represents undo/redo under the hood as a tree, which is absolutely incredible once you have a plugin that unlocks it, but the built-in facilities for traversing that tree could be charitably described as "dismal".
Vim's undo tree makes a solved problem out of the old "undo undo undo undo undo... ok what did this file used to look like... redo redo y... oops did I just press 'y' by accident instead of redo and blow away a bunch of my later edits... next time I should remember to commit before I do that (even though I totally won't)" situation, but without the plugin, it's effectively inaccessible.
[1] https://github.com/mbbill/undotreeI wouldn't say that. Plain Vim does have the `:earlier` and `:later` commands, which aren’t too hard to use in the case you described. For example, `:earlier 40sec` takes you to the state of the file as you saw it 40 seconds ago, no matter where in the undo tree you are or were. I agree that undo-tree is usually easier to use, though.
However, I'm curious if you know `rg` (aka. ripgrep): https://github.com/BurntSushi/ripgrep In my experience it's markedly faster than `ag` (which is markedly faster than `grep`).
http://owen.cymru/fzf-ripgrep-navigate-with-bash-faster-than...
https://medium.com/@crashybang/supercharge-vim-with-fzf-and-...
fzf is lifechanger inside and outside Vim. I now use it for almost everything.
Selfpromotion: I have made a Vim plugin for searching and playing iTunes Library based on fzf.
- https://github.com/prabirshrestha/asyncomplete.vim
- https://github.com/lifepillar/vim-mucomplete
Note that mucomplete isn't async, it's intended to be simple.
Maybe I'm weird but I don't use any plugins. When I want more than what Vim does I use something else. Autocomplete, find usages, etc? I'll use an IDE for that. When I need to refactor a 500MB text file without hanging my machine, I'll use vim.
These are usually attempts at reducing the need for IDEs, while keeping the familiar vim editing. With no exceptions so far, no IDE plugin (or emacs plugin, for that matter) has been able to emulate vim editing well enough to replace vim as my primary editor.
Perhaps when neovim (or anything else) is able to give me native vim capabilities in a more extensible or powerful editor, I'll switch. But we're just not there yet.
I suppose your right. I use it as a continuation of vi. Instead of a nerdtree plugin, I use a real file browser to manage the files in my project. Instead of split windows, I open multiple instances. To refactor a piece of code, I use some ex commands, buffers and maybe a macro. In that sense I'm not a Vim user. Vim is the vi implementation I use.
This changed my life.
I thought I had to decide between having a separate pane to run my tests in and having a convenient and precise way to run to exactly the test or test file I want to run. But because of send-keys, I can have both!
https://gist.github.com/ddresselhaus/98b022e295bc27e9264dece...
I haven't done a ton of Vim scripting and found this resource to be super helpful! https://devhints.io/vimscript
Colemak?
It is bearable with ',', but I cannot stand it with <space>.
If it is possible to remove completely this lag (not simply reduce it), then it would be awesome.
Perhaps it's a setting you have enabled/disabled, or unrelated to vim?
It is configurable in vim, but then either you have a lag and you are able to use your key sequence, or you don't and <leader> sequences cannot be used.
So maybe I have something configured that sets it wrong, but I do not see how to reconcile both things.
The whole point of Vim’s normal mode is to free up “modifier-free” key mappings for commands rather than inserting characters. So by extension, using “modifier-free” key mappings for commands in insert mode is a Vim anti-pattern (if you want custom mapping’s in insert mode, use mappings for them with modifier keys).
Regarding your issue, I suspect your defining your bindings with the `map` keyword when you should be using `nmap` (or better yet `nnoremap‘).
But yes, these keys' intended functions are actually really damn handy, and I use them on a daily basis.
/me ducks and runs out of the room
I've tried Spacemacs a couple of times, it's very good but not for me I think. I'd be happy to import ideas like dired though.
But with vim & neovim, people are building a complex operating environment in a terrible language, and ignoring the man-centuries of effort which have gone into emacs.
Why not just switch over? In what ways is a tricked-out vim or neovim preferable to emacs? In what ways is tricking out vim or neovim preferable to emacs?
More generally, I agree with you. If it were up to me I would prefer to use Emacs as a baseline. But it's not up to me, just like it wasn't up to Google to decide that Javascript wins. Ubiquity wins. Emacs lost.
> for throwing everything and the kitchen sink into our editor. ... But with vim & neovim, people are building a complex operating environment
That's not really true. The explicit goal of Nvim is to be embedded and focus on "peer to peer" nvim instances. That's the opposite of Emacs' constant reminder that there needs to be a single Emacs daemon controlling everything, and you "should never leave Emacs".
I don't think one can really say 'emacs lost'; the game's not over yet. Yes, emacs really has lost popularity over the last decade, and yes vi really has maintained its popularity. But emacs still exists, new users are still coming to it — and at the end of the day, emacs is a better operating environment than vi. They are both pseudo-Turing-equivalent, in the sense that emacs can perfectly emulate vi & vi can perfectly emulate emacs — but emacs is extensible in a far better language than (vi)|(vim)|(neovim).
I maintain hope that as young programmers become old programmers, they will see the wisdom of true native apps (unlike Sublime), of free software (unlike TextMate) and that when they evaluate emacs vs. vi they will choose an editor they can use & extend for the rest of their lives.
Imo fuzzy finding and git plugins isn't a huge stretch for a editor. I still wouldn't like to read my email from vim.
Magit and org-mode are a killer pair of reasons for many. Dunno if they would be for you, though.
Try TRAMP, which enables you to edit remote files in a local (spac)emacs (and also local files with sudo or su). It's pretty awesome.
I have an almost identical setup as that described in this post. Being in the terminal and integrating with tmux is a wonderful environment - lightweight and immersive. And all these Vim plugins are of such good quality - are Vim plugin authors perhaps of a different, geekier, ilk? So it's a shame that vanilla Vim is restricted to its special modal editing paradigm, there's so much more to it than that.
BTW I post this on HN everytime I see a gushing Vim thread, apologies if you've seen it before.
PS I'm also working on refactoring my tmux keybindings that do a similar thing - SHIFT+ARROW to select, CTRL+C to copy, CTRL+D to select the current word, etc, etc.
If someone don't want to use VIM modal editing why not to stay with Sublime/Atom/VSCode or any other editor? They also have very rich plugins ecosystem. Not mentioning that Sublime is like crazy fast...
To clarify it's not an attack on anyone. For instance evil mode in emacs is also a heart breaking plugin for me. Every editor is made for different workflow, why on earth mix them up? And in most cases it does not work very well.
For Vim learners I really think that GVim is a great tool because eg it doesn't do bad things when hit some keys you're used to with muscle memory such as copy/paste and Ctrl+arrow.
It has dropdown menus with the commands on so you can learn from them.
Once you're comfortable in GVim it's easy to switch to regular Vim.
Plus I use it on Windows as handles fonts and syntax highlighting better.
See "Why Atom Can't Replace Vim"--https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385...
The default settings required very little changes for me and I've adjusted to their (clever) default key shortcut scheme.
I have wanted to try i3wm for as long as I can remember. Unfortunately, it is a PITA to get working on a VM with the Mac as the key chords don't play nicely intersystem. Super excited to give it a go... what is awesome is that I can have an IDE like Pycharm right next to VIM and my shell in a tiling window manager with Linux. I hope I can ditch macOS...
The rest, as they say, is garbage.
This(http://abhirag.in/articles/org/i3_setup.html) is my i3 setup with literate dotfiles, hope you find it helpful in switching to i3 :)
For getting something close to i3 (you wont...?) on macOS I am using chunkwm https://github.com/koekeishiya/chunkwm.
I spent some time during the summer to get to know Linux using i3 (i3-gaps actually) with urxvt on a VirtualBox. I do recommend it!
And yes, scrolling with j/k for longer periods may be an anti-pattern in Vim and yada yada... I scroll in Vim, and in Alacritty its smooth, in Terminal.app its sluggish.
That said, there are plans[1] to reduce Alacritty's input latency. Though, I personally use it as a daily driver and have never felt that there was a noticeable input lag.
Once that lands, Alacritty will have similar latency to Terminal.app _and also have_ a 60 Hz refresh rate (the "smooth" feeling), low CPU usage, and much higher throughput.
You're going to have to pick a side. You can't be an atheist that dabbles in Catholicism.
Some men just want to watch the world burn.
But there are many nice things from Emacs that I really miss. For example magit, various REPL integrations and much better support for functional programming languages. Emacs felt cool and nerdy but I always felt like I was using 1% of it. Many things on the other hand felt much more clunky than I expected (terminals for example). And I don't like all in one philosophy of people reading emails, reading reddit, chatting on IRC all through emacs. I tried many of those things but didn't find it appealing at all.
But if I had to do some serious work in one of the functional languages I can see myself coming back to Emacs pretty easily.
Ctrl Alt SysReq + REISUB
(It's the only way.)
I'd never consider switching; I'm in too deep.
It might be easier to change religions, than change editors.For emacs, try helm to replace fzf (or just use fzf.el). helm-ag is awesome. On the terminal, just alias 'vi' to 'emacsclient -nw -a ""'.
If you miss the vi keybindings (which are a pretty nice way to deal with code), then evil-mode or a full Spacemacs are pretty good options for you.
With Tab mapped to :WSNext (and C-Tab to :WSPrev) I can see all open buffers and cycle through them. And close unnecessary with :WSClose.
I did try to get tabbing through buffers working and yours looks like a good solution, but I find my buffers are rarely next to each other.
The method in this blog could do this: just add :w to the mapping. The blog method might seem hacky in using up and enter, but this makes it easy to modify the command you want to run.
I also wanted to try using kakoune (http://kakoune.org/) but found that for day to day stuff I was far to reliant on my vim setup. Since beomming more reliant on the shell this is now more feasible and I've got a lot more flexibility.
[0] https://github.com/qznc/dot/blob/master/bin/git-onNotify
set hidden
Stopped reading here. This is from emacs and those other editors copied it. Emacs had this in about 1996, a full decade before those other editors existed. Oh, and the emacs versions are way more flexible than fzf due to supporting tab completion as well. All this other stuff has been in emacs for decades as well.
I know about the Holy War etc.. but seriously, credit where credit is due.
And if you tell me that typing is faster, please also tell me why that’s relevant!
I started configuring vim years ago and have only tweaked it here and there over time, adding a plugin for this or that as I felt the need. I don't really see anything wrong with that :)
Because it's a workflow that works for some people. Shouldn't being the most effective you can be trump things like which editor is better, or IDE versus vanilla editor? Your workflow is your workflow, don't worry about other people's.
Are you serious? Do you know about Vim buffers? The `:b` command? The `Ctrl + 6` command? The `m` and `'` commands? These commands alone make Vim a far superior multi-file editor than anything else I have seen.
Now if you add plugins like `NerdTree`, `CtrlP` or `fzf` to the list, I don't think there is any other editor on the planet with the exception of emacs that comes anywhere close to multi-file editing productivity that Vim can offer.
It's like TrackPoints versus mice. Once you're used to never leaving the home row, the alternative feels rough and unergonomic.
Clearly the less understood thing about vim. People keep thinking this means "typing more words", while what it means is "having the change you have in mind faster on your screen". It's not about writing more code, it's about not having your code lagging compared to your brain.
Anyway, to me, this is not even the best feature of vim. The best feature is what vim creator mentioned : its ability to automate repetitive tasks, possibly short living (with macros). It's easy with vim to convert a file without writing a parser, just with macros. So yeah, I prefer to add IDE stuff on top of vim rather than using an other editor.
Even where vim supports these, it’s support is far weaker, less reliable, and much more painful to set up than IDE support. Among devs serious about productivity, it’s hard to imagine choosing vim.
What do you mean by this? Like folded comments?
>debugger
So, gdb?
>unit tests
You can write unit tests in vim. You can also run them, obviously.
>refactoring
Again, what do you mean? Now it feels like you are just listing stuff or maybe I just don't know what refactoring actually means.
>file browser/project support
Granted the build in file explorer is pretty stupid, but the standard `:find` works perfectly well, so as long as you are not just randomly browsing, I don't see an issue.
>find usages/jump to definition
Vim has support for tags. I use jumping between them every day.
>full project intelligent search
What is this? Just grepping for stuff on whole repo or something more interesting?
>Even where vim supports these, it’s support is far weaker, less reliable
Only if you haven't used the features before. I definitely do not buy the "far weaker and less reliable" part.
>much more painful to set up than IDE support.
I am not arguing that vim does not have a higher learning curve than your average GUI editor/IDE, but are you seriously suggesting that you have not configured a single thing in your IDE? If you have, then your point is moot. I consider my .vimrc complex, but it has been build from scratch over the years as I've wanted more functionality.
>Among devs serious about productivity, it’s hard to imagine choosing vim.
Meh, sure depends on what you are doing. I rather have a tool which I can adapt to my needs than having to hunt down new tool for every project/language.
You ready for that killer feature that your IDE doesn't have? Try being productive on another machine. Over an SSH.
EDIT: I just noticed that I completely dismissed the "intellisense". Completion is build in by default. I can't remember if member list is, I use some tiny script that formats them all nice and neat.
> Again, what do you mean? Now it feels like you are just listing stuff or maybe I just don't know what refactoring actually means.
Agree with all your points. For this one, some IDEs support extracting lines of code into a method/function, figuring out what's an argument and stuff like that. It's a pretty nice feature that I don't believe is in vanilla vim, but it's something I can imagine writing a vim plugin for it.
>Again, what do you mean? Now it feels like you are just listing stuff or maybe I just don't know what refactoring actually means.
It allows you to inline / rename variables and methods. It allows "safe deletes". It gives suggestions for improving code (i.e. if a best practice wasn't met or if there is some obvious improvement). "Move" or "extract" snippets of code into other/new files.
If you haven't used an IDE-like's refactoring capabilities I'd be surprised. Meanwhile, almost all of this is likely possible with the correct set of VIM plugin. I've just never had the time or energy to go find plugins, ensure they individually work as advertised, and work well all together, when I can just download Intellij and be extremely productive.
FWIW, I sync my laptop's directories to my remote dev box, so I rarely develop on anything but my macbook, but I do use Intellij with VIM bindings, so when I log into a remote machine I'm still quite productive.
P.S. I prefer VIM for Ruby / JS / Config files, etc.
Tags require a lot of manual work, so I consider them in the “worse” category of vim support for ide features.
Also, you shouldn’t mention gdb because the Ux is awful next to IDE integrations. Really. There’s no comparison here.
For unit tests ides can run individual unit tests with a single click.
Again, vim may support some of these features, but it’s UX is awful next to IdE Ux.
Also, I’ve been able to use VSCode over sftp, although it’s true vim can be pretty nice here. Personally don’t want to cart around a whole folder of plugins on top of vimrc, sounds like a pain.
Tags just require you to have something like exuberant-ctags installed, then you can just run `!ctags -R .` from vim and you are golden (only needs to be done as you create more classes/functions/methods/whatever)
Most shit are just GUIs or wrappers for gdb. There are plenty to choose from if you so choose.
If your unit tests take super long that might be a sign they are bad. Also if you can run a single unit test in some way, you can do it with vim. Unless your IDE does some JIT magic on the side that for some reason can not be replicated in terminal.
>it’s UX is awful next to IdE Ux.
I don't like tomato soup, so you are wrong!
>Personally don’t want to cart around a whole folder of plugins on top of vimrc, sounds like a pain.
I have grand total of 3 plugins, none of which are required for me to do work. It depends on whatever you want, I've seen many people use ton of useless plugins which either reimplement something already present or just try to do things "the old way I'm used to" instead of just learning to do the thing in "vim way"
Before you tell me how it’s totally not, all the things you listed require specific knowledge, configuration, and then custom non conflicting keyboard shortcuts (unless you like manipulating your tools 10x slower than ide users). For me it’s just not worth the work. Vim is best for me in its default state, and I can still take advantage of it being available everywhere that way. Ides make crazy configured vim portable by being the default state of the ide and downloadable to any pc (with limits) from the internet. It’s a much lower maintenance approach for me. I’m glad vim works for you, but I find it hard to believe it’s a very practical choice (unless you’re extremely attached to your custom setup).
Also vim seems less discoverable to me. If something’s not a keybind you already set up, you need to look up plug-in docs, or tab through all the hundreds of possible commands. In ide land you open your command Paulette and type a relevant word or plugin name and everything you could do along with keyboard shortcuts is displayed. Not to mention it’s displayed in a way that doesn’t disrupt what you were already looking at. That’s a nice advantage of a GUI.
When I picked up vim and committed to it it’s because I read online it was better and probably thought it made me more badass, but eventually after a few years I returned to IDEs, because they’re genuinely better suited (imo) for programming. Vim is a headache for a second rate ide, and continues to be headache to use as you go (ctags for every language? Official language plugins? ...)
I get you like vim, but using vim seems stubborn to me.
>unless you like manipulating your tools 10x slower than ide users
Imo using mouse alone makes you at least twice as slow as using keyboard shortcuts. Not only do you need to physically move your hand and find your mouse, then you need to locate your pointer (which might not even be on the same screen) then you need to swing it in the approximately right region of screen and search for the button to click. Only to return your hand back to familiar keyboard. All the while you probably could have just pressed 2-3 buttons and be done with it.
>Also vim seems less discoverable to me. If something’s not a keybind you already set up, you need to look up plug-in docs, or tab through all the hundreds of possible commands.
The handy `:help <what-you-want-to-know-about>` has so far served me well, when searching how to do stuff in vim.
Otherwise it is obviously up to your taste. I truly believe that you are wrong, just as much as you believe that I am. From my point of view you probably didn't give vim a proper chance (most likely you fell into the few big potholes that many beginners find themselves, which I'll admit is fault of the default vim configuration)
As for >ctags for every language? Official language plugins?
Excuberant-ctags have so far worked with me on all but one language (Robot Framework), but people have long told me that exuberant-ctags is bad and I should use something else that is more advanced, I just haven't bothered since it handles C++ and Python well and that's all I currently care about. For language plugins, I guess only thing I have is specific syntax file for Robot Framework, but that's again only because it's still uncommon tool, so support for it is lacking.
Also, yes the mouse can be slow for some purposes, but if you’re not in a typing frenzy it’s probably easier to be in mouse mode which is something like reading mode. Scrolling is much easier for me outside of vim than inside of vim. Also I considered that this is maybe a better match to my workflow, which is often more readingand thinking than actual keyboard input. So it’s ok for keyboard input to be less prioritized. For this workflow having inline documentation, intellisense and compiler errors as you type is fundamental.
Also I doubt I ran into the beginner traps. I used it pretty seriously and exclusively for a year or two and am still proficient at navigating. I even got into using macros like other commenters mentioned, and learned all the different edit mode shortcuts (cxsSDCiaAOo). Seriously editing in vim is really really fast. Although maybe there are traps for people that I don’t already know about, and you could fill me in on those.
>Scrolling is much easier for me outside of vim than inside of vim.
you might want to try `set mouse=a`
- Automatic compilation and error mapping into the codebase (supports make and parses gcc output by default).
- Function definition traversal with tags.
- File traversal over #include statements
- Syntax highlighting.
- Word completion with both on-page and tags file support.
It's sometimes easy to forget, but vanilla vim is a fully featured IDE for C. All this is really doing is extending that IDE functionality to support other languages, and adding innovations which have been made in other editors.