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

Comments URL: https://news.ycombinator.com/item?id=40378218

Points: 291

# Comments: 131

Comments URL: https://news.ycombinator.com/item?id=39683104

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=39204366

Points: 6

# Comments: 0

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.