> Any popular editor usually has a “Vim mode” that you can install and you can achieve native Vim productivity.
I would editorialize this to say "closish to native vim productivity", since there are virtually no vim mode plugins for popular editors which offer a complete set of vim features. Even EVIL mode (as of the last time I checked it) has a few notable discrepancies which arise from mapping Emacs functionality to vim keybindings.
> I’d rather do my part to ensure good desktop software will continue to exist, even if it’s proprietary. I will not use shitty software just because it’s open source.
Perhaps I'm just a troglodyte, but I agree with this sentiment heartily.
I have never considered moving though, because although the other editors may emulate vim itself pretty closely, I highly doubt that the vim econsystem of plugins which I'm used to (my particular flavoring of keyboard-only window management, autocomplete, file tree navigation, searchability, etc) would be portable over. Vim is more than just hitting j to go down a line and ce to replace a word to me.
At the absolute minimum I need a port or something very, very similar to NERDTree and vim-easymotion in the new environment.
To go to the reverse route, I'm a SublimeText and Vim user that's debating going back to pure vim.
Much of the functionality that I used ST for I found Vim could do naturally, with no plugins. This presentation taught me alot (https://www.youtube.com/watch?v=3TX3kV3TICU), such as basic command completion.
There is some stuff that Sublime can still do that I don't think Vim can (multi-cursor editing comes to mind, and that's still really handy when I'm making edits to HTML). Other stuff can be done by both but I happen to like ST's better (the awesome GitHub package comes to mind).
And finally, I did pay $70 for an ST license, so I imagine I'll keep using it for another few years or so. But given that I do alot of remote administration on RHEL/CentOS boxes where vim is the only thing I can safely assume to be installed, it doesn't hurt to stay fluent in vim for such a day.
> There is some stuff that Sublime can still do that I don't think Vim can (multi-cursor editing comes to mind, and that's still really handy when I'm making edits to HTML) […].
I'm trying this route as well. ST is so much easier to use and learn because it's like all the other editors I've ever used. Vim is completely different in everything, it's an entire other language.
My underlying thought is though, that if I can become fluent in Vim's world, the layer between thought and coding becomes thinner.
I do want to write a translators guide from ST to Vim. Simple things like 'Tabs = Buffers' (which are different to Tab pages) I had no idea about until recently.
I'm strongly considering Spacemacs or evil mode having seen some of the cool things emacs can do, but aside from that, no text editor has ever grabbed me like vim. n++, Sublime, Atom, VS Code - I just don't achieve the same level of flow with any of them.
I would agree with you, except I really do feel like NeoVim has fixed nearly every big problem I've had with Vim.
There were definitely hackey things you had to do with regular Vim, but NeoVim adds a much better interface for plugins and lets you use whatever languages you'd like for making plugins...Not to mention that it has had proper async support for years now, much before regular Vim got it.
Using NeoVim, I can still do all my work in the terminal with tmux, and have the interface that I'm familiar with. Sublime is a great editor, and I use it as a quick little "paste-buffer", but I don't really feel I'm as productive with it as I am with my NeoVim + tmux combo.
"Why I'm no longer using vim and now using X" typically result from not digging into Vim enough. All the issues the OP is having have been resolved from either updates to vim, switching terminals, or just understanding vim basics.
NOTE: Plugs can be slow and the OP is correct that some are hacky, but typically there's the Vanilla Vim solution to a problem that takes a little bit of reading and/or finding to solve.
If plugin/loading speed is really an issue then switch to using Alacritty and Neovim, use vim-plug for async & lazy loading plugins. You get truecolor support and you're using your GPU to render everything. If plugin speed is still a problem, learn why they're loading slowly, then dig into why rather than just saying "they're hacky or clunky". Silver search is great, but if you understand how to execute terminal commands from vim (:!) then you can grep everything and remove the need for silver search. I use FZF (https://github.com/junegunn/fzf) which is another fuzzy searcher that's optimized for speed, built with Go.
For those that don't want to put in the time to optimize and learn vim, then by all means switch editors. But don't blame the editor ("I will not use shitty software just because it’s open source.") unless it's truly the root of the problems, explore and find better ways. A key thing to remember as a Vim user is there's always a faster way and your .vimrc will always be different from another's.
>If plugin speed is still a problem, learn why they're loading slowly, then dig into why rather than just saying "they're hacky or clunky".
I'd rather switch to an editor where I don't have to do that. After years of using Vim/Neovim, that's what I recently did. I'm planning to remove my Neovim config down to its bare essentials to speed it up and use it as a simple text editor, because that it does well; but even with a carefully tended for configuration, it's been a horrible experience as a programming environment.
Slow or buggy autocompletion (and I have tried it all with all types of configuration, deoplete, YCM, neocomplete, neowhatever, etc), problematic file management (NERDtree not playing well with the rest of Vim, netrw being buggy, VimFiler being slow), syntax highlighting being slow and often buggy compared to plugins from other editors... And then there's the whole having to glue together plugins that don't work nicely with each other, my god how many entire days have I wasted on that.
On the other hand, I have set-up Atom (for Elm) and VSCode (for everything else) with nearly no effort and no experience in very little time. And while their Vim-modes cannot compare, putting up with that is less stressful that putting up with a poor everything-else.
I have really high hopes for the Neovim project extracting all the text editing juice without the legacy, and to a lesser extent, the Xi editor (assuming Vim bindings are ever prioritised, otherwise it'll never be able to compete with Neovim); but right now, while Vim may be the best text editing experience it's nowhere near being in the same league of programming productivity of modern text editors.
Last time I mentioned having switched away from Vim due to its plugins not giving the functionality I get elsewhere, the reaction was not good. As with the parent comment, somehow it was my fault, as I'd failed to update to the latest vim, changed terminals, or '[understand] vim basics'.
I've been using various vi-alikes, including vim, since 1996, so, yes, I have used just about every vim plugin, used vi[m] on every terminal you can name, plus several you may have forgotten existed, and would guess I know the basics by now, considering 90% of what I've edited over the last 20 years has been through Vim and most of the other 10% has been through work-alikes.
Please don't insult people by making assumptions about their knowledge, experience and commitment. I - and the OP, I assume(!), have put the work in and have decided the grass might be greener elsewhere. Please respect that and be constructive. The OP seems to be trying to help others by pointing at what they did / are doing to try and live with another editor.
> If plugin/loading speed is really an issue then switch to using Alacritty and Neovim, use vim-plug for async & lazy loading plugins.
I already do.
> Silver search is great, but if you understand how to execute terminal commands from vim (:!) then you can grep everything and remove the need for silver search
I used that for CtrlP and in my experience returned better results. I know how to use grep and I use it frequently outside of Vim.
You don't need to gratuitously bash the open source community because you don't like Javascript-based editors. It doesn't make any sense, you are just ranting. There are plenty of open source projects inspired by Sublime Text, written in many different languages and environments.
I've recently switched from Sublime Text to Atom. I've used Sublime for a few years and was very unimpressed when I first installed Atom 2 years ago. For a long time it remained slow and clunky, but recently not only did they improve performance significantly but also made the whole user experience much easier and pleasant.
I suggest taking a look at Atom before spending money on Sublime. The number of plugins and extension is just enormous. You might get surprised.
I tried to use Atom for a while, but it becomes slow once you load a few projects. With Sublime or Vim i can have more than 4 instances and it stills runs smooth, but Atom starts lagging and feels heavy.
I'd recommend fzf over CtrlP and Command-T. It is incredibly quick and extremely reliable. Reason why it's so fast: not really a vim plugin, fzf is just a wrapper to an external fzf command.
Once installed, you'll also get shell extensions in bash/zsh also as a bonus (fuzzy auto-completion, fuzzy command history with Ctrl-R).
I went through a similar change, switching to Sublime a few years ago. However, I hate to say it as a die hard Linux enthusiast, Visual Studio Code is by far the best editor.
However, Vim always works. What do I mean by this? Chances are if you do any real development work, you are having to remote into another system. For sublime, VSCode, etc... you'll have to Mount the remote file system. Well that has failed me a few times, especially if the remote system does not support anything other than sshfs and you are on Windows machine. Terminal access means Vim. Vim just works 100% of the time.
So... I've come back full circle to Vim, because it just works and I don't have to change my workflow, because I'm in a different environment/borrowed machine.
> What I didn’t like about Vim was that a good number of plugins always felt like a hack.
> Also, why not Emacs? I wanted to change my editor, not my operating system :P.
He really made a mistake here, IMHO. Spacemacs is exactly the right solution here: can run on the console, can run in a GUI, meant to be extended (extending emacs isn't a hack: it's using emacs).
I briefly tried Emacs both alone and with Spacemacs. Spacemacs configuration is impenetrable, specially if you're not a LISP fan and Emacs simply needs a lot of glue to work well with Evil. Even then one has to know and use quite a few regular keybinds. At that point it just wasn't worth the effort to me over using a more modern and straightforward editor.
Until vim 8, everything in vim ran in a single thread with little or no cooperative multitasking. So if you have a handful of plugins that do any non-trivial thing with the contents of a buffer in real time - dynamic syntax highlighting, running an external process or other such things - pretty soon those milliseconds add up and there is a visible delay between your typing and the on-screen cursor. Vim 8's background tasks were created precisely to deal with these sort of problems.
Even basic highlighting and the mentioned relative linenumbers will put VIM to sleep. Which honestly is absolutely pathetic (and a know problem which was never fixed).
The file opener/finder ctrlp is kind of slow as well (there is a different search engine for it which is an order of a magnitude faster).
I really like the vim keybindings and just use ideaVim plugin for intellij which can do all the vim stuff i need and has the ide functionality on top.
And it is faster as well (at least it can do relative line numbers without dying)
Yes, just look for the most popular plugins. Or try using a popular "dotfiles" configuration, compare it with a raw Vim and it's really slow. With sublime you can have a lot of plugins and it doesn't affect the speed.
The plugins the OP was using are pretty heavy, the real question to ask if they're necessary. Just using the default netrw over Ctrl-P is a great alternative with little or no cfg. Syntastic is overkill IMO, just use an IDE at this point - Also using silver search is great, but not necessary if you understand how to Grep.
Honestly the author just lacked the time and knowledge to go ahead and learn basic bash tools and utilize them.
This is one of the most annoying things about being in a node js project, whether you're just grepping or searching for a specific file it's a real pain point if you've forgotten to ignore it
Nano for configs & logs, sublime for long term programming. I either user vim mode in sublime for movement or my own hotkeys that are more easy for me to remember. mulicursor editing is a must and a game changer from the days of editing 1400 lines at once without it. atom was soooo close to fitting my needs but it failed big time on opening files over ssh mounted file systems.(electron issue?) if that gets fast maybe I'll go back. The JavaScript modding and plugins were kind of nice.
I've been using rnu for fairly long time and it has never slowed me down. Ctrl+D/Ctrl+B for forward/backward paging combined with /<search> is very fast in Vim. Maybe because I don't use any heavy plugins.
On the topic about plugins, does anybody know of a plugin which allows me to give "names"/"tags" to files so that I can jump back to them with a shorter "name" instead of the full path?
In my experience both JetBrain's Vim plugin for their IDEs and the Visual Studio (not Code) plugin are better than the VSC plugin, but the latter is the best I've tried after those two.
For me, the biggest advantage of VIM is vim-tmux-navigator, which makes navigating between vim splits and tmux panes seamless. Pressing CTRL-{h,j,k,l} navigates to the next split or pane in that direction.
I don't think I'll ever be able to switch to a GUI editor unless I can navigate between that editor's splits and my tmux panes in the same way.
I just can't muster going back to an IDE after using Vim for the last several years. It does everything I need a text editor to do, is super lightweight and is almost always available. I bet I could use vi in a toaster.
This is essentially the choice I made a couple years back. Vintageous isn't perfect but it's the best vim emulator I've used. Sublime is a great text editor on top of it.
[+] [-] falcolas|9 years ago|reply
> Any popular editor usually has a “Vim mode” that you can install and you can achieve native Vim productivity.
I would editorialize this to say "closish to native vim productivity", since there are virtually no vim mode plugins for popular editors which offer a complete set of vim features. Even EVIL mode (as of the last time I checked it) has a few notable discrepancies which arise from mapping Emacs functionality to vim keybindings.
> I’d rather do my part to ensure good desktop software will continue to exist, even if it’s proprietary. I will not use shitty software just because it’s open source.
Perhaps I'm just a troglodyte, but I agree with this sentiment heartily.
[+] [-] lunixbochs|9 years ago|reply
I'm aiming to change that: https://github.com/lunixbochs/ActualVim
NeoVim needs a bit more remote UI work to enable every Vim feature, but it's still very powerful to embed right now.
[+] [-] sushisource|9 years ago|reply
[+] [-] savanaly|9 years ago|reply
At the absolute minimum I need a port or something very, very similar to NERDTree and vim-easymotion in the new environment.
[+] [-] AdmiralAsshat|9 years ago|reply
Much of the functionality that I used ST for I found Vim could do naturally, with no plugins. This presentation taught me alot (https://www.youtube.com/watch?v=3TX3kV3TICU), such as basic command completion.
There is some stuff that Sublime can still do that I don't think Vim can (multi-cursor editing comes to mind, and that's still really handy when I'm making edits to HTML). Other stuff can be done by both but I happen to like ST's better (the awesome GitHub package comes to mind).
And finally, I did pay $70 for an ST license, so I imagine I'll keep using it for another few years or so. But given that I do alot of remote administration on RHEL/CentOS boxes where vim is the only thing I can safely assume to be installed, it doesn't hurt to stay fluent in vim for such a day.
[+] [-] cseelus|9 years ago|reply
https://github.com/terryma/vim-multiple-cursors
I use this with NeoVim and it works perfectly.
[+] [-] icc97|9 years ago|reply
My underlying thought is though, that if I can become fluent in Vim's world, the layer between thought and coding becomes thinner.
I do want to write a translators guide from ST to Vim. Simple things like 'Tabs = Buffers' (which are different to Tab pages) I had no idea about until recently.
[+] [-] cholantesh|9 years ago|reply
[+] [-] callesgg|9 years ago|reply
[+] [-] tombert|9 years ago|reply
There were definitely hackey things you had to do with regular Vim, but NeoVim adds a much better interface for plugins and lets you use whatever languages you'd like for making plugins...Not to mention that it has had proper async support for years now, much before regular Vim got it.
Using NeoVim, I can still do all my work in the terminal with tmux, and have the interface that I'm familiar with. Sublime is a great editor, and I use it as a quick little "paste-buffer", but I don't really feel I'm as productive with it as I am with my NeoVim + tmux combo.
[+] [-] EduardoBautista|9 years ago|reply
[+] [-] hhsnopek|9 years ago|reply
"Why I'm no longer using vim and now using X" typically result from not digging into Vim enough. All the issues the OP is having have been resolved from either updates to vim, switching terminals, or just understanding vim basics.
NOTE: Plugs can be slow and the OP is correct that some are hacky, but typically there's the Vanilla Vim solution to a problem that takes a little bit of reading and/or finding to solve.
If plugin/loading speed is really an issue then switch to using Alacritty and Neovim, use vim-plug for async & lazy loading plugins. You get truecolor support and you're using your GPU to render everything. If plugin speed is still a problem, learn why they're loading slowly, then dig into why rather than just saying "they're hacky or clunky". Silver search is great, but if you understand how to execute terminal commands from vim (:!) then you can grep everything and remove the need for silver search. I use FZF (https://github.com/junegunn/fzf) which is another fuzzy searcher that's optimized for speed, built with Go.
For those that don't want to put in the time to optimize and learn vim, then by all means switch editors. But don't blame the editor ("I will not use shitty software just because it’s open source.") unless it's truly the root of the problems, explore and find better ways. A key thing to remember as a Vim user is there's always a faster way and your .vimrc will always be different from another's.
Edit: For those interested in my setup (https://github.com/hhsnopek/dotfiles/blob/master/.nvimrc)
[+] [-] mixedCase|9 years ago|reply
I'd rather switch to an editor where I don't have to do that. After years of using Vim/Neovim, that's what I recently did. I'm planning to remove my Neovim config down to its bare essentials to speed it up and use it as a simple text editor, because that it does well; but even with a carefully tended for configuration, it's been a horrible experience as a programming environment.
Slow or buggy autocompletion (and I have tried it all with all types of configuration, deoplete, YCM, neocomplete, neowhatever, etc), problematic file management (NERDtree not playing well with the rest of Vim, netrw being buggy, VimFiler being slow), syntax highlighting being slow and often buggy compared to plugins from other editors... And then there's the whole having to glue together plugins that don't work nicely with each other, my god how many entire days have I wasted on that.
On the other hand, I have set-up Atom (for Elm) and VSCode (for everything else) with nearly no effort and no experience in very little time. And while their Vim-modes cannot compare, putting up with that is less stressful that putting up with a poor everything-else.
I have really high hopes for the Neovim project extracting all the text editing juice without the legacy, and to a lesser extent, the Xi editor (assuming Vim bindings are ever prioritised, otherwise it'll never be able to compete with Neovim); but right now, while Vim may be the best text editing experience it's nowhere near being in the same league of programming productivity of modern text editors.
[+] [-] rikkus|9 years ago|reply
I've been using various vi-alikes, including vim, since 1996, so, yes, I have used just about every vim plugin, used vi[m] on every terminal you can name, plus several you may have forgotten existed, and would guess I know the basics by now, considering 90% of what I've edited over the last 20 years has been through Vim and most of the other 10% has been through work-alikes.
Please don't insult people by making assumptions about their knowledge, experience and commitment. I - and the OP, I assume(!), have put the work in and have decided the grass might be greener elsewhere. Please respect that and be constructive. The OP seems to be trying to help others by pointing at what they did / are doing to try and live with another editor.
[+] [-] EduardoBautista|9 years ago|reply
I already do.
> Silver search is great, but if you understand how to execute terminal commands from vim (:!) then you can grep everything and remove the need for silver search
I used that for CtrlP and in my experience returned better results. I know how to use grep and I use it frequently outside of Vim.
[+] [-] Terriblehn|9 years ago|reply
[deleted]
[+] [-] bbmario|9 years ago|reply
http://limetext.org/
http://edbee.net/
https://github.com/richrd/suplemon
https://plugins.geany.org/geanyextrasel.html
Since they are all open source, if you don't like something, just change it.
[+] [-] EduardoBautista|9 years ago|reply
I'd much rather give the Sublime Text devs money. I don't have the time or knowledge to create an editor as good as Sublime Text.
[+] [-] bitcharmer|9 years ago|reply
I suggest taking a look at Atom before spending money on Sublime. The number of plugins and extension is just enormous. You might get surprised.
[+] [-] randomsofr|9 years ago|reply
[+] [-] iaml|9 years ago|reply
[+] [-] c0achmcguirk|9 years ago|reply
In my experience Sublime is _much_ slower than Vim.
[+] [-] rodorgas|9 years ago|reply
Once installed, you'll also get shell extensions in bash/zsh also as a bonus (fuzzy auto-completion, fuzzy command history with Ctrl-R).
https://github.com/junegunn/fzf
[+] [-] bphogan|9 years ago|reply
[+] [-] iamNumber4|9 years ago|reply
However, Vim always works. What do I mean by this? Chances are if you do any real development work, you are having to remote into another system. For sublime, VSCode, etc... you'll have to Mount the remote file system. Well that has failed me a few times, especially if the remote system does not support anything other than sshfs and you are on Windows machine. Terminal access means Vim. Vim just works 100% of the time.
So... I've come back full circle to Vim, because it just works and I don't have to change my workflow, because I'm in a different environment/borrowed machine.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] zeveb|9 years ago|reply
> Also, why not Emacs? I wanted to change my editor, not my operating system :P.
He really made a mistake here, IMHO. Spacemacs is exactly the right solution here: can run on the console, can run in a GUI, meant to be extended (extending emacs isn't a hack: it's using emacs).
[+] [-] mixedCase|9 years ago|reply
[+] [-] diminish|9 years ago|reply
[+] [-] sirtaj|9 years ago|reply
[+] [-] LordHeini|9 years ago|reply
The file opener/finder ctrlp is kind of slow as well (there is a different search engine for it which is an order of a magnitude faster).
I really like the vim keybindings and just use ideaVim plugin for intellij which can do all the vim stuff i need and has the ide functionality on top. And it is faster as well (at least it can do relative line numbers without dying)
[+] [-] randomsofr|9 years ago|reply
[+] [-] hhsnopek|9 years ago|reply
Honestly the author just lacked the time and knowledge to go ahead and learn basic bash tools and utilize them.
[+] [-] meow_mix|9 years ago|reply
This is one of the most annoying things about being in a node js project, whether you're just grepping or searching for a specific file it's a real pain point if you've forgotten to ignore it
[+] [-] cdevs|9 years ago|reply
[+] [-] noisy_boy|9 years ago|reply
On the topic about plugins, does anybody know of a plugin which allows me to give "names"/"tags" to files so that I can jump back to them with a shorter "name" instead of the full path?
[+] [-] riquito|9 years ago|reply
https://github.com/VSCodeVim/Vim/blob/master/ROADMAP.md
Every "vim mode" plugin should have something like that
[+] [-] mixedCase|9 years ago|reply
[+] [-] gorthol|9 years ago|reply
[+] [-] jitl|9 years ago|reply
I don't think I'll ever be able to switch to a GUI editor unless I can navigate between that editor's splits and my tmux panes in the same way.
[+] [-] cygned|9 years ago|reply
[+] [-] nunez|9 years ago|reply
[+] [-] SloughFeg|9 years ago|reply
[+] [-] knodi|9 years ago|reply