Fantastic work by the Neovim folks as usual. However, this sentence stuck out to me
> The API should only grow, not break
This seems to ensure eventual bloat.
Newsletter #7 - Summer of Road
21–30 of 36 posts
Re: Newsletter #7 - Summer of Road
#22Earlier quoted context omitted.
I'm not sure how it could be 'for worse'? Even Neovim benefits from the uptick in Vim patches, because they actually merge many of them into Neovim. So it seems like it can only be a good thing. Better editors for everyone.
That's one way it could play out, but that's not the way it did play out. Vim ate Neovim's lunch because they took so long to create a release that Vim was able to copy their best features. Worse yet, they did this in a way that is not compatible with Neovim. There is a chasm between Vim and Neovim that is growing, and the incentive to cross it is shrinking. As someone who has watched closely Neovim's development sin…
Vim didn't eat Neovim's lunch. It made its own lunch. Vim8's async feature is a copy only in name. Comparing both async APIs, I'm almost certain that Vim8's was added spitefully. It's just so obtuse compared to Neovim's.
Re: Newsletter #7 - Summer of Road
#23Earlier quoted context omitted.
I'm not sure how it could be 'for worse'? Even Neovim benefits from the uptick in Vim patches, because they actually merge many of them into Neovim. So it seems like it can only be a good thing. Better editors for everyone.
That's one way it could play out, but that's not the way it did play out. Vim ate Neovim's lunch because they took so long to create a release that Vim was able to copy their best features. Worse yet, they did this in a way that is not compatible with Neovim. There is a chasm between Vim and Neovim that is growing, and the incentive to cross it is shrinking. As someone who has watched closely Neovim's development sin…
Hm, ok, that's interesting. I guess I stopped following Vim's progress once I switched to Neovim. It still seems to me that Neovim has the right overall approach (through cleanup, shedding ancient compatibility layers), but if that doesn't yield an increase in velocity in the short term then I guess it wouldn't be a big advantage.
Re: Newsletter #7 - Summer of Road
#24Earlier quoted context omitted.
:term to run a terminal in a vim window. Also, much more sensible defaults.
Cool, but why?
Speaking practically, if you're using a terminal to use Neovim, you get consistent window management. If you're using one of Neovim's GUI clients, you also get a terminal in the GUI's frame.
Re: Newsletter #7 - Summer of Road
#25Earlier quoted context omitted.
Cool, but why?
I like being able to have a vim window that has a terminal in it, there are some cases where I just prefer to have it in my terminal environment rather than switching to another real window. Mostly this is for things where I want to be in the same directory as my editor to run greps through my source, etc... It's also nice sometimes to do something and then be able to search through the history with "/". At times I'v…
> I was, however, fairly surprised that I could no longer ":sh" out to run something
Honestly, :sh always felt weird in vim.
Either you are in a terminal, and Ctrl-Z is a much better experience, since you maintain your existing session.
Or you are in the GUI, and the terminal emulation is poor and slow.
Re: Newsletter #7 - Summer of Road
#26Earlier quoted context omitted.
That's one way it could play out, but that's not the way it did play out. Vim ate Neovim's lunch because they took so long to create a release that Vim was able to copy their best features. Worse yet, they did this in a way that is not compatible with Neovim. There is a chasm between Vim and Neovim that is growing, and the incentive to cross it is shrinking. As someone who has watched closely Neovim's development sin…
Vim didn't eat Neovim's lunch. It made its own lunch. Vim8's async feature is a copy only in name. Comparing both async APIs, I'm almost certain that Vim8's was added spitefully. It's just so obtuse compared to Neovim's.
Well, that one is the one people are using. Now that the question among plugin developers is "Vim or Neovim?" which one do you think they will choose? It's totally possible that Neovim will need to adopt Vim's inferior API for compatibility reasons, like they're doing with the VimLLua compatibility layer.
Re: Newsletter #7 - Summer of Road
#27Earlier quoted context omitted.
I read that article and didn't get a good handle on any features that would motivate a transition from Vim. Any links you could provide?
For me, I like: - Neomake ( https://github.com/neomake/neomake ) which I use for async linting. I know this is now working in Vim 8, but I've been using Neovim for a while and this was exclusive for a while. - Vim-test ( https://github.com/janko-m/vim-test ) uses `:term` for running your tests from within vim -- this is most useful because I have a shortcut to test from current editing file, etc. I know this is also…
Thanks for the link to Neomake - Neovim is still a first class citizen for it, and it was a pain to get it working on Vim (and several bugs for Vim have been filed, debugged and fixed in this process).
Re: Newsletter #7 - Summer of Road
#28Earlier quoted context omitted.
I read that article and didn't get a good handle on any features that would motivate a transition from Vim. Any links you could provide?
For me, I like: - Neomake ( https://github.com/neomake/neomake ) which I use for async linting. I know this is now working in Vim 8, but I've been using Neovim for a while and this was exclusive for a while. - Vim-test ( https://github.com/janko-m/vim-test ) uses `:term` for running your tests from within vim -- this is most useful because I have a shortcut to test from current editing file, etc. I know this is also…
Regarding distros: Arch has it.. ;)
Re: Newsletter #7 - Summer of Road
#29Re: Newsletter #7 - Summer of Road
#30Is neovim packaged for distros?
Arch has it: https://www.archlinux.org/packages/?name=neovim
The -git version in AUR: https://aur.archlinux.org/packages/neovim-git/.