gpanders

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/

There is a ghostty-git AUR repo for tracking the main branch: https://aur.archlinux.org/packages/ghostty-git

With both Ghostty and iTerm2 now freely available, there's really no reason to use Terminal.app.

[1]: https://mitchellh.com/writing/grapheme-clusters-in-terminals

[2]: https://github.com/neovim/neovim/issues/26093

[3]: https://github.com/neovim/neovim/issues/28776

[4]: https://github.com/neovim/neovim/pull/28453

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.

[1]: https://github.com/ziglang/zig/issues/2646

[2]: https://github.com/ziglang/zig/issues/2301

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.

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.

    zig build-obj file.zig

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.

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 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.

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.

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.

    rm -rf ~/.local/{bin,share}/nvim

In addition, another point I don't often see mentioned is the alarmingly likely possibility that all AI-enhanced software engineering will go through these tools that are owned by 1 or 2 (American) tech companies. Are people really excited about a future where you can't even perform the basics of your skillset without depending on a Microsoft service? We are rapidly advancing toward a future where a single company owns the most popular text editor, the most popular code hosting platform, (one of) the most used cloud infrastructure platforms, and soon, if the AI enthusiasts have it right, the tool that will be a "necessity" to even write code at all.

If that future unfolds, I will leave software voluntarily long before I get "replaced".

I haven’t read any of them myself or I’d recommend them directly, but your question brought this to mind.

You may not have to switch at all if you are already using one of these terminal emulators.

Kovid deserves credit for addressing some of the issues in the original proposal, and for documenting it well. But Evans deserves credit as well for formulating the original idea.

Note also that this is not the only solution to this problem. Xterm has had its own solution for a long time called modifyOtherKeys [2] which has been supported by Vim and iTerm2 for quite some time (I believe foot supports it as well, perhaps others). Of course people have different opinions on which approach is “better”, though empirically it seems like the CSIu/“fixterms”/kitty approach has a lot more momentum at present.

[1]: http://www.leonerd.org.uk/hacks/fixterms/

[2]: https://invisible-island.net/xterm/modified-keys.html