Switching to Sublime Text from Vim in 2017(eduardobautista.com)
eduardobautista.com
Switching to Sublime Text from Vim in 2017
https://eduardobautista.com/switching-to-sublime-text-from-vim-in-2017/
70 comments
> Since they are all open source, if you don't like something, just change it.
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.
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.
You can help the open source project of your choice with money too: https://www.bountysource.com/
You can also help with documentation, translations, bug reporting, QA, etc.
You can also help with documentation, translations, bug reporting, QA, etc.
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.
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.
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 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.
Is VIM with plugins really that slow compared to Sublime Text? I'm curious what plugins OP was talking about.
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.
Vim 8 async was created to prevent/revert a massive exodus to NeoVim. The NeoVim team actually made a (solid) commit that Bram didn't outright reject, but wanted modified. He jerked around the NeoVim team, having them make lots of modifications and in the end basically said 'not gonna do it lol, who needs async anyway'. Out of that came NeoVim. Then NeoVim started to pick up major steam and lo and behold, Vim had async pretty quick.
Right, I've heard that floating around, and it's true that neovim exists primarily due to the lack of async in vim. Whether or not it appeared in vim 8 because of neovim is something I can't personally answer.
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)
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.
Before I switched to emacs I added any vim plugin that looked even possibly useful and usually didn't remove the ones I wasn't even using. I used nvim but didn't do anything fancy with plugins just used pathogen. A quick count shows 127 plugins. nvim loads instantly and exhibits no slowdown I can perceive.
I honestly have no idea where this nonsense comes from.
I honestly have no idea where this nonsense comes from.
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.
Honestly the author just lacked the time and knowledge to go ahead and learn basic bash tools and utilize them.
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 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'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?
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?
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.
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.
Yes, NeoVim is definitely an improvement over regular Vim. Hopefully more people will begin to use NeoVim and make it the standard going forward.
Since the transition from regular vim to neovim isn't as simple as typing a different command (especially if you're invested in vim already), I doubt it will ever replace vim for most users.
For some users, the migration may be as easy as "move these files to these folders", but that's still a hurdle most people will say "why bother" with, especially since NeoVim doesn't offer anything that spectacular for users who don't write plugins.
For some users, the migration may be as easy as "move these files to these folders", but that's still a hurdle most people will say "why bother" with, especially since NeoVim doesn't offer anything that spectacular for users who don't write plugins.
[deleted]
As an avid vim user I was trying to google and see reasons to use NeoVim and I couldn't find any except "built in terminal"
Any advice on why I should switch?
Any advice on why I should switch?
The tab-autocomplete when you hit the ":" key gives out written suggestions.
All the plugins you know and love with Vim should work, and you can write new plugins in virtually language.
New features tend to reach NeoVim faster than with regular Vim; most notably async support.
NeoVim used the XDG system for configs, so it doesn't pollute your home folder with a bunch of dotfiles.
And this might just be in my head, but I just feel like the entire system is a bit snappier and runs faster.
===== EDIT: ====
falcolas pointed out that I was mistaken on the first point:
> The tab-autocomplete when you hit the ":" key gives out written suggestions.
That appears to be in regular Vim.
All the plugins you know and love with Vim should work, and you can write new plugins in virtually language.
New features tend to reach NeoVim faster than with regular Vim; most notably async support.
NeoVim used the XDG system for configs, so it doesn't pollute your home folder with a bunch of dotfiles.
And this might just be in my head, but I just feel like the entire system is a bit snappier and runs faster.
===== EDIT: ====
falcolas pointed out that I was mistaken on the first point:
> The tab-autocomplete when you hit the ":" key gives out written suggestions.
That appears to be in regular Vim.
> The tab-autocomplete when you hit the ":" key gives out written suggestions.
Can you explain this a bit more - how does this differ from vim's tab completion for ex commands?
Can you explain this a bit more - how does this differ from vim's tab completion for ex commands?
:e ~/.vim^I
.vim/ .viminfo .vimrc
:help ctrlp-
'ctrlp-<c-p>' ctrlp-options [...]Looks like I lied (or was using an old version of Vim a few years ago). I just tried it on my machine and got the tab autocomplete with written suggestions in both Vim and NeoVim.
My bad!
My bad!
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.
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) […].
https://github.com/terryma/vim-multiple-cursors
I use this with NeoVim and it works perfectly.
https://github.com/terryma/vim-multiple-cursors
I use this with NeoVim and it works perfectly.
Good to know! Although based on my scenario above, I'd prefer to keep it to vanilla vim, at least until I feel I've mastered it. I thought I had at least a moderate understanding, but 20 minutes of 'vim' searches on youtube demonstrates that the rabbit hole goes far deeper than I could have imagined.
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.
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've been dabbling with Spacemacs for a while now (after having looked at Vim to the point of being able to handle day-to-day editing well enough), and have to say I quite like it. The mnemonics work well enough.
I have previously been using ST too, though, and so far find two of its nicer features lacking in both Vim and Spacemacs:
1) Ctrl-Shift-P. ST's menu is really nice and I always seemed to search for the right words in order to find what I was looking for. You can emulate it with plugins in Vim, and Spacemacs' ´SPC :´ comes close, but they both end up being a bit more awkward than necessary (with emacs, it's mostly due to the function naming scheme and the terminology used).
2) I found the various flavors of multi cursor support in both Vim and Spacemacs not to be equally elegant as in ST. ST allowed you to do some amazing edits with Ctrl-F and some basic Regex knowledge (using Alt-Return). On the other hand, I learned that this can mostly be mitigated by the usage of mostly simple on-the-fly macros with Vim-syntax, so it's not that much of a problem.
I have previously been using ST too, though, and so far find two of its nicer features lacking in both Vim and Spacemacs:
1) Ctrl-Shift-P. ST's menu is really nice and I always seemed to search for the right words in order to find what I was looking for. You can emulate it with plugins in Vim, and Spacemacs' ´SPC :´ comes close, but they both end up being a bit more awkward than necessary (with emacs, it's mostly due to the function naming scheme and the terminology used).
2) I found the various flavors of multi cursor support in both Vim and Spacemacs not to be equally elegant as in ST. ST allowed you to do some amazing edits with Ctrl-F and some basic Regex knowledge (using Alt-Return). On the other hand, I learned that this can mostly be mitigated by the usage of mostly simple on-the-fly macros with Vim-syntax, so it's not that much of a problem.
Thank you you have just saved me weeks worth(or more) of time over my future lifetime.
I would recommend vim-easymotion and command-t for a big speed improvement over relativenumbers and CtrlP.
In my experience Sublime is _much_ slower than Vim.
In my experience Sublime is _much_ slower than Vim.
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).
https://github.com/junegunn/fzf
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
That's odd. I switched from Command-T to CtrlP a couple years ago for speed. I wonder now if I should look again.
Unite.vim is really nice too
I only have two comments:
> 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.
> 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.
> there are virtually no vim mode plugins for popular editors which offer a complete set of vim features
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.
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.
I think a lot of us can agree with the last bit, but that said VS Code is actually pretty darn nice.
Do you know how to remove 5 stupid menus on the left; explorer, search, git, debug, and extension.
I don't agree with all these as default.
Explorer (basically the nav tree): Just give me a toggle key and hide it by default please (I mean hide its icon nav too)
Search: really? something + F is fine for short key like the others do.
Git: I haven't even tried to use version control inside text editor. It is just illusion of ease. It's not significantly different from switching to a terminal. A terminal has its jobs to do, please use it. You will use it anyway for other tasks.
Extension: This is even worse to be default. I don't think I have something to frequently do with extensions.
I like its light computation compared to Atom. I had switched to VS Code for a while, then switched back to Atom. Maybe I'm just lazy to remember new keys.
Edit:: Just found it, "Hide activity bar". Sorry for being lazy :/
I don't agree with all these as default.
Explorer (basically the nav tree): Just give me a toggle key and hide it by default please (I mean hide its icon nav too)
Search: really? something + F is fine for short key like the others do.
Git: I haven't even tried to use version control inside text editor. It is just illusion of ease. It's not significantly different from switching to a terminal. A terminal has its jobs to do, please use it. You will use it anyway for other tasks.
Extension: This is even worse to be default. I don't think I have something to frequently do with extensions.
I like its light computation compared to Atom. I had switched to VS Code for a while, then switched back to Atom. Maybe I'm just lazy to remember new keys.
Edit:: Just found it, "Hide activity bar". Sorry for being lazy :/
Jut hit ctrl-b to collapse them. I don't know how to completely get rid of the icon strip, but it doesn't have to be a big sidebar.
Thanks, I knew cmd|crtl+b. But yes, I'd like to completely hide them. It is annoying to see something I don't use appear on screen, even its icons.
Put this in your settings file:
"workbench.activityBar.visible": falseIn my opinion, the fact that VS Code performs well is not something to be praised. For such a minimalistic code editor, good performance should be one of absolute minimum requirements.
The domain of minimal code editors is well explored and quite mature, and the platforms upon which VC runs are all quite stable with well known performance characteristics. If we can't make software work well under these conditions, we have bigger problems that we need to address.
The domain of minimal code editors is well explored and quite mature, and the platforms upon which VC runs are all quite stable with well known performance characteristics. If we can't make software work well under these conditions, we have bigger problems that we need to address.
[deleted]
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.
At the absolute minimum I need a port or something very, very similar to NERDTree and vim-easymotion in the new environment.
> Ignoring the node modules directory
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
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
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.
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 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.
Atom tends to be my go-to, but being built on Electron is what hurts it the most, in my opinion. I don't reboot my work machine often, only for updates, which means that having 2 or 3 projects (in 2 or 3 windows) can eat a lot of memory if it has been open for a while.
It's frustrating having to restart my editor because the Electron window gets stale and needs to be closed.
It's frustrating having to restart my editor because the Electron window gets stale and needs to be closed.
You may also try vs code, in my opinion it is better than atom, albeit not as flexible. Much faster, though.
The primary reason I never really used Sublime is that it is not Open Source. I am happy with Emacs at the moment.
In 20 years of coding, the use of vim or emacs has never quite clicked with me. I get that they're infinitely scriptable but the basic experience of using them just seems so miserable. Sublime is one of my favorite programs ever, for the reason that I so rarely have to think about it or wait for it. Some of the best money you'll ever spend, in my view.
I hate these types of posts...
"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)
"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)
>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.
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.
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.
The intent was not to insult the OP, rather express the problem with all the articles that are "Vim to Editor X/Y/Z" which all, typically, relate to Plugins & Performance. Most problems have solutions that just require more searching. Now I'm not saying you or the OP didn't take time to do this, but using plugins that are slow and bulky like CtrlP and syntastic have their alternatives.
I'm fine with the OP switching editors, I could careless which editor someone is using or switching to, but don't place the blame on plugin performance, plugin bloat, or building an IDE; Vim isn't an all-in-one solution and that's okay, we can push it to be an all-in-one solution.
My constructive criticism is that these problems are in every editor, don't pin it on vim plugins or the amount of plugins you're loading into vim. "releativenumber" is a valid reason to switch editors, but the rest of the reasons are applicable to all editors.
Edit: "switching terminals" -> "switching editors"
I'm fine with the OP switching editors, I could careless which editor someone is using or switching to, but don't place the blame on plugin performance, plugin bloat, or building an IDE; Vim isn't an all-in-one solution and that's okay, we can push it to be an all-in-one solution.
My constructive criticism is that these problems are in every editor, don't pin it on vim plugins or the amount of plugins you're loading into vim. "releativenumber" is a valid reason to switch editors, but the rest of the reasons are applicable to all editors.
Edit: "switching terminals" -> "switching editors"
> 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.
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.
CtrlP has okay results, the best is to perform your own search and do a reverse grep match on files you want to exclude.
If you were already using Alacritty and Neovim, you should expand on why these did not solve your problems as many if not all speed/optimizations can be matched or better than Sublime Text
If you were already using Alacritty and Neovim, you should expand on why these did not solve your problems as many if not all speed/optimizations can be matched or better than Sublime Text
I think that the this "vim mode" plugin for Visual Studio Code has the best roadmap/checklist for supported vim features out there.
https://github.com/VSCodeVim/Vim/blob/master/ROADMAP.md
Every "vim mode" plugin should have something like that
https://github.com/VSCodeVim/Vim/blob/master/ROADMAP.md
Every "vim mode" plugin should have something like that
Hmm. I'll wait for "why I moved back Vim" post.
> 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).
> 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.
> Spacemacs configuration is impenetrable, specially if you're not a LISP fan
I find its configuration very nice — I don't actually use spacemacs regularly, but I miss how clean its package system tends to be over normal emacs configs.
And everyone should be a Lisp fan, since it's the best language we've managed to come up with yet.
> At that point it just wasn't worth the effort to me over using a more modern and straightforward editor.
I don't think there's any editor more modern than emacs; there's certainly none more powerful. More straightforward? Well, nano is probably the most straightforward, but I wouldn't want to use it regularly.
I find its configuration very nice — I don't actually use spacemacs regularly, but I miss how clean its package system tends to be over normal emacs configs.
And everyone should be a Lisp fan, since it's the best language we've managed to come up with yet.
> At that point it just wasn't worth the effort to me over using a more modern and straightforward editor.
I don't think there's any editor more modern than emacs; there's certainly none more powerful. More straightforward? Well, nano is probably the most straightforward, but I wouldn't want to use it regularly.
[deleted]
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.