I agree. A lot of his other criticisms can be addressed via the customisation. Vim now has plugins to speak LSP, so it can have syntax highlighting and cross-referencing that is exactly the same as Visual Studio Code. As long as you install everything, on every machine you use.
I’ve written four books, a PhD thesis, 150+ articles, a bunch of scientific papers, and a few hundred thousand lines of code in vim. I mostly use it for two reasons:
A lot of development I do is on remote machines. Being able to edit code or build from any terminal is useful. I would probably replace a lot of this with the VS Code remote extension if it were open source (unfortunately, the server part isn’t and so it’s limited to a depressingly small set of supported platforms at the moment).
My fingers are used to vim and sulk if I am not in vim (sorry, vim mode in other editors is not the same.
For text (of the human-readable kind), I think vi’s modal interface is actually a good things (one of the very few things I disagree with Jef Raskin about), because writing and editing are separate tasks and you are more productive if you completely separate them in your workflow. For code, it’s not really a benefit and I mostly use it to avoid having to retrain my fingers.
The one feature that I miss on non-vim editors is unlimited, persistent, branching undo. This was something we tried to duplicate and make general with Étoilé. If I edit some code with vim and it was, at some point in the past, in a working state, I can always go back and find that, even if I’ve rebooted a few times. This makes me a lot more comfortable experimenting without regular VCS commits. Ideally, I’d want an editor with automatic git integration that would create a stream of git commits for my in-progress changes and then squash them when I did a named commit (or, even better, leave them in a local branch and merge the squashed version into that).
Ideally, I’d want an editor with automatic git integration that would create a stream of git commits for my in-progress changes and then squash them when I did a named commit (or, even better, leave them in a local branch and merge the squashed version into that).
Couldn’t you basically do that with some buffer auto commands in Vim, where it would need to detect what “branch” you’re on and the commit all the changes? And a “squashcommit” git alias to then commit (pardon the pun) to this timeline?
Yup, though with Vim’s branching undo I’d want that branching to also be reflected in the git history, so if I do ‘undo’ a bunch of times and then start typing again, there’s a git branch that reflects my prior state that I can go back to (and, ideally, as we did with Étoilé, allow easy cherry-picking from other undo branches). But what I really want is that exposed with a nice GUI in a graphical editor. I rarely use vim’s branching undo because I can never remember the commands.
Because if you customize vim a lot (custom keybinds, functions, plugins, whatever, …) then you will build muscle memory and habits that are tied to your vim setup. With that in mind, using vi on OpenBSD or vim.minimal on ubuntu server would still be a pain, because you’d lack all the customisation from your local setup.
To sum it up, vim is installed everywhere, but your customisations are not, so you can only benefit of one of these advantages at a time.
This is where Emacs shines. With Evil and Tramp, one can use the familiar customised vim keys while editing files remotely, as long as the remote system has SSH.
As @swehren mentioned, vim can edit remote files by specifying path as “ssh://host:/path/to/file”. I don’t know how this works with your emacs plugin, but this is definitely not ideal.
I use vi to administrate my dns/mail/http servers, and even though I could easily edit file comfortably from my local machine, I still need to login on the remote end to restart services, read logs, etc…
The only use case I see is to edit PHP files remotely, and even then this would be bad, because you cannot use autocompletion of filenames, and saving files takes longer due to network latency.
Navigation file structure and editing files locally is still the easiest option IMO. And this is also why OpenBSD added mg(8) to the base system !
Tramp is not so much a plugin, as a “Transparent Remote (file) Access, Multiple Protocol”. When connected via one of the various methods (inline, external or GVFS-based) you get to do almost everything as you would on a local system (therefore “transparent”). That means you can also use M-! or Eshell to run commands, copy files, diffs, etc. without having to worry where what is.
Good point. Maybe this calls for splitting up my vimrc into two files, a .basic.vimrc which has commonly used configuration not tied to plugins or installed programs and my regular .vimrc which would source the former.
The .basic.vimrc can then be copied wherever I need it.
A different solution is to go with an empty ~/.vimrc (the simple existence of this file automatically set “nocompat”, so you get a full vim experience), and try your best to use it like this. Vanilla vim is already real powerful as an editor, and once its default keybinds and mechanism enter your muscle memory, you’ll realize just how futile many plugins are.
I did that for years (working on personal C projects mostly), and it was great.
I then switched to vis 2 years ago, and never looked back. It mixes vim with sam, so you get multiple selection and cursors on top of vim, which is neat.
As it really ressemble vim, I can apply my muscle memory to defaukt vim as well, except for the substitute command (which is :x/foo/ c/bar/ in vis).
The fact I commited to using default vim for so long helped a lot switching to vis, as it doesn’t have the same plugins (though it can be extended in lua).
Heavily cutomized vim very quickly starts looking nothing like vanilla vim. It’s infeasible to carry around your dotfiles everywhere (though there are ways you can bring subsets of your configuration everywhere), and the more customizations you have, the less effective you’ll be without them. It has to do with the emphasis on macros and simple keybindings that vim has and the muscle memory that requires.
In practice, I think I disagree. I use vim on production machines and sundry random boxes with little customization, and I use local copies with dozens of plugins and a stack of custom keybindings. There are occasional frustrations, but not especially overwhelming ones.
“Being able to use roughly the set of vi features plus some niceties” remains a fairly portable skillset. I might have a different experience if I’d overridden the core vi-style semantics of the interface all that much, but apart from a couple of bindings I haven’t, and I’d suggest that best practice is to leave most of that stuff in place and augment it rather than replacing it. That’s why there’s a convention of prefixing things with the leader key and so forth.
As always, it’s a gradient. I was thinking more of people customizing to look like this, remapping hjkl, etc.
And besides, I was just talking about the argument. Practice is a different thing, but when you see people who have only used vim try to use vi and seem just as confused as a newcomer, then I do think that there is a difference worth mentioning.
I think there’s two sides to vim: there’s vim itself, which has the virtue of being available on most platforms but is in many ways inferior to a modern IDE (even with loads of plugins), and then there’s the vim model of editing, which has been ported to many other editors and IDEs with plugins (though of course they’re emulation layers, and might not always work the way vim does). You don’t really need to use vim itself to get most of its benefits.
But here is where the problem lies, it’s surprisingly rare that I find myself editing only one file at a time.
And that’s why Emacs exists. It even has a best-in-class set of vim keybindings. And it has a wonderful extension language. It’s a Lisp Machine for the 21st century!
That just means he needs to learn more Vim. It does indeed support tabs, and splits too, and IMO does it better than most IDEs. And you can get a file tree pretty easily too with Nerdtree. I have no issues with editing a bunch of files at once in Vim. Features like being able to yank into multiple registers is much more of a help there.
I suspect one problem people have with vim and editing multiple files is that they only know about buffers, which can be a little tricky to work with, but I don’t think many people realise it does actually have tabs too.
I frequently open multiple files with vim -p file1 file2 which opens each file in a tab, and you can use gt, gT, or <number>gt to navigate them. There’s also :tabe[dit] in existing sessions to open a file in a new tab.
I generally find this pretty easy to work with and not much harder than doing something like Cmd-[ / Cmd-] as in some IDEs.
That said, while you can work with tabs like this, that’s not entirely the idea of them. Tabs in Vim are more like “window-split workspaces” where you can keep your windows in some order that you like. With one buffer in one window per tab you do get a pretty similar workflow to tabs in other editors, but then again you could get a similar workflow with multiple buffers in one window even before Vim got tabs.
Guess tabs fall in the tradition of vim naming features different than one would imagine: buffers is what people usually understand as files, windows are more like what other editors call splits and tabs are more like workspaces.
Oh, to be clear I don’t have one buffer per tab. I do tend to use them more like workspaces as you say. Typically each of my tabs has multiple splits or vsplits and I’ll go back and forth between buffers - but having tabs to flip back and forth between semi-related things can be useful on a smaller screen too.
One of the reasons why I love vim is that I find a lot easier to edit multiple files at once. I can open then with :vsp and :sp and shift-ctrl-* my way around them very fast, with NERDtree I can open a directory folder in any of these windows, locate the file, and there you go, I have them arranged in whatever way I want. It makes it super easy to read the multiple files and copy things around. I like my auto-complete simple, I find autocomplete distracting, so I just use ctrl-n, but I’m aware this is a fringe opinion, if you want a more feature rich autocomplete, You complete me works pretty fine for people that like these. Also, I can open any terminal with :terminal… My vim usually looks more like this https://i.redd.it/890v8sr4kz211.png nothing with to do with 1 file per time.
Does vim makes me super faster than everyone else? Probably not, it’s just a text editor, but it’s very maleable and I’ve been coding for many years now and I haven’t ever seen the need to not use it. When I need to work on a new language I just install a bunch of new plugins and things get solved.
Nothing against VS Code, but it’s also only super powerful with the right plugins and configurations, there’s more of it out of the box, but without them it would also just be a simple text editor.
I gave emacs a try through mg(8), a small editor that ressemble emacs a lot (no LISP though) and is part of the default OpenBSD system. It comes with a tutorial file that takes you on a tour to discover the basics of emacs, starting with the navigation. This is like vimtutor, and it’s great !
It also let you discover emacs as a text editor, AND NOTHING MORE! Which is refreshing and helped me reconsider its usefulness for editing text 😉
But here is where the problem lies, it’s surprisingly rare that I find myself editing only one file at a time.
I got stuck on this plateau for a while myself, but learning how to use splits and tabs is extremely worthwhile. The syntax isn’t any harder than the usual vim stuff, and I’ve found it to be generally more powerful than GUI editors.
Most of my time is spent flipping between multiple files, ctrl clicking into function calls, cutting code out of one file and pasting it into a new one. I feel this can be done much faster with an IDE.
So learn how to do it faster with vim :)
You can have file-trees, you can have fuzzy file-finding, you can have horizontal splits, vertical splits, multiple buffers, etc etc etc.
For a bit of inspiration, check out the Destroy All Software screencast series. There are a few episodes on vim (and also an important one on job control), and he demonstrates that once you get comfortable with fuzzy file-finding, it’s unlikely you’ll want to use a file-tree again, except for the occasional instance where you background your vim process to drop into the shell, run tree to get a high-level overview of the structure, and then foreground vim again.
Even just watch it to see the speed at which it’s typical to work at once you gain proficiency. Poking at IDEs seems glacial after that.
Getting comfortable with my text editor is easily one of the best investments I’ve made in my career, and life more generally, probably, since I use vim for almost all writing I do, including email.
I think it’s great, but I think I’m addicted to it. There are things that are simply easier in vscode or pycharm (intelliJ), etc. Especially when it comes to integrating deeper tooling. Language servers are helping, but the (by design) mystery meat navigation of vim, the not exactly 2020 help search system (compare it to the search under Help in every Mac app), keep it a bit hamstrung. I think there’s some great parts to vim, but I learned vi because my initial editor of choice, emacs, wasn’t on the servers I was logging into. And when it was it took too long to startup. Those things aren’t true anymore and I’m still stuck on hjkl and :, etc.
There are worse things to get addicted to, plus vim-mode in some of the more modern editors isn’t half bad if you need some of their features.
Like @david_chisnall I in the end wrote my thesis in vim (undergrad and phd) so yea, it just rules. I’d still say I’ve heard of 80% of the things vanilla vim can do, but I use about 5-10% on a regular basis.
Seems the poster’s answer is “no”. I’d say it’s “yes”. But there are a few qualifications. First, you should be able to get what you need from an IDE in vim - with eg ctags and language plug-ins, you should be able to autocomolete and go to definition in vim. Second, you of course need vi(m) key bindings in your browser, and decent key bindings in your window manager - so you stop needing to use the mouse.
Strong agree on vim bindings in the browser. I find however that these bindings don’t work universally across all websites due to differing designs and layouts (“don’t work” as in ergonomics, not code correctness), so browsing is only sometimes keyboard-only.
Even as someone who extensively customizes vim, strong disagree that this is the right solution for big projects, especially (e.g. at work) where you might have one or two usually well-supported languages across everything. Why do all that configuration if a good IDE will ship that behavior and more out of the box. Most of them even do it with vim-like bindings available.
As a security person, I spend more of my time reading and modifying code than creating new code from scratch, and often I’m reading for understanding rather than for debugging, of which the latter requires more depth. The code I interact with is in a myriad of different languages, and is often functionally and decomposed poorly or not at all. This lends itself to a highly configured vim. If I worked on “Large Code”TM then I would likely use an IDE.
Most of my time is spent flipping between multiple files
I use vim full time, and to achieve that I use tmux and have multiple instances of vim running. So I can switch with Ctrl+b, n/p, create a new window Ctrl+b, c.
ctrl clicking into function calls
Jumping to definitions is possible with vim, however I barely use it. I use vim-go which allows me to do :GoDef to jump to the definition in my Go projects.
cutting code out of one file and pasting it into a new one.
I recently discovered that you can cut in vim to the system clipboard with "+x, then use the usual paste "+p.
I recently discovered that you can cut in vim to the system clipboard with “+x, then use the usual paste “+p.
It’s better than that, anything that yank content (d,x,c,y,s will work with named register ("+). Want to cut the current expression body ({...})? Do: "+di{
Agree, vim is great until you need to work between multiple files. Then a ton of complexity is involved to work between files. I like my current setup where I use vim for single/small files and then VSCode + vim plugin for projects.
I used Vim full-time for about six years until I discovered kakoune. Now that serves as my daily choice. as others have mentioned, once you add LSP support to any editor it becomes about as feature-ful as an IDE, so the choice really comes down to things like how you navigate the interface.
I’ve been using vim too long to be able to understand the idea of it being bad for multiple files. Is the workflow they’re doing something “vim file1”, edit, close, “vim file2”? Or typing :e ?
I use nerdtree and fzf for everything, splits if I want to see multiple files at once.
I don’t quite understand what the OP means with “full time”. From what I see he couldn’t replace his browser with vim, which is uhm, somewhat understandable, since vim is an editor, not a browser. He notes that IDEs are better file explorers which they might indeed be, but no word on whether he’ll continue to use vim emulation modes or not.
I think that’s most interesting question: did working in the modal vim way sway you to use this interaction mode more than you did before? For me personally the answer is yes, I’ve incorporated some vim patterns into my broader life (like using vim-like plugins for my browser, using hjkl as cursor keys on my computer) but is it for the OP?
And yes, there is a Vim washing detergent but I didn’t replace my washing machine with vim, so I guess I am not using vim “full-time”.
I always say this, but if you’re argument is
(emphasis mine), then you can’t also claim
I agree. A lot of his other criticisms can be addressed via the customisation. Vim now has plugins to speak LSP, so it can have syntax highlighting and cross-referencing that is exactly the same as Visual Studio Code. As long as you install everything, on every machine you use.
I’ve written four books, a PhD thesis, 150+ articles, a bunch of scientific papers, and a few hundred thousand lines of code in vim. I mostly use it for two reasons:
For text (of the human-readable kind), I think vi’s modal interface is actually a good things (one of the very few things I disagree with Jef Raskin about), because writing and editing are separate tasks and you are more productive if you completely separate them in your workflow. For code, it’s not really a benefit and I mostly use it to avoid having to retrain my fingers.
The one feature that I miss on non-vim editors is unlimited, persistent, branching undo. This was something we tried to duplicate and make general with Étoilé. If I edit some code with vim and it was, at some point in the past, in a working state, I can always go back and find that, even if I’ve rebooted a few times. This makes me a lot more comfortable experimenting without regular VCS commits. Ideally, I’d want an editor with automatic git integration that would create a stream of git commits for my in-progress changes and then squash them when I did a named commit (or, even better, leave them in a local branch and merge the squashed version into that).
Couldn’t you basically do that with some buffer auto commands in Vim, where it would need to detect what “branch” you’re on and the commit all the changes? And a “squashcommit” git alias to then commit (pardon the pun) to this timeline?
There’s this: https://github.com/bartman/git-wip
I’ve used this in the past and it worked really well for me.
Yup, though with Vim’s branching undo I’d want that branching to also be reflected in the git history, so if I do ‘undo’ a bunch of times and then start typing again, there’s a git branch that reflects my prior state that I can go back to (and, ideally, as we did with Étoilé, allow easy cherry-picking from other undo branches). But what I really want is that exposed with a nice GUI in a graphical editor. I rarely use vim’s branching undo because I can never remember the commands.
Why can’t you claim that?
Because if you customize vim a lot (custom keybinds, functions, plugins, whatever, …) then you will build muscle memory and habits that are tied to your vim setup. With that in mind, using vi on OpenBSD or vim.minimal on ubuntu server would still be a pain, because you’d lack all the customisation from your local setup.
To sum it up, vim is installed everywhere, but your customisations are not, so you can only benefit of one of these advantages at a time.
This is where Emacs shines. With Evil and Tramp, one can use the familiar customised vim keys while editing files remotely, as long as the remote system has SSH.
Just FYI, vim has remote editing as well.
As @swehren mentioned, vim can edit remote files by specifying path as “
ssh://host:/path/to/file”. I don’t know how this works with your emacs plugin, but this is definitely not ideal. I use vi to administrate my dns/mail/http servers, and even though I could easily edit file comfortably from my local machine, I still need to login on the remote end to restart services, read logs, etc… The only use case I see is to edit PHP files remotely, and even then this would be bad, because you cannot use autocompletion of filenames, and saving files takes longer due to network latency.Navigation file structure and editing files locally is still the easiest option IMO. And this is also why OpenBSD added
mg(8)to the base system !Tramp is not so much a plugin, as a “Transparent Remote (file) Access, Multiple Protocol”. When connected via one of the various methods (inline, external or GVFS-based) you get to do almost everything as you would on a local system (therefore “transparent”). That means you can also use
M-!or Eshell to run commands, copy files, diffs, etc. without having to worry where what is.I found evil to not include all the things my vim setup has, but won’t remember what until I try to use them again.
Good point. Maybe this calls for splitting up my vimrc into two files, a .basic.vimrc which has commonly used configuration not tied to plugins or installed programs and my regular .vimrc which would source the former.
The .basic.vimrc can then be copied wherever I need it.
A different solution is to go with an empty
~/.vimrc(the simple existence of this file automatically set “nocompat”, so you get a full vim experience), and try your best to use it like this. Vanilla vim is already real powerful as an editor, and once its default keybinds and mechanism enter your muscle memory, you’ll realize just how futile many plugins are.I did that for years (working on personal C projects mostly), and it was great. I then switched to vis 2 years ago, and never looked back. It mixes vim with sam, so you get multiple selection and cursors on top of vim, which is neat. As it really ressemble vim, I can apply my muscle memory to defaukt vim as well, except for the substitute command (which is :x/foo/ c/bar/ in vis).
The fact I commited to using default vim for so long helped a lot switching to vis, as it doesn’t have the same plugins (though it can be extended in lua).
Good suggestion, however gvim is incredibly ugly without any color schemes and I really like being able to copy-paste with ^C and ^V.
Heavily cutomized vim very quickly starts looking nothing like vanilla vim. It’s infeasible to carry around your dotfiles everywhere (though there are ways you can bring subsets of your configuration everywhere), and the more customizations you have, the less effective you’ll be without them. It has to do with the emphasis on macros and simple keybindings that vim has and the muscle memory that requires.
See my other comment on a potential solution: https://lobste.rs/s/wpmmbt/should_i_use_vim_full_time#c_gg386z
In practice, I think I disagree. I use vim on production machines and sundry random boxes with little customization, and I use local copies with dozens of plugins and a stack of custom keybindings. There are occasional frustrations, but not especially overwhelming ones.
“Being able to use roughly the set of vi features plus some niceties” remains a fairly portable skillset. I might have a different experience if I’d overridden the core vi-style semantics of the interface all that much, but apart from a couple of bindings I haven’t, and I’d suggest that best practice is to leave most of that stuff in place and augment it rather than replacing it. That’s why there’s a convention of prefixing things with the leader key and so forth.
As always, it’s a gradient. I was thinking more of people customizing to look like this, remapping hjkl, etc.
And besides, I was just talking about the argument. Practice is a different thing, but when you see people who have only used vim try to use vi and seem just as confused as a newcomer, then I do think that there is a difference worth mentioning.
I think there’s two sides to vim: there’s vim itself, which has the virtue of being available on most platforms but is in many ways inferior to a modern IDE (even with loads of plugins), and then there’s the vim model of editing, which has been ported to many other editors and IDEs with plugins (though of course they’re emulation layers, and might not always work the way vim does). You don’t really need to use vim itself to get most of its benefits.
And that’s why Emacs exists. It even has a best-in-class set of
vimkeybindings. And it has a wonderful extension language. It’s a Lisp Machine for the 21st century!That just means he needs to learn more Vim. It does indeed support tabs, and splits too, and IMO does it better than most IDEs. And you can get a file tree pretty easily too with Nerdtree. I have no issues with editing a bunch of files at once in Vim. Features like being able to yank into multiple registers is much more of a help there.
I suspect one problem people have with vim and editing multiple files is that they only know about buffers, which can be a little tricky to work with, but I don’t think many people realise it does actually have tabs too.
I frequently open multiple files with
vim -p file1 file2which opens each file in a tab, and you can usegt,gT, or<number>gtto navigate them. There’s also:tabe[dit]in existing sessions to open a file in a new tab.I generally find this pretty easy to work with and not much harder than doing something like
Cmd-[/Cmd-]as in some IDEs.There is some debate on whether tabs should be used this way in Vim. I used to do it this way and then I installed LustyJuggler and edited all my files without tabs.
But if it works for you, more power to you!
As a sort-of an IDE power user, I would argue that editor tabs are a counter-productive feature: https://hadihariri.com/2014/06/24/no-tabs-in-intellij-idea/.
That said, while you can work with tabs like this, that’s not entirely the idea of them. Tabs in Vim are more like “window-split workspaces” where you can keep your windows in some order that you like. With one buffer in one window per tab you do get a pretty similar workflow to tabs in other editors, but then again you could get a similar workflow with multiple buffers in one window even before Vim got tabs.
Guess tabs fall in the tradition of vim naming features different than one would imagine: buffers is what people usually understand as files, windows are more like what other editors call splits and tabs are more like workspaces.
Oh, to be clear I don’t have one buffer per tab. I do tend to use them more like workspaces as you say. Typically each of my tabs has multiple splits or vsplits and I’ll go back and forth between buffers - but having tabs to flip back and forth between semi-related things can be useful on a smaller screen too.
One of the reasons why I love vim is that I find a lot easier to edit multiple files at once. I can open then with
:vspand:spandshift-ctrl-*my way around them very fast, with NERDtree I can open a directory folder in any of these windows, locate the file, and there you go, I have them arranged in whatever way I want. It makes it super easy to read the multiple files and copy things around. I like my auto-complete simple, I find autocomplete distracting, so I just usectrl-n, but I’m aware this is a fringe opinion, if you want a more feature rich autocomplete,You complete meworks pretty fine for people that like these. Also, I can open any terminal with:terminal… My vim usually looks more like this https://i.redd.it/890v8sr4kz211.png nothing with to do with 1 file per time.Does vim makes me super faster than everyone else? Probably not, it’s just a text editor, but it’s very maleable and I’ve been coding for many years now and I haven’t ever seen the need to not use it. When I need to work on a new language I just install a bunch of new plugins and things get solved.
Nothing against VS Code, but it’s also only super powerful with the right plugins and configurations, there’s more of it out of the box, but without them it would also just be a simple text editor.
What’s a good resource to start learning emacs?
Using it is critical, but I recommend these sources too:
I gave emacs a try through
mg(8), a small editor that ressemble emacs a lot (no LISP though) and is part of the default OpenBSD system. It comes with a tutorial file that takes you on a tour to discover the basics of emacs, starting with the navigation. This is like vimtutor, and it’s great !It also let you discover emacs as a text editor, AND NOTHING MORE! Which is refreshing and helped me reconsider its usefulness for editing text 😉
I got stuck on this plateau for a while myself, but learning how to use splits and tabs is extremely worthwhile. The syntax isn’t any harder than the usual vim stuff, and I’ve found it to be generally more powerful than GUI editors.
So learn how to do it faster with vim :)
You can have file-trees, you can have fuzzy file-finding, you can have horizontal splits, vertical splits, multiple buffers, etc etc etc.
For a bit of inspiration, check out the Destroy All Software screencast series. There are a few episodes on vim (and also an important one on job control), and he demonstrates that once you get comfortable with fuzzy file-finding, it’s unlikely you’ll want to use a file-tree again, except for the occasional instance where you background your vim process to drop into the shell, run
treeto get a high-level overview of the structure, and then foreground vim again.Even just watch it to see the speed at which it’s typical to work at once you gain proficiency. Poking at IDEs seems glacial after that.
Getting comfortable with my text editor is easily one of the best investments I’ve made in my career, and life more generally, probably, since I use vim for almost all writing I do, including email.
I think it’s great, but I think I’m addicted to it. There are things that are simply easier in vscode or pycharm (intelliJ), etc. Especially when it comes to integrating deeper tooling. Language servers are helping, but the (by design) mystery meat navigation of vim, the not exactly 2020 help search system (compare it to the search under Help in every Mac app), keep it a bit hamstrung. I think there’s some great parts to vim, but I learned vi because my initial editor of choice, emacs, wasn’t on the servers I was logging into. And when it was it took too long to startup. Those things aren’t true anymore and I’m still stuck on hjkl and :, etc.
There are worse things to get addicted to, plus vim-mode in some of the more modern editors isn’t half bad if you need some of their features.
Like @david_chisnall I in the end wrote my thesis in vim (undergrad and phd) so yea, it just rules. I’d still say I’ve heard of 80% of the things vanilla vim can do, but I use about 5-10% on a regular basis.
Seems the poster’s answer is “no”. I’d say it’s “yes”. But there are a few qualifications. First, you should be able to get what you need from an IDE in vim - with eg ctags and language plug-ins, you should be able to autocomolete and go to definition in vim. Second, you of course need vi(m) key bindings in your browser, and decent key bindings in your window manager - so you stop needing to use the mouse.
Strong agree on vim bindings in the browser. I find however that these bindings don’t work universally across all websites due to differing designs and layouts (“don’t work” as in ergonomics, not code correctness), so browsing is only sometimes keyboard-only.
Even as someone who extensively customizes vim, strong disagree that this is the right solution for big projects, especially (e.g. at work) where you might have one or two usually well-supported languages across everything. Why do all that configuration if a good IDE will ship that behavior and more out of the box. Most of them even do it with vim-like bindings available.
As a security person, I spend more of my time reading and modifying code than creating new code from scratch, and often I’m reading for understanding rather than for debugging, of which the latter requires more depth. The code I interact with is in a myriad of different languages, and is often functionally and decomposed poorly or not at all. This lends itself to a highly configured vim. If I worked on “Large Code”TM then I would likely use an IDE.
I use vim full time, and to achieve that I use tmux and have multiple instances of vim running. So I can switch with Ctrl+b, n/p, create a new window Ctrl+b, c.
Jumping to definitions is possible with vim, however I barely use it. I use
vim-gowhich allows me to do:GoDefto jump to the definition in my Go projects.I recently discovered that you can cut in vim to the system clipboard with
"+x, then use the usual paste"+p.It’s better than that, anything that yank content (
d,x,c,y,swill work with named register ("+). Want to cut the current expression body ({...})? Do:"+di{If you are on Linux you have two system clipboards: selection and clipboard. * And + respectively.
Agree, vim is great until you need to work between multiple files. Then a ton of complexity is involved to work between files. I like my current setup where I use vim for single/small files and then VSCode + vim plugin for projects.
I think it highly depends on the user. For me working with many files in Vim is a breeze and I do not see any disadvantages or reasons to switch.
I used Vim full-time for about six years until I discovered kakoune. Now that serves as my daily choice. as others have mentioned, once you add LSP support to any editor it becomes about as feature-ful as an IDE, so the choice really comes down to things like how you navigate the interface.
I’ve been using vim too long to be able to understand the idea of it being bad for multiple files. Is the workflow they’re doing something “vim file1”, edit, close, “vim file2”? Or typing :e ?
I use nerdtree and fzf for everything, splits if I want to see multiple files at once.
I don’t quite understand what the OP means with “full time”. From what I see he couldn’t replace his browser with vim, which is uhm, somewhat understandable, since vim is an editor, not a browser. He notes that IDEs are better file explorers which they might indeed be, but no word on whether he’ll continue to use vim emulation modes or not.
I think that’s most interesting question: did working in the modal vim way sway you to use this interaction mode more than you did before? For me personally the answer is yes, I’ve incorporated some vim patterns into my broader life (like using vim-like plugins for my browser, using hjkl as cursor keys on my computer) but is it for the OP?
And yes, there is a Vim washing detergent but I didn’t replace my washing machine with vim, so I guess I am not using vim “full-time”.