I'm an avid tmux+neovim user, too, though working with Reason is a lot easier in VS Code. Making the switch from actual vim to fake vim (ie JS emulation) sucks.
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
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!
To be clear (as the guy behind these efforts), what was merged was a PR to let Neovim handle Ex-commands. This by itself was already pretty cool. In <200 lines of code, we were able to obtain full Ex-mode support, an aspect that had already taken 2000+ lines of code for much more limited support.
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.
FWIW, in all the times I've tried to use Emacs with Evil, it's still not been quite good enough. Enough friction here and there to bring me to a dead halt and make me reach for vim again.
same with me. tried everything to use evil with emacs (since i really wanted to use orgmode), but it's just not the same. the emacs keybinds get in the way of vim mode imho.
You definitely need to add a bunch of extra emacs configuration on top of the standard evil-mode stuff to get a fully intergrated emacs<->vim environment. On top of that, for most meta modes (e.g. dired, magit) you'll have to either find an evil-compat set of bindings, write your own, or get used to the emacs way of doing things in these special buffers.
Spacemancs is another half-step up the ladder toward OS. It's a bunch of configuration utils and conventions that other people have decided for you--which may or may not be what you want.
I actually have moved from VIM (I had an Amiga that I learned Vim on) to VS Code. The Vim plugin is just great but the VS Code ecosystem id great and when I switched was much fast than Atom. If people can look past their Electron Bias they might actually find a great open source tool.
This is great. Just enabled it and it's really nice having a full version of vim inside of vscode. I actually switched from vscode to atom a while back because the vim emulation in it was a little bit better, but I'm definitely going to switch back because of this. Thanks again for the heads up :)
"The vim-surround plugin is so useful that it should probably be built into Vim."
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.
> without the plugin, it's effectively inaccessible
I 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.
Kickass. Thanks for pointing out undotree. I had no idea it worked that way under the hood. This will certainly help me with bad habits I probably wasn't going to kick anyway.
Interesting read, I've been using Vim for some 18 years myself and I was completely unaware of fzf.
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`).
I work at VS Code and we recently switched to ripgrep for quick open and search. Even searching in Chromium source takes only a few seconds. Pretty impressive speed.
Damn, I'm an avid user of both fzf (super useful, recommended) and rg (yes, it's really faster than ag!) and I never thought of combining them... gotta try
An interest plugin I've found recently (Neovim only) is Deoplete, which is basically Ctrl-n on steroids. As you type, it shows a list of completions without any kind of slowdown (on my 4 yo MBA). For some languages, such as TypeScript, it even shows type definitions. It's close to being on-par with the smart completion in IntelliJ.
You missed https://github.com/maralla/completor.vim - one of the first async ones targeting vim8, later gaining neovim support. It doesn't look like it's easily extensible though, aside from using omnicompletion, which negates the async benefits.
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.
It sounds like you haven't given it a whirl. I've been on neovim for about about 3 years now after 5 years of native vim and it's been a complete drag-and-drop.
Sorry for the confusion, but I'm talking about moving out of the vim ecosystem into Visual Studio or one of the Jetbrains IDEs or Eclipse when they can integrate an actual vim environment; not about moving from vim to neovim.
I used to use `alias qvim="vim -u ~/.qvimrc"` as my small, toned down vimrc. It still had some bells (like vim-surround), but lacked the full-on Unite.vim, tmux, etc integration of my usual vimrc.
This only makes sense if you're on servers all the time, otherwise I wouldn't refuse to have a better workflow because of short period of inconvenience/annoyance.
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.
tmux send-keys is fantastic. I recently added a shortcut to run the test that my cursor is on in a different pane.
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!
Sounds cool! Could you share that shortcut please? I'm sure I could work it out, but there's always a bit of trial and error, and looking up docs without knowing the name in vim (for me, anyway).
For sure! There was definitely some trial and error as I was writing it. :) The specific use case I have is for running Elixir tests, but I'm sure adapting it wouldn't present too much of a challenge:
Apologies if this is incorrect (on my phone atm) but I've been using <space> as leader for two years now, and have never ever noticed lag in insert mode.
Perhaps it's a setting you have enabled/disabled, or unrelated to vim?
This lag is introduced by vim, to wait for the next keys and see if you are actually inserting them or using mapped key sequence.
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.
Unless you’re deliberately enabling certain key mappings in insert mode, then yes you’ve configured something wrong. And if you have deliberately enabled these bindings, you’re probably misunderstanding Vim.
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‘).
The problem is not the leader itself, but instead the bindings you're setting using leader: Use nmap instead of imap so that the mappings aren't even checked during insert mode.
I remapped , to ; and vice-versa - comma repeating the search in its actual direction and semicolon repeating it in the reverse direction just makes more sense on a german keyboard.
But yes, these keys' intended functions are actually really damn handy, and I use them on a daily basis.
As a former Vim user I'm happy to see a post like that ! Some old problems mentionned in the post like asynchronous processes mostly, but also the lack of smart indentation with the TAB key that also takes into account the type of file you're editing really drove me out of Vim. I've since switched to Emacs (with Evil mode because modal editors rocks), and I haven't looked back since.
That's what I don't get: for years, vi (and vim) mocked the emacs community (with some justification) for throwing everything and the kitchen sink into our editor. We were building an entire operating environment, while vi was providing a nice, solid, fast text editor.
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?
There's a lot of engineering in Vim as well. E.g., Vim's completion system is actually real cool once you learn it (it "clicked" for me after watching this video: https://www.youtube.com/watch?v=3TX3kV3TICU ). Vim regex, folding, and spellcheck also have useful features that you won't find anywhere else.
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".
> 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.
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.
This bothers me too, as a vi / vim user of 20 years, I've always respected emacs even if I didn't want to use it. But now it's getting to be where vim too is laboring under a big pile of hacks, and in a worse language than elisp. Recently I've switched to kakoune for development, which innovated where it counts by implementing new ideas about the core job of editing text. I'll still use plain vi as $EDITOR, because I know it's always there for me, but vim-as-an-ide is not for me.
I have a similar thought coming from a Java/Eclipse background; why use a bunch of half baked plugins to build a poor IDE experience? Vanilla vim is very capable. Personally, I use zero plugins, and a minimal vimrc, and have for years.
I've given emacs 3 tries. First just main emacs, then with Evil mode, and last time as Spacemacs. Every time the issue is the same: there is won't be any significant improvement to justify the re-learning curve of everything.
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.
I'm using Spacemacs with evil mode only for note taking and work tracking with org-mode. For the rest I'm still using Vim, but the org-mode was for me absolute worth it - now doing it for almost three years. Still for development still using Vi(m), because it's on every (remote) machine, is so much more responsive. Just to say, org-mode alone is worth emacs with evil mode.
dirvish.vim is my attempt to adapt dired to the Vim philosophy. It doesn't attempt to "DWIM", but provides :Shdo which allows you to script file operations using your shell.
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.
Many newcomers using your plugin will have a huge problem when using vanilla VIM. The same problem exist with Spacemacs, Spacevim or other weird things.
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.
I agree that you can't just use all the old keys otherwise you'll never learn. But what I am looking for is kind of a translation guide from ST to Vim.
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.
I'm so in with fzf. I discovered it recently, after using CtrlP for several years and I couldn't be happier.
maybe there was a workaround, but with CtrlP I had to clear its cache everytime I added a new file to be listed in the search results. With fzf it just works out of the box and it's blazing fast <3
Does anyone know of a good approach to debugging .vim files? I've not been able to find an interactive debugger or really even a good source of information about the program model of the vimscript interpreter.
Problems with macOS and iTerm2... that is too bad. I am going to do a 30 day challenge with a Thinkpad from Costco next month. Full linux install with Ubuntu 17.10!
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...
I recently switched from iTerm2 to Alacritty https://github.com/jwilm/alacritty. It does not have scrollback, splits, tabs and other fancy features. But for me, performance and snappiness is the most important feature (besides, I use Tmux for all those things mentioned).
It also says that both of them are limited by tmux, which I use 100% of the time in the terminal. The real problem is when you run Vim in tmux and start to scroll in a large file that you notice that Terminal.app does not cut it. It lags badly. In Alacritty its silky smooth.
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.
Word of caution when reviewing this report: it doesn't take into account vblank period. If you hit a key just after a monitor refresh, you're not going to see it until the next refresh cycle which is typically up to 16ms later. This study is concerned with how long it takes to update the frame buffer rather than time-to-visible which is difficult to measure.
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.
I've been using i3 for years now. I experienced the same pain. Mac hijacks a lot of the child vm keybindings. I didn't have this problem with windows as the host os. But that doesn't really make sense. Best of luck with the transition. Posting from a thinkpad, with i3, pycharm and vim right now :).
Switched to i3 a few weeks back and I absolutely love it. Switching between applications and workspaces is incredibly fast, and the _only_ time I need the mouse is for web browsing. It's amazing.
Unfortunately, it'll also be obsolete in a few weeks when Firefox 57 comes. I've switched to Saka Key, but it's not yet a viable replacement (esp. because clipboard interactions are broken in FF 56 on my Linux systems).
Unfortunately it appears all of the most popular (and feature-complete) Vim-style plugins for Firefox are dying with the upcoming Firefox update dropping support for XPCOM/XUL plugins.
I was split between using Emacs and Vim for last 2 years (I used Vim for last 6, and learned Emacs 2 years ago). But what made Vim my main editor is fzf and ag, and smooth workflow that I had in terminal. But I have to say, ivy and counsel made my Emacs experience much, much nicer. But I guess that I got too deep into Vim already that I kinda got used to it so much, that I appreciated more that "terminal" workflow.
A friend of mine is an avid Spacemacs user (which, as far as I understand, is a Vim distribution running on Emacs or something like that). He has both a Vim and an Emacs sticker on his notebook next to each other, and they've been carefully applied so that they overlap each other both ways.
I had tried spacemacs for a few months, it was nice overall, but everything seemed to be a little bit slower there than in vim, so I eventually switched back to vim.
I picked vim in the end because I already got really used to the workflow I previously mentioned.
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.
I'm a vigorous vim user, and always want to incorporate emacs into my workflow or try to utilize its strength. So far, I just failed several times and the affection to vim grows stronger.
I tried helm, but it induced slight lag, bigger loading times, and I didn't like that. I had big ass emacs configuration, it felt heavy and sluggish. That was the moment where I declared bankruptcy and started from beginning where I created 250 LOC config, with no big plugins like helm.
I had another pane autorunning something when it detected src file changes (inotify). So you just :w, and it happens.
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.
Lately I've been going the other way, from a complex vim setup to using the terminal and tools like inotify, tmux, and bash, so far I've found this a much better solution. Keeping my vim configuration and plugins synced between environments (windows, cygwin and linux) was getting to be a compatibility nightmare.
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.
Highly recommend kakoune. I've been using it since January or so, and its selection-oriented approach is really nice. I was a heavy user of visual mode in vim, so switching to kak, which has a much richer notion of selections, was a breeze.
If you use inotifywait a lot, I recommend trying http://entrproject.org/ which solves a lot of minor annoyances with inotifywait. It makes it easy to e.g. rebuild all web pages, restart your simplehttpserver and reload the current Firefox tab every time on of your `git ls-files` changes. The "restart server"-part can be fiddly with plain inotifywait, trivial with `entr -r`.
I avoid using too many plugins because the biggest advantage of using vim is its ubiquity on every *nix and BSD-based OS. I don’t want my workflow to become reliant on things I might not be able to use. Also, vim on its own is really damn powerful.
But the whole point of 'set hidden' is that the current buffer is hidden (rather than unloaded/closed) when you switch to a different one, so there's no prospect of losing unsaved changes -- unless you :qa! without checking your buffer list first.
> TextMate and Sublime Text showed us that the fastest way to find a file is by fuzzy finding
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.
Vim is the best lightweight single file editor there is. That’s all it should be. If you’re heavily configuring it, you should be able to answer “why is this better than an ide?” Without saying “vim makes me cool”. Also, if you can answer that, please let me know! To me, an IDE is better for everything but what default vim is good at.
And if you tell me that typing is faster, please also tell me why that’s relevant!
> And if you tell me that typing is faster, please also tell me why that’s relevant!
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.
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.
> Vim is the best lightweight single file editor there is.
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.
I can't live without my vim bindings now, it's incredibly jarring anytime I have to use someone else's editor. The muscle-memory is just too strong, and configuring vim with a bunch of plugins is extremely easy to do and provides me a lot of value for no downside afaict.
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 :)
After you really internalize the Vim movement keybindings, using anything else to move, from arrow keys to home/end to the mouse, feels like an interruption in your workflow. The wrist movements are what kill you by a thousand cuts.
It's like TrackPoints versus mice. Once you're used to never leaving the home row, the alternative feels rough and unergonomic.
- 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.
Intellisense, in-line code documentation, debugger, unit tests, refactoring, file browser/project support, find usages/jump to definition, full project intelligent search.
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.
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.
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.
> 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.
For intellisense/documentation it means having method names, arguments, types, and short summaries pop up as you’re typing. E.g “print” might complete or printf and give you all you need to know to use it on the spot. While vim has autocomplete, I’ve never seen this documentation feature (even typed argument listings) and it’s extremely valuable to me.
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.
The documentation thing exists, I just find it distracting, so I don't use it.
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"
I suppose it’s possible to get a pretty good env with vim (you’re losing a lot without a mouse), but damn it’s a lot of work to get there...
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.
>I suppose it’s possible to get a pretty good env with vim (you’re losing a lot without a mouse), but damn it’s a lot of work to get there...
>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.
I'll give it a try. At least there seems to be parser for Robot Framework, which could be handy. Although I've already written my own, but it only sort of works and it's pretty hack-y.
When I was talking about discoverability I meant assuming you don’t know all the exact command names and what they do. I thought you neeeded to know the exact command name to use :help, so I’m not seeing how that’s an answer here.
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.
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!