I mean to be fair, in that video he was recording a video using the headset. In that context, I don't think it's _that_ different from a parent pressing their eye into a camcorder or holding up a smart phone.
It does have similar vibes, but personally I wouldn't have the same negative reaction if the same functionality was added to the iphone. There's just something inauthentic with the digitally projected eyes.
>I've really tried to move from vim to neovim for a long time and spent many hours trying to configure it to behave like vim
Could you elaborate on this? Out of the box, Neovim and Vim are extremely similar, almost identical to a first approximation (Neovim has different defaults for some options than Vim, but that's about it). The two start to diverge dramatically when you begin writing or using plugins as the extensibility/API model is quite different between the two, but I am very surprised to hear you had difficulty trying to make Neovim behave like Vim.
>E.g. when you are in a vim terminal and you go to normal mode to yank some stuff to put it in the other pane with the code, nvim defaults adds line numbers to the terminal that need to be cleaned up afterwards
Maybe I'm misunderstanding, but the Nvim terminal does not do this, at least by default (maybe some plugin enables this "feature"). If you yank some text from a terminal buffer in Nvim and paste it into another buffer with p, no line numbers are added.
>I believe it was a mistake to fracture the ecosystem with plugins that can only be used with neovim.
I hate to break this to you, but Vim itself is in the process of converting its runtime files into Vim9script (which is Vim specific), and many new Vim plugins are also being written in Vim9script.
Neovim has always supported "traditional" Vimscript, and has ported all runtime file changes from Vim (think filetype plugins, syntax highlighting, etc.). In fact, we explicitly request that any runtime file changes first go through Vim precisely because we want to keep the two projects aligned. But the more that Vim transitions to Vim9script, the less can be shared between the two projects. So unfortunately the "fracturing of the ecosystem" is not specific to Neovim.
I don't think the onus is on the original project to maintain compatibility with a fork. Neovim made it pretty clear from the beginning that they were going to fracture the ecosystem and now we have colorschemes in Lua that can't be used in vim... say what you will about Emacs, but at least all of their distros can run the same code.
From my perspective as a vim user, neovim has only made my life worse by splitting plugin authors into two camps without any real benefit over what we had in vim. The only good thing about neovim is it caused some nice features to be added to vim, which the neovim authors could have just contributed themselves without trying to fight for control of the ecosystem with Bram. Neovim has really just made things worse for everyone.
Probably me but I definitely sense biases in your replies.
Vim ecosystem is 'controlled' by the community not Bram. If Neovim/Lua is not good enough there wouldn't be a fracture in the first place.
The fact that Bram saw the success of Lua with Neovim but insisted on inventing Vim9Script speaks for itself. Yet you somehow manage to blame everything on Neovim.
One feature I'm personally excited about is the "undeprecation" of the 'exrc' option, which allows project-specific configuration.
Vim (and thus Neovim) has had the 'exrc' option for a long time, which loads any .exrc or .vimrc (or in Neovim's case, .nvimrc) files in the current directory. However, it does this unconditionally, which is obviously a bit of a security concern as a random .vimrc file could contain arbitrary code. For this reason, Vim recommends not using this option and Neovim even went so far as to mark it deprecated.
In this release, Neovim adds the concept of a "trust database", which is used for the 'exrc' option. When 'exrc' is enabled and a .nvimrc or .nvim.lua file is found in the current directory, Neovim will ask the user if the file is trusted (with the ability to first view the file). The file is only executed if the user explicitly marks it as trusted. Because this solves at least the most egregious security issues with the 'exrc' option, it is now marked undeprecated in Neovim.
I have been using .nvim.lua files for project specific configuration to great effect at work. Hopefully others find this feature useful as well.
> In this release, Neovim adds the concept of a "trust database", which is used for the 'exrc' option.
This is basically how direnv and shadowenv work. So if anyone has used those, this is the same idea but it lets you layer on project-specific nvim config without shipping a whole, preconfigured nvim with your projects. Pretty cool!
Neovim uses LuaJIT on most distributions (or when building from source), which is substantially faster than Vimscript. Although this only really matters in computation-heavy plugins.
The only other "advantage" is that the Neovim development team is 100% all in on Lua, and Vimscript is essentially in "maintenance mode". We still port patches from Vim, but even Vim has moved on to Vim9script, which Neovim has no plans to support, so traditional Vimscript is very likely not going to see any improvements from either Vim or Neovim.
You can use Neovim without a framework. In fact, for the most part Neovim will work as-is with a .vimrc written for Vim (there are some options that are specific to Vim or Neovim, but not many, as both projects port features from the other).
