Vim 8.0 released(groups.google.com) |
Vim 8.0 released(groups.google.com) |
docker run -it -e TERM=screen-256color yaasita/vim:8.0 vim
Maybe https://github.com/vim/vim/blob/v8.0.0002/runtime/doc/versio... ?
> Over Quota
> This application is temporarily over its serving quota. Please try again later.
https://groups.google.com/forum/#!topic/vim_dev/LaYdHDNzJcU
or
If you're going to lightweight and vi-like, than do that. If you're going to go the Emacs route (and if you're adding async, packaging, and lambdas, make no mistake, you're starting in the steps to building an inferior Emacs), than get a half-decent extension language. Or just up and die. We don't need a Vi clone that does the Emacs thing, we've got Evil/Spacemacs for that.
At some point you have drop out of the pseudo Vim world do things the Emacs way, keybindings and all.
For me personally, that's not what I want.
e.g. I like to use C-h as an alternative to backspace, it helps relieves my RSA not have to reach for backspace. Spacemacs provides that binding in some places but not all.
To get get C-h to consistently act as backspace I ended up effectively breaking the help system (which for an Emacs newbie like me is a bad thing).
I found loads of other things like that where I just want it to work the Vim way.
What I _really_ want is a better Vim not another editor pretending to be Vim on a superficial level. I'm glad to have the options that both Vim 8 and NeoVim offer.
Of course Emacs is an amazing bit of software and Spacemacs is a great configuration so if they work for you, more power to you.
or many packages there are many "vim-optimized" packages nowadays, e.g. evil-ediff, evil-org or evil-magit.
> e.g. I like to use C-h as an alternative to backspace, it helps relieves my RSA not have to reach for backspace.
I would do such remapping on the system level. E.g. I personally have my layout implemented in C++ on system level: https://github.com/kozikow/keyremaplinux
> I found loads of other things like that where I just want it to work the Vim way.
In Emacs in general it's easier to customise to do things your way. After a bit investment into learning elisp you can make it work however you want, including vim way. vim is not as customisable.
I guess what I really want is for Vim to decide what it wants to be. You can be simple, or you can be extensible. Vim is kind of trying to be both. Traditionally, Emacs did extensible, and Vi did simple. It's fine if Vim wants to go the emacs route, it's just that I'd rather it stopped doing it so badly: At this point, Vim's extensibility story is embarrassing. It's 2016, the built-in language is rubbish, the external language interfaces are second-class at best. This has to change if Vim really wants to go in that direction. And if doesn't, why bother pretending?
Why would you bash VIM by saying it should die? Just move over to something else and use the "Mom Rule."
No one is compelled to use Vim over Vi, you can just leave it in compatible mode or use another vi binary such as the one in busybox.
As far as the built in language and external API being second-class well you may have a point but both Vim and NeoVim are improving.
Whilst it's still useful and still provides, IMHO, nice ergonomics I'm probably going to stick with either Vim or NeoVim I think. I really don't mind if they never make up their mind what they want to be when they grow up. ;)
From my perspective, I want to see Vim/NeoVim differentiating itself from the competition. It's extensible... but emacs does that better. It's simple and modal... but nvi does that better. It's stuck somewhere in the middle, and mediocrity is a terrible, terrible fate.
Ow! Stop that! Okay, this is the last time I sneak a Dresden Files quote into my HN comments. I swear. :-D.
I love that idea and I keep telling myself I'll go back and give give it another try sometime. Would love to get really into org-mode, etc.
It's just that Vim is so comfortable! ...like a nice old pair of Goodyear welted shoes.
Come to the dark side. We have macros.
Which reminds me, I must reread that stackoverflow post about grokking vi again.
http://stackoverflow.com/questions/1218390/what-is-your-most...
Sure, they come with bindings, but what about my custom bindings? Working with HJKL does not mean they are vim optimized.
Anyways, I only suggested it because you seemed interested. There's certainly no requirement to do so. And since you'll never master every feature in Vim, you'll never use Emacs if you have that requirement.
The sad thing about Vi is its Lisp mode: the original Vi had a pretty nice mode for editing Lisp, which most clones have not recreated.
Donation page: http://iccf-holland.org/donate.html
It seems that you can send bitcoins too: http://iccf-holland.org/bitcoin.html
Imho just mentioning HN in the payment description would be okay :)
There is very few pieces of software I could never imagine replacing in my toolkit. Linux? I use Windows, too. GCC? Clang gets some love sometimes. Languages themselves? I'm fluent in several. Shell? I used Bash for years, now I switched to ZSH, but could go back to Bash if I needed. Tmux? I could also go back to screen if I needed to.
But vim? There's no replacement for vim. vim changes how you think about programming, how you think about software development. It is this frictionless editor (I mean, yes, huge fucking learning curve, but so is programming in general) that, even 20 years later, I will never abandon (unless I'm doing Java, because... fuck Java outside of Eclipse or IntelliJ; and yes, I've tried using that one vim<->eclipse bridge, hell no).
We currently hold the top spot, although I would be happy to see someone surpass that: http://www.vim.org/sponsor/hall_of_honour.php
I'm used to seeing people say "vim" where "vi" is meant (of which vim is but one (much enhanced) clone), so when you say you could switch out gcc for clang, or bash for zsh, could you not switch out vim for (e.g.) nvi[0]? If not, why not?
If you're referring to eclim [0] FWIW I've found it to be an adequate way to have a vim centric workflow with a few excursions into eclipse. If you have proficiency with both tools and enjoy having an eclim server running in a eclipse window you'd get have access to the best features of both tools.
I hope that you're being sarcastic.
Neovim is like the Chrome of the web. A great editor, but also a great forcing function for the ecosystem.
Did Bram Moolenaar tell you that? Otherwise, none of us know what motivated him.
Neovim fans seem to hijack Vim discussions frequently. Sometimes people want to talk about Vim.
http://www.economist.com/news/middle-east-and-africa/2161334...
I would encourage folks to read up on factors surrounding the causes they support. Perhaps organizations like the Free Software Conservancy could use your donation to benefit humanity far more profoundly, even if they can't compete on emotional appeal.
Second-order effects also can make donations to the Free Software Conservancy counter-productive.
As an aside, I wonder if the Free Software Conservancy would want to be seen telling people not to donate to Ugandan AIDS victims and to redirect the money to themselves. My guess is they would not like to see their name here.
> emotional appeal
Life and death has appeal beyond 'mere' emotion. It's more important than free software, and I say that as an avid fan of, and occasional donor and contributor to FOSS projects.
EDIT: A rewording or two
- Async /Io
- Async Jobs
- "Packages", which allow easier built-in bundling of plugins
I'm pretty excited for this release! I've been using Neovim for several months now, but really great to see mainline Vim get these (IMO long overdue) enhancements.
Magit and org-mode are worth it.
I've been using pathogen for a while for plugins..
I will happily give 8.0 a try, but I have never used such perfect software such as vim (and I also don't follow its dev cycle at all) I am really, really surprised a new version came out. I figured I'd be using the same vim until keyboards were completely out of style.
https://danielmiessler.com/study/vim/
Going to download and see what Prezto stuff breaks when I upgrade.
Every Jedi needs to build their own light saber, and come on, it's just 6KLOC or so.
Every real Jedi needs to build their own light saber, and come on, it's just 100KLOC or so.
I've never even considered what goes into making an editor.
inoremap jk <Esc> inoremap kj <Esc>
Async is basically the reason I used NeoVim, so it feels good to come back.
Windows: ftp//ftp.vim.org/pub/vim/pc/gvim80.exe
MD5SUMS: ftp://ftp.vim.org/pub/vim/pc/MD5SUMS
Readme seems incomplete
https://github.com/vim/vim/blob/master/READMEdir/README_mac....
$ brew install --HEAD vim
[1] http://brew.sh
cd /usr/local/Cellar/vim/HEAD/share/vim/vim80/compiler; chmod 644 *.vim README.txt
-bash: cd: /usr/local/Cellar/vim/HEAD/share/vim/vim80/compiler: No such file or directory
chmod: *.vim: No such file or directory
chmod: README.txt: No such file or directory
$ brew update && brew upgrade vim --HEAD
I've since put Windows 10 on my MBPr (performs so much goddamned faster, Ivy Bridge era /w Intel GPU only, 8gb of RAM, decentish SSD for that generation), and use msys2 to fill that gap.
Disclaimer: My company Exelion hosts the msys2 mirror because their project is so important to the Windows community, and Sourceforge was having serious issues at the time. Well worth spending a dedi on them to keep the project going, imo.
(I realise that NeoVim has this.)
Update: Looking at the version8.txt[1] on github, the option seems to be `set termguicolors`
Change seemed to take place at version 7.4.1799[2]
[1]https://github.com/vim/vim/blob/master/runtime/doc/version8....
[2]https://github.com/vim/vim/blob/master/runtime/doc/version8....
Problem: Cannot use true color in the terminal.
Solution: Add the 'guicolors' option. (Nikolai Pavlov)
Files: runtime/doc/options.txt, runtime/doc/term.txt,
runtime/doc/various.txt, src/auto/configure, src/config.h.in,
src/configure.in, src/eval.c, src/globals.h, src/hardcopy.c,
src/option.c, src/option.h, src/proto/term.pro, src/screen.c,
src/structs.h, src/syntax.c, src/term.c, src/term.h,
src/version.c, src/vim.hWhile I usually stick to I, A, N+G, Shitf-ZZ and :q! only, I appreciate the effort and keeping vi alive and well.
Big thanks!
cnoremap sudow w !sudo tee % >/dev/null
Or from inside your editing session:
:w !sudo tee % > /dev/null
For when you find you've edited a file you don't own (e.g. config file) and forgot to sudo first.
That said, I feel like this is a perfect example showing off that the best way (or a at least a very good one) out of stagnation of a piece of software is competition. VIM was dead in the water for a very long time (aync support looking at you), which is but one of the reasons NeoVIM was created, in turn sparking VIM to actually get off its laurels.
I can't help but draw parallels to the Haskell community with stack and cabal-install, to the people that might be familiar with that situation.
Anyhow, I guess I just wanted to also thank NeoVIM for pushing some life into VIM again, besides having it more or less in maintenance mode.
Don't get me wrong, I use vim all the time cause it's there on any machine I log in to, but I found I was MUCH more productive when I paid for a good IDE for development.
And YES I tried using all the plugins to make vim into an IDE. That was half the problem.
$ find foo | xargs nvim
By that time Emacs will have replaced temacs with Guile and someone clever will have added VimScript as a hosted language.
I think that was the main objective of the project. Would be nice to real vim in IntelliJ idea.
Anyway, the things I appreciate more are the fast evolution and the community, no more than one year ago I tried it but was too lazy to compile, wait, configure...
This time I ran homebrew, linked my .vimrc in ~/.config/nvim/init.vim, and forgot I was using Neovim instead of Vim, except for the async compiling/linting.
From what I understand, the plugin community is generally pretty happy with neovim and find it preferable.
I've since switched all my plugins to use async versions and it's sooo fast, didn't think vim could be faster but here we are.
Vim's tabbed interface is quite good, it's basically Vim + a Vim-specific stacking window manager.
I personally use emacs-native way, window-configuration-to-register: https://www.emacswiki.org/emacs/WindowsAndRegisters
In concept though, it is the best solution. Maybe I just have a broken config or something.
What you may be experiencing is an erroneous action stopping the macro. For example, if you press h at the beginning of the line, macro recording would be stopped. To make this behaviour less annoying add: (setq evil-kbd-macro-suppress-motion-error t) .
Sublime-like multi-cursors in emacs are sometimes more useful than macros. I use and like https://github.com/gabesoft/evil-mc .
Regarding other points:
- yes, for huuuge files I still use vim
- Occasional bugs due happen, as in every editor running custom plugins. In emacs debugging and editing plugins code is natural. You can use emacs to debug itself and reload parts of code without restarting.I actually started testing Spacemacs ad Vim was getting slow when highliting big .rs files.
More than anything, Vim for me is a really good set of keybindings.
(setq select-enable-clipboard t)
(setq select-enable-primary t)
It might be that Spacemacs layer is adding additional complexity, and maybe going through Helm is the issue, I don't know, just it does take quite a bit for it to catch up. In Vim, you really are plowing through at the speed of thought.
See https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr...
It's true that emacs can get pretty slow if you have so many things running that you don't even need. It's also useful to defer packages until you actually need them by using autoloads or if you use use-package, `:defer/:commands/:bind` which create them for you.
Perhaps try disabling your layers one at a time to see where the problem is.
Might see in my tone I am not a fan of this fork.
Three of Spacemac's four pillars (mnemonic, discoverable, consistent) make it relatively easy to get the hang of. My early usage looked something like:
- Think of task I want to accomplish that probably has key binding
- Begin typing SPC - <continue drilling down through menus that look promising>
- If that doesn't work, type SPC-: and begin typing what I think the command might be called
- If that doesn't work, search web for "Spacemacs key binding <thing I want to do>"
- If that doesn't work, find/read relevant Spacemacs layer documentation
- If that doesn't work, ask in the Spacemacs gitter channel
- Memorize key binding
Once I learned a binding I found it easy to remember due to the mnemonicness:
open this file in Github? SPC-g-h-o of course (g (git) - h (..hub) - (open))
view most recent search buffer? SPC-s-l (s (search) - l (last search buffer))
maximize this window's buffer? SPC-w-m, etc
Method 1
1. Become proficient in vim
2. Become proficient in emacs
3. Learn spacemacs keyboard shortcuts
Method 2
1. Become proficient in emacs
2. Become proficient in vim
3. Learn spacemacs keyboard shortcuts
I'm a vim user, but I know almost nothing about emacs, so I am having a tough time adopting spacemacs. The basic editing features are a flawless reproduction of vim, but when I do `set textwidth=99` it doesn't work. Then I end up googling how to do this in spacemacs which is apparently `spc : set-fill-column <enter> 99`. This is just one example, but there are many others if you try to do anything different from the spacemacs defaults.
The whole thing should be fun, not just laborious.
http://spacemacs.org/ http://spacemacs.org/doc/QUICK_START.html
Seems like we are now in a feature war between both lets see who comes out winning. This whole thing could have happend so much smoother for the community but stubbornness sometimes lead to interesting innovations :).
https://groups.google.com/forum/#!topic/vim_dev/_SbMTGshzVc/...
Some choice posts:
- Bram (vim author's) response to whether he looked at existing implementation in neovim: https://groups.google.com/d/msg/vim_dev/_SbMTGshzVc/wXmJuL4P...
- Thiago (neovim author's) response to Bram, which was ignored: https://groups.google.com/d/msg/vim_dev/_SbMTGshzVc/XZEXxaxD...
There are lots of other instances of this exact interaction between neovim and vim over and over, it's infuriating. Neovim was started precisely for this reason, an async proposal was made (in 2014!!) which was rudely shut down and all efforts of collaboration were ignored.
That being said I hope they pull an io.js and merge taking the best of both vim and neovim, whatever that may be.
It's happily just compiled and installed for me.
I'm not sure how, in my use case, neovim could improve upon vim. vim's fast, available virtually everywhere, packaged with many OS's and distros, and has a rich and active community. I'm not sure why I'd want to change.
Neovim seems like a fun project ("let's reimplement vim!") but it feels a bit redundant, like a reimplementation for the sake of doing a reimplementation. There's an intangible reason why vim is so popular and has such a following. vim is well engineered, simple, and has been well cared for over the years. If I'm integrating something so deeply into my workflow, electing it the main way I interface with my code, it's going to be the 25 year old project that's beyond reliable, has evolved conservatively and is ubiquitous. Ten years ago I was writing code in the language du jour using vim, and ten years from now I'll be working with the hot new language. In vim.
vim isn't a broken relic of the 90's, it's one of the best, most valuable tools in my toolbox.
Since they've forked it, they've done an amazing job cleaning up the codebase, modernizing the toolchain and implementing great async support, while maintaining almost perfect compatibility with vim. They've also created a real development community where many people participate equally, not just trying to get the "bus factor of 1" commit bit holder to accept their patches.
I switched a year ago, brought all my plugins with me, and have seen only improvements in performance and features. If I had to choose which would survive for the next 30 years, it would be neovim. Thiego Arruda is the best example of an open source leader. I have a deep respect for Bram Moolenar and what he did with vim, but until neovim came along, vim was sclerotic and getting worse. It speaks well of Bram that when real competition came along, he returned to active development of vim.
Evil mode in Emacs seems to be a bit of a crutch. I was actually an emacs user for awhile, and a lot of emacs' power imo comes from using emacs "the right way". I respect emacs and emacs users.
The advice "Don't just do something, stand there!" comes to mind.
Bram has been going to Kibaale since 1994, and he's now presumably busy feeding and clothing a new generation of orphaned children, orphaned by the original orphans. Isn't this precisely the creation of a trans-generational cycle of dependency by Western patrons?
Wouldn't those people rather be in a position to feed and clothe their own population? Perhaps even be the ones sending charitable aid workers to the Netherlands.
What is happening is evidently not a path to freedom and independence. The correct action can be found in inaction.
> Life and death has appeal beyond 'mere' emotion.
Remember it's true: lives are valuable, but our dignity is valuable too.
Should you feel moved to give to Bram's organization, at least consider an offsetting donation to help address the eradication of pristine savannah, extinctions from over-hunting, elimination of biodiversity, and other imbalances which will naturally occur when a human population is suddenly freed from all checks on growth.
https://en.wikipedia.org/wiki/Kibaale_District#Population
Or one might consider just making the world a better place by doing something we actually understand - like, writing software and doing our jobs, instead of staying up late $#!+posting ;-)
That comment makes up a fact and then criticizes it.
I have no idea what the outcomes are for the people Bram helped and I doubt you do, though I'm confident they have a little more food and whatever else he provides. There are still problems in Uganda and there are still problems everywhere in the world, including in rich nations, in your family and mine, in your life and mine; there are bugs in Linux' code. The fact that problems remain doesn't in any way imply that the efforts to improve are counter-productive. That doesn't make sense.
To migrate to Spacemacs, I just replicated my workflow. Earlier I would use `find . ...` extensively for complex grep. I figured the equivalent in Spacemacs. For file navigation I used the NerdTree. I again looked up the key bindings for file navigation. So on, so forth. I now have a pretty decent spacemacs setup.
I would think, this can also classify as a third method, without having to become proficient in Emacs.
Also, the same with Java only being used with Java IDEs, C# only being used with Visual Studio is also a notable exception to my "vim all the things" rule.
I spent quite a lot of time mastering vim. It's beautiful editor and I could be incredibly productive with it, but I'm not sure that there are many people who'll do that.
Its a very non-intrusive vim plugin for Eclipse, just does vim emulation and nothing else.
I've found it to be very pleasant to work with.
I don't think this is a subjective matter? The sequence of events was:
1. async feature was proposed in 2014 and earlier, Bram was opposed to the idea in general
2. neovim was created to integrate async and other improvements
3. lots of plugins started supporting neovim's async
4. vim comes out with its own async feature
You're welcome to ask Bram what motivates him personally, but I'm comfortable with my judgement of causality to the ecosystem as a whole.
> Neovim fans seem to hijack Vim discussions frequently. Sometimes people want to talk about Vim.
You may talk about vim, that's fine. Do you feel neovim is off-topic for vim discussions? It seems fairly related to me.
Not accepting a patch without question doesn't mean he was opposed to the idea.
[0]http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...
1. async feature proposed and implemented in neovim
2. vim comes out with its own async feature.
shazow's post has significantly more evidence of neovim's responsibility, enough that it isn't a fallacious argument. It isn't definitive proof, either.
neovim's approach links libvterm in via C. You could potentially do so via python and ctypes instead, but then you have to count on having a vim compiled with Python support.
Every other programming language I've used a lot of (spanning from assembly to lisp) I've found it most pleasant to work in vim, even in large projects. I suspect the only other environments I'd want an IDE would be for iOS development and C#.
Visual Studio would have been better, if I could have got a decent Windows desktop to span both of my monitors. But since my employer at the time didn't want to get a Windows PC or get a Visual Studio license for this Windows desktop application project, Vim + Samba + SSH were a workable substitute.
C, C++, Python, Ruby, JS, Erlang, Perl, etc, just require a relatively sane text editor, no full scale heavy weight IDE features needed. So, yeah, vim does everything I need there.
Also, who says vim is running in a terminal?
I already use Tmux inside a tiling window manager and generally try to avoid manually managing panes inside Vim, mostly only tabs. There is a finite amount of hierarchical panes and tabs you can work with intuitively, before you wonder why they won't accept each others keyboard shortcuts, especially when you use the same color scheme in Vim, Tmux and Awesome.
> If I tmux then vim, I have to find some way to get the text out of tmux, and then back into vim.
That's actually a valid concern. I use piping for that, but it's not ideal at all. Maybe I will try it out.
Exactly the reason I want to manage terminals in vim. I already heavily use splitting in vim, and find it much faster and simpler to use than screen or tmux. In addition, I typically want integration between those splits, such as displaying the quickfix list in one, or showing 2-3 files in vimdiff, or yanking and pasting between files. Given that, I'd like to just open one more split in vim and have a terminal in it.
The original motivating use case for me: a vertical split, editing a manpage on one side, and showing a continuously updated render of the manpage on the other (using watch).
Helm is super helpful, so most likely I will disable it and see how it goes.
I've seen some of these but I don't think any of them actually follow the tabbed interface paradigm:
* visible tab bar, preferably at the top and preferably style-able so that it doesn't look like it's out of Windows 3.11
* dynamic tab names based on file contents (in case of multiple buffers, show the name of the currently focused buffer), so that there's no need for manual tab name management
* tab navigation through shortcuts (open tab, close tab, move tab left/right, etc.)
It meets all the points you raised, and I agree with them - I prefer evil-tabs for that reason. Although I must that admit that evil-tabs only implements only crucial subset of all vim tabs features mentioned in http://vim.wikia.com/wiki/Using_tab_pages .
I created tmux-like keybindings, leveraging hydra and helm for some commands: https://gist.github.com/kozikow/58b46c45a2c24406dc7cde3f1861... .
- vim-plug for a plugin manager (very good regardless of concurrency)
- neomake for building
- vim-go added async job support using neovim a while ago for most of its functionality, which I use for writing Go
My full inventory is here: https://github.com/shazow/dotfiles/blob/master/.vim/plugins....
The keybindings would then be the only thing that the IDE changes.
Now I would pay for that feature decent sum of money :D.
Do you have your dotfiles somewhere online? Or could you put up the code needed for that setup in a gist/pastebin?
* SPC-l gives you the layouts micro-state, which allows you to do all of this. First, set up your layout however you'd like, then open up the micro-state and run the save-as command (SPC-l-S) and that will allow you to save the layout to a layouts file somewhere deep in the bowels of Spacemacs.
* When you're ready to use your layout, use SPC-l-L to load the layout from a file. Type its name (Helm is used, so you get narrowing/fuzzy-find for free) and the layout will load. Note that if you already had another layout loaded, it will load it to the next workspace (accessible through SPC-l-<workspace-number>).
* As for the org Kanban board, check here: http://www.draketo.de/light/english/free-software/el-kanban-... To add this to spacemacs, just open your .spacemacs file (SPC-f-e-d) and add `kanban` to your `dotspacemacs-additional-packages` list.
rm -rf /Library/Caches/Homebrew/neovim--git
brew reinstall --HEAD neovim ==> make VERBOSE=1
Last 15 lines from /Users/jimwharton/Library/Logs/Homebrew/neovim/02.make:
"__Unwind_GetCFA", referenced from:
_lj_err_unwind_dwarf in libluajit.a(lj_err.o)
"__Unwind_RaiseException", referenced from:
_lj_err_throw in libluajit.a(lj_err.o)
"__Unwind_SetGR", referenced from:
_lj_err_unwind_dwarf in libluajit.a(lj_err.o)
"__Unwind_SetIP", referenced from:
_lj_err_unwind_dwarf in libluajit.a(lj_err.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [luajit] Error 1
make[3]: *** [src/luajit] Error 2
make[2]: *** [build/src/luajit-stamp/luajit-install] Error 2
make[1]: *** [CMakeFiles/luajit.dir/all] Error 2
make: *** [all] Error 2
unset LUA_CPATH LUA_PATH
brew reinstall --HEAD neovimThe analogous comparison would be between bash and posh/dash, or between gcc/clang and the Tiny C Compiler.
http://vimcasts.org/episodes/fugitive-vim---a-complement-to-...
I got pissed off for Bram reading it.
Also Bram had much more detailed and valid criticism about neovim's implementation above the response you linked. Did you intentionally link that one to make Bram look bad or did you simply not read the whole thread? I'm betting on the former.
Bram might be the more experienced programmer overall, but for implementing async in vim, I'll take Thiago's learned opinion over Bram's 'the horse has been dragged to water' solution anyday.
Brams criticism is valid about Thiago solution. Forcing msgpack is less than ideal. It's clear Thiago is learning as he goes along. Taking his work without reflection would be silly.
Also it is also clear neovim wants plugin writers. So they want vim to be compatible with what they made so they can grab users.
Why should vim care about being compatible with neovim?
Then the developer threw a hissy fit a few days later and created a fork because his patch wasn't accepted right away.
According to the Geoff Greer, they didn't fork Vim. The fork happened a couple of months after their patch wasn't accepted, and they joined: "A couple of months after my disillusionment with Vim, Thiago de Arruda submitted a similar patch. It was likewise rejected. But unlike me, Thiago didn’t give up. He started NeoVim and created a Bountysource for it." http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...
"surround" and "targets" are indispensable for me.
As for why vim should care? Because at this point I'd put money on neovim as the long term winner, and if I were Bram, I'd worry about vim joining vi on the sidelines as 'still developed, still in use, but not the vi everyone uses when they log into a linux box'. I'd look at my codebase and neovim's, at my toolchain and neovim's, at my community and neovim's, at my velocity and neovim's, and I'd imagine neovim eclipsing vim over time.
Maybe that's fine. But Bram is hardly some god-king who's position as foremost developer in the vi universe is a lifetime appointment--especially after he took that position from Bill Joy.
Once again Bram brings up a valid issue with neovims design about using msgpack for RPC. It just adds another layer of difficulty.
So explain to me why vim should include such an obviously flawed design?
And "makes debugging difficult" is an observation, not a criticism or valid reason to reject--it's certainly not detailed, as you said. Yes, it's more difficult debugging it directly, but the architectural separation makes the components more loosely coupled and more easily tested in isolation--it's a valid tradeoff, and one the neovim has demonstrated to work well in actual fact.
I mean, it's an accomplishment for Bram to add async to vim, but let's not forget who actually did it first, successfully, and along the way accomplished a lot more.
Why are you so hostile to neovim? By any measure they've done a tremendous job modernizing the codebase for vim and rejuvenating development of both neovim and vim.
Step back and ask yourself: if you were approaching both projects fresh, and asking which you might want to participate in, which would you choose and why, ignoring politeness on either side?
I'm guessing the delay you are referring to is the delay imposed by your terminal emulator (not vim) to detect the Escape key at the end that terminates visual block mode. If I'm right, you can quickly press "j" just after you press ESC, which should cancel the ESC-detection delay and cause your comment characters to appear instantly.
Edit: there's actually a few things that could be at play, including your terminal emulator, your screen/tmux (which is like another terminal editor, really), and vim's timeoutlen and ttimeoutlen settings.
set noesckeys #if 0
...code...
#endifhttps://github.com/Jaymon/vim-commentify
It's a no frills plugin that only does one thing, but it does it pretty well.
Optionally, convert the region into a separate function/method and just don't call it while checking.
Something challenges you, your reaction is to ignore/quit or step up and respond.
They're served decently enough by older versions and I doubt that any machine running those has the resources for features provided by newer Vim versions. Even if they do, the OS support for these features might not be good enough.
Omitted in this version are:
The 16-bit DOS, OS/2 and Amiga versions, these are obsolete.
The 32-bit console version for MS-DOS/Windows 95/98
The 16 bit MS-Windows version
Maybe you want to move on just for the sake of moving on? To a new generation? Can you explain why? Seems to me that the person who knows the code base 200%, who wrote/vetted the entire codebase, is better placed to add features, than newbie refactorers who didn't?
And all of that while maintaining such good backwards compatibility that almost all vim plugins work unmodified. Plugin authors only need to lift a finger to take advantage of new capabilities like async.
I didn't switch just for the sake of moving on. I switched because by any appreciable aspect, neovim and the developers behind it are simply better than vim.