I love VIM... but I feel like VIM's life is coming to an end... as VIM. NeoVIM is just... better. The editor as it stands now is essentially the same, but an actual active development that isn's a single contributor is going to create a better project, and its going to respond to the community more and keep itself more up to date and performant.
I feel bad, in a way, because i have a strong loyalty to vim, but Bram's stubbornness at playing well with others is basically holding onto sand, and we know how that analogy goes...
"actual active development that isn's a single contributor is going to create a better project"
Depends on what your definition of "better" is. If you just want stable software that's bug free, multiple contributors might actually make the software worse. A lot of people use vim in a way such that Neovim will be no improvement.
Neovim could become like the next zsh. I use zsh every day and have for years. I think it's "better". But for most people bash is good enough so they use it. The things that are better in zsh are not things they care about, so they will not bother switching.
I'd be okay with that result (bash : zsh :: vim : neovim). Whatever the result I think vi(m) users are winning in the end. One side benefit of neovim existing is a push for vim to get similar feature and step up their development efforts. One difference I see with this comparison is neovim's goal: `feature-parity and backwards compatibility are high priorities`. If they succeed in this then there'd be little downside to switching.
Every mention of Vim turns into promotion of NeoVIM. Perhaps submit a story about NeoVIM if you want to talk about it. And what value do comments like this add? How am I better informed after reading it?
> NeoVIM is just... better
> an actual active development that isn's a single contributor is going to create a better project
Seriously? Since Vim was first released, probably there have been millions of software projects fitting the latter description that have not been nearly as successful as Vim. There are millions of them on Github right now. And don't forget the personal attack:
> Bram's stubbornness
If stubbornness produced Vim, we need a lot more stubbornness in software development.
>Every mention of Vim turns into promotion of NeoVIM.
I understand the frustration, but doesn't every Hacker News thread have a thread about alternatives (usually including some promotion)? I mean, every Vim thread includes a discussion of Emacs, too.
True, but as someone that visits places specifically for vim like (/r/vim) it get's particularly annoying. It's not that it's out of place here, is just a cumulative effect (for me personally anyway) from hearing about it where it doesn't belong.
I used vim for 20 years, up until about a month ago when I tried kakoune. It's got a new approach to modal editing that I really dig, which makes me realize the thing I loved about vim was that for a long time it was the best modal text editor around. I still think vim is a great project, but kakoune takes a refreshing approach that really clicked for me.
Grammar: kakoune is heavily oriented towards selections.
Things that happen in normal mode operate on the current
selection. It's like using visual mode in Vim, except
it's always on. It takes a little getting used to, since
any cursor move changes the current selection. Part of
its selection orientation is excellent support for multiple
cursors.
Platforms: POSIX only. No support for odd platforms. If
you want to use it on Windows, you have to use Cygwin.
Packaging: basically non-existant. You pull it from github
and build it yourself.
Maturity: kakoune doesn't have version numbers as far as
I can tell. I've had it crash on me, but it's rare.
Community: tiny but vibrant. There's #kakoune on freenode,
which the core team seems to monitor pretty actively.
Syntax highlighting: yes, and it's more flexible than vim's.
You can use it to roll your own colorcolumn, for instance.
Code folding and line wrap: these aren't there in kak, and I
do miss them, but not enough to go back to vim
Tmux integration: awesome in kak, absent in vim. One of my
new favorite things. In general, you can have multiple
editors attached to the same session.
Automation / configuration: There's no such thing as
kakscript, which I see as a plus. Nevertheless, you can
do a lot of stuff here; I haven't scratched the surface,
but there are lots of interesting example kakrc files
out there.
Two main differences for who comes from vim in my opinion:
1) Editing model based on (multiple) selections. Instead of moving around and issuing verbs on objects, as in vim, you are always selecting something and the command (delete, change, yank and so on) comes afterwards.
It may not seem very different from vim, but the huge advantage is the feedback that you get from the editor.
2) Scripting kakoune is totally different from scripting vim and somewhat harder.
If you need something in vim, you write your vim script and that's it.
You can't do this in kakoune because the editor language is not a programming language, but only allows you to communicate with the system.
This is the reason why POSIX is a hard dependency, every script in kakoune usually relies on POSIX binutils to do things.
I've been learning to use UNIX more since I've started to use kakoune.
If your interested in text editors then it's worth watching some youtube videos on kakoune. There are some great ideas in there that even the old dogs could learn from. Actually, a lot of us could learn from it when it comes to things like feature discovery, it's a really good example of complex yet easy to use software.
The reason I haven't switched is because I prefer vims command->motion over kakounes motion-command, which doesn't quite sit well with me and because I don't like the scripting choices they made.
Sorry about that, I can't find any youtube videos either, I must be mis-remembering. I would recommend trying it out though, you don't have to spend long to see many of it's better features.
my take: the main strength and weakness is that kakoune is visual mode by default, so you see the effect of your text object commands without guessing (c3fx? c4fx?). having something always highlighted can be annoying.
Thanks for the pointer. I am getting more and more frustrated with Vim (and neovim is not what I am looking for) and looking for alternatives.
I did try "vis" a while ago and it was alright but not quite there yet. And it was a bit too "sickness" for my taste, e.g. requires shell scripts for completion to ":open".
I do intend to try it again some time but I'll also give kakoune a go.
I haven't tried vis, although it too looks like a pretty solid project.
> I did try "vis" a while ago and it was alright but not
quite there yet. And it was a bit too "sickness" for my taste, e.g. requires shell scripts for completion to ":open".
With regard to that particular issue, kak has a great fuzzy-finder.
edit: It also apparently integrates with ranger, although I haven't tried that.
I've been using `vis` for a while now, and I agree that it used to be overly minimal, but I've submitted enough issues that it now fits my workflow. Once you get past the friction of it not being vim, you can enjoy multiple cursors, a sane scripting language (Lua), sam's structural regex....
Yes, it's time to start thinking about the next twenty years.
Moving vim from a single threaded process to more of an asynchronous server framework is the right move. Emulating vim commands in other editors just doesn't work, we need to turn the edit and command modes into a service.
I also like the endorsement on lua. I'm eager to move my scripting away from vimscript.
Guess it would depend a lot on the dev, but it seems like NeoVim would make sense for one's personal computer, and then Vi/m whenever logged on to a remote server.
I'm a vim neophyte, but it's not like your .vimrc follows you along to those remote servers anyways so things would be different anyways working on a server?
> but it's not like your .vimrc follows you along to those remote servers
It could follow you. In the recent discussion of TMUX some people said that they have remote systems configured in such a way that the personal config files are automatically downloaded when they login as their dedicated user. All you need to do is to put your dotfiles put your dotfiles on S3 (IIRC), download happens on first login (again, IIRC).
In other words, "your config doesn't follow you" is more of a philosophical problem rather than a technical one. Personally, I think it's a bit silly.
I mean, you wouldn't normally think of running Nginx, Supervisord, Redis, Postgres, etc. without config files, so why do you (people who are against personal configs on servers) insist that we use Vim, Emacs, Git, Tmux, etc. without one? Using Vim (less so than Emacs, but still) without your .vimrc is like using Nginx with default nginx.conf. You can still serve static files if you can find your htdocs dir after all.
A sane global (system-wide) config for the tools would solve some issues, but that's a first step towards personal customization (which, as mentioned, is unacceptable for some people), so in practice we're mostly stuck with nearly unusable tools when we work on remote servers...
> but it's not like your .vimrc follows you along to those remote servers anyways so things would be different anyways working on a server?
That's why I don't really customize vim at all, or make fancy macros, or any of that. I work on a half-dozen different machines and OSes every week, I can't be bothered to customize those environments just to lose them every time I re-format.
You could just make config downloads automatic on all your servers, see my comment below.
Doing this - not using customizations - means you're forfeiting 70%-90% of functionality and power of those tools. I don't think it's smart, but well, it is your choice.
This is so nice and so much easier than it seems. And there's no need for a private repo; unless you're ashamed of your dotfiles, you could keep them in a public repo.
They are in a private-ish... its my company's internal... because i do share it with coworkers, but it does setup a lot of environment variables specific to our products, so its not fit for general public consumption :)
I will agree once neovim ships on the major platforms and has functions on par with vim. Their next milestone for Windows support has continued to slip. It's been at 75% complete for many months. Meanwhile, gVim is running great on numerous platforms.
It's not a knock against neovim, but I just hope they can keep things going.
Until vim 8, it was a drop-in replacement, retaining full compatibility with vimrc and all plugins. My switch was seamless, and that was a big goal of theirs. Vim 8 introduced features already found in neovim in an incompatible way, and now the real fork begins.
Well it isn't a drop-in replacement now. And it wasn't a drop-in replacement before either, on the platforms they needlessly removed compatibility with.
Vim introduced features that had been being worked on since before NeoVim, in a way that actually made sense in the context of Vim, and which fit into Vim nicely.
Hitting ^[ needs to be utterly responsive, but this causes that input to take up to seconds to be accepted. I've tried the suggested workarounds in tmux, etc. but the problem stubbornly persisted so I gave up. Will have to check back once that is fixed.
This brings me to a larger point - with Vim I can throw just about any environment/file type/file size at it and expect it to work. NeoVIM is not there yet so it's going to stay on the "try again in the future" list.
" leave insert mode quickly
if ! has('gui_running')
set ttimeoutlen=10
augroup FastEscape
autocmd!
au InsertEnter * set timeoutlen=0
au InsertLeave * set timeoutlen=1000
augroup END
endif
For me personally, a good reason to switch seems to be the NeoVim team itself seems less hostile to new people and making changes. Of course stability is likely important to many people, so there may be many good reasons to stay with vim as other's have stated, but someone refusing an update because it uses ANSI C seems a bit much...
There's the change, and there's what the change says about the project. The change violates the principle that what is in the buffer is there because the user caused it to be there. Since it is a silent change to a principle that vi and its descendants have always followed, it can lead to data loss; the copy in the buffer may have been the only one. The fact that the change was apparently entirely uncontroversial means that neovim does not think through the implications of their changes and/or is not sufficiently concerned about data loss.
If you think the issue is important, you are free to report it; the project has reverted decisions like this when people have complained (most recently, the default value of the `mouse` setting).
On the other hand, considering how much time this had to be discussed, I would think that by and large this is not a mayor concern for users. This commit was made In June 2015, and the discussion about defaults goes as far back as essentially the beginnings of the project in 2014. We inherited this setting from sensible.vim (which many people consider, well, a very sensible minimal configuration), where the issue was discussed and dismissed back in 2013 (https://github.com/tpope/vim-sensible/issues/64). I think the argument there is convincing. Again, if you don't, please discuss it in the appropriate channels.
I feel bad, in a way, because i have a strong loyalty to vim, but Bram's stubbornness at playing well with others is basically holding onto sand, and we know how that analogy goes...