Chris Oakman ported the parinfer algorithm to Lua [1]. I used this to write a parinfer plugin for Neovim [2]. I use Fennel (a Lisp that compiles to Lua) for all of my Neovim config and so use parinfer everyday. It works exceptionally well (there are occasional hiccups, but no showstoppers).
Neither my plugin nor Chris' script have been updated in 2+ years. That's because it just keeps working. I owe a lot to Shaun and Chris for their work (my plugin is just a little glue code for interacting with the editor, they did all of the hard work).
Apple Terminal has a lot of problems. As others have mentioned, it lacks support for 24 bit color, enforces minimum contrast ratios without any ability to disable them (meaning you cannot set arbitrary color themes), is hopelessly bad at Unicode rendering (particularly with multi-codepoint graphemes, see [1]), and in general misbehaves in other myriad ways [2][3][4].
With both Ghostty and iTerm2 now freely available, there's really no reason to use Terminal.app.
Terminals do have a concept of a cursor (there are dedicated control sequences for cursor management). There's no fundamental reason a terminal emulator couldn't implement an animated cursor like this, my guess as to why no one has done it is simply that it's not a very commonly requested feature.
>Zig gives buffer overflow safety and null pointer safety but not use after free, double free
It can provide the latter two through the use of the `GeneralPurposeAllocator`, which tracks UAF and double free.
Stack pointer escape safety is being actively researched (there are a few tracking issues, see [1]). I'm personally interested in this, I've written a decent-ish amount of Zig for toy/personal projects, and anecdotally stack pointer escape is the only type of memory error that has bitten me more than once (though to be fair, one of these cases was calling into a C API, so even Rust wouldn't have helped).
More broadly, the ability to catch all forms of UB in Debug/safety builds is an accepted proposal [2], though whether or not it will be possible in practice is a different (and interesting!) question.
As a long time Vim user I’m extremely thankful for Bram’s creation and stewardship of an incredible piece of software. He gave the world an amazing gift.
I’ve interacted with Bram a few times personally in the process of submitting changes to Vim, and I’ve observed many more interactions with others. I always had an immense amount of respect for the way he led the Vim project and interacted with the community. It is not uncommon to see open source software maintainers become burnt out or frustrated, particularly with a piece of software as quirky and complicated as Vim. But Bram was almost always respectful and patient with users and contributors, even when they were not.
This is a loss for the software world. Bram, you will be missed.
In contrast, for me this seems like the "killer feature" that differentiates it from the current generation of headsets. I've always been completely uninterested in anything AR/VR and a big reason for that is that these headsets make you feel so "cut off". The ability to see someone's eyes while they are wearing the headset reduces that feeling of isolation.
I agree that it will always be weird to just keep the headset on during an entire conversation or to just walk around with them all the time. But if someone is doing work or watching a movie or something with these on, and just needs to turn their head to talk to you for a minute, it's a nice feature to have.
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.
>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.
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.
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.
Neither my plugin nor Chris' script have been updated in 2+ years. That's because it just keeps working. I owe a lot to Shaun and Chris for their work (my plugin is just a little glue code for interacting with the editor, they did all of the hard work).
[1]: https://github.com/oakmac/parinfer-lua
[2]: https://github.com/gpanders/nvim-parinfer/