gpanders

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

[1] https://github.com/oakmac/parinfer-lua

[2] https://github.com/gpanders/nvim-parinfer/

Note the AUR package was removed because it's since been packaged in the official Arch repos.

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

It's a macOS-only feature, for now.

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.

[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

This gets brought up a lot, so I wrote about it here https://gpanders.com/blog/ghostty-is-native-so-what/

It's a macOS-only feature, for now.

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.

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

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

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.

“Atlasean task” sounds like a Jira ticket.

You can invoke Zig without build.zig:

    zig build-obj file.zig

Indeed. The combination of direnv and exrc is very potent.

Probably true, but the Pi4 is not up to the task of transcoding 4k video.

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.

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

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

I have been installing into $HOME/.local for a while now and it works wonderfully. I build from source, but it should work just as well from a tar or AppImage.

I completely agree. Many of the recent articles and blog posts written by AI enthusiasts giving examples of how AI makes their job "easier" or "more productive" just demonstrates this to me even further. What they call "more productive" looks to me like "incredibly boring".

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

There are a few mentioned in this discussion: https://m.youtube.com/watch?v=-m6GFs3GuU0&feature=youtu.be

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

It is also supported by iTerm2, Wezterm, and foot. Alacritty does not (yet) support dynamically modifying the key encoding per-application, but you can hardcode the encodings in your config file (there is an issue in the Alacritty repo that explains how to do this).

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

It is briefly mentioned in this post, but this work is based on a proposal by Paul Evans [1] (creator of libtickit and libvterm, among others).

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

It has been implemented to a degree that it is useful for most users. For instance, you can now map Control-I and Tab separately, as well as keys like Control-1, Control-2, Control-;, etc.

It's not mentioned in the headline, but GM also intends to phase out Android Auto, so this is not specific to iPhones.

General Motors plans to phase out widely-used Apple CarPlay and Android Auto technologies that allow drivers to bypass a vehicle's infotainment systems, shifting instead to built-in infotainment systems developed with Google for future electric vehicles.

No it is not for many applications. The entire embedded software engineering field is an example.