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.
> This also means that native features like pressing Shift+⌘+\ open the tab overview, just as in other applications.
Ah, so this is a macos thing and not just Safari. Can anyone help me select a tab using a keyboard? I use the shortcut, type in the search box and...have to use the mouse :(
I don’t recall where, and don’t have my laptop handy, but there is a macOS system option to enable tabbing through all controls (not just inputs), that _should_ do it
Let's hope it will become available for Linux, too. I have been using Yakuake for over a decade now, mostly because I love how I can access the terminal everywhere with one button press.
At the same time, Yakuake seems to be in maintenance mode, and you should be happy when it works with new KDE versions.
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.
Another problem is that the cursor moves while the screen is buffer is being rendered. The location is only really known once the cursor settles in the same place for some time, which is unacceptable in terms of latency.
>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.
The way `GeneralPurposeAllocator` works is kinda scary though, since it may result in whole memory pages used only for very small allocations, effectively multiplying the memory usage of the program. Also kinda goes against the memory exhaustion safety, since now you're more likely to exhaust memory.
Yeah, I don't think it's right to say Zig doesn't have use-after-free and double-free safety. If you want that, you can just use a general purpose allocator. Note that you can't forget to choose an allocator since they are explicit.
Is this somehow harder than, say, choosing not to use "unsafe" in Rust?
Maybe all that is missing is a linter to help enforce whatever memory-management policy you've decided on. That's not really needed for small, coherent teams, but would be important for using Zig in larger projects with multiple teams and/or disparate individual contributors. (Perhaps such a thing exists and I just don't know about it.)
You might also be able to use an arena allocator where free is a no-op. That has different tradeoffs, but is also safe for use-after-free and double-free.
As you say, stack escape is the main thing where Zig doesn't have a good memory-safety story yet (at least not that I've heard). I guess there are a few others that concern me when I see them on a list, though I haven't hit them in real life.
Static analysis at the IR level would be awesome. It could catch use-undefined, stack escape, and probably uaf/df as well so you don't have to lean on gpa's (potentially expensive) tricks. Plus there are times when you maybe don't want to use page allocator.
As an aside. I'm not certain I understand how double free is memory unsafe (in the sense of "causing vulnerabilities")
A double free breaks invariants for the memory allocator. For example, the freed memory may have been handed out to someone else and if you free it again, it will be marked as unused even though that code relies on their stuff being available. One very classic way of exploiting a double-free is a sequence like this happens:
1. Some code allocates memory.
2. The code frees the memory, but keeps a stale reference to it around. It is marked as unused by the allocator.
3. Some other code allocates memory. Maybe it's reading the password file off of disk. The allocator has some unused memory lying around so it hands it out–but it turns out that this is actually just a reuse of the buffer from earlier. It is now marked as "in use" again by the allocator.
4. The code from earlier has a bug and frees the allocation again. This means that the allocation is now marked as "unused".
5. Another allocation request hands out this memory again. Maybe it's a buffer for user input? Well, it's been scribbled all over with other data now.
6. Someone asks to authenticate and the password checking code gets called. It has the password right here to check against…oh, wait, that memory got freed out from under it and overwritten with some attacker-controlled content!
> I'm not certain I understand how double free is memory unsafe (in the sense of "causing vulnerabilities")
Perhaps there are some allocators where doing that hits UB. UB in memory allocation is probably always a memory safety issue. I would say if your code accepts any allocators where double-free could be UB then you've got a safety issue.
What do you think the difference is between “patching out free” and allocators as a first-class feature? I’ll bet you can think of a few rather significant ones if you try.
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.
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/