rockorager

If you work with LLM agents, you will immediately be able to tell this issue is written by one. The time cost of this sort is almost certainly not real, as others have pointed out.

I’ve had agents find similar “performance bottlenecks” that are indeed BS.

I think exposing a C lib would be very nice. Feel free to open a discussion or issue on the Github.

Oh no - where at?

Oh that's cool. `find` is another tool I thought could benefit from io_uring like `ls`. I think it's definitely worth enabling io_uring for single threaded applications for the batching benefit. The kernel will still spin up a thread pool to get the work done concurrently, but you don't have to manage that in your codebase.

You would have to write your IO to have a fallback. The Ghostty project uses `io_uring`, but on kernels where it isn't available it falls back to an `epoll` model. That's all handled at the library level by libxev.

I didn't include `busybox` in my initial table, so it isn't on the blog post but the repo has the data...but I am 99% sure busybox does not have locale support, so I think GNU ls without locale support would probably be closer to busybox.

Locales also bring in a lot more complicated sorting - so that could be a factor also.

Yeah, I wrote this as a fun little experiment to learn more io_uring usage. The practical savings of using this are tiny, maybe 5 seconds over your entire life. That wasn't the point haha

Author of the project here! I have a little write up on this here: https://rockorager.dev/log/lsr-ls-but-with-io-uring

I've discussed with Mitchell a bit in the past on this, but there are a few ways to opt in to this. First, let's imagine there is some escape sequence that tells the terminal to ignore some set of escape sequences.

1. The shell could have a keybind (say, ctrl+enter) which runs the command with (for example) only styling enabled (CSI m sequences).

2. You could write a wrapper around any program to do the same. The shell doesn't need to know anything about the system, but instead you have a wrapper that disables and then reenables said sequences.

3. A program itself can opt in by turning on the feature at launch. This allows CLI / TUI developers to "safeguard" their programs from malicious attacks.

I understand the fear of living near such a heinous crime, but you have to see the difference between the two situations. Random crime is scary, but is random. All signs point to this being an assassination. Brian Thompson wasn't the victim of a random criminal, nor was he murdered by some person he has a connection with. He was assassinated. So the right question is why do we investigate assassinations differently than murders? And to me, the answer is clear - an assassination has far larger societal implications than a murder.

It could definitely work for that. You have to think of zig in this context as a build system which can download and compile C/C++ codebases.

Exactly - these should be reported along with any other input event as an escape sequence. There are other comments on this post that link to how this is done.

The single downside being you can get signals for SIGWINCH, while the (legacy) xterm escape sequence requires polling.

I wrote a proposal[0] to have terminals send these updates in-band, instead of requiring polling a-la xterm. So far, foot, ghostty, iterm2, and kitty have implemented this feature on the terminal side. Neovim, notably, also supports this on the client side.

[0] https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3...

I've been daily driving Ghostty for over a year now, and have been a somewhat regular contributor. As a TUI library author, I've worked with several terminal authors on bug fixes and implementing features - Mitchell is among the nicest to work with. Happy to see this project launch as 1.0!

Ghostty has both mode 2027 and kitty image protocol

The state of the art here is to detect mode 2027, and enable it when supported. This lets you know the terminal will handle graphemes properly.

I maintain two TUI libraries which use this technique and emoji support has been (nearly) great. (One of which uses your uniseg library!)

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

This isn't using any "fancy" terminal features, aside from the synchronized update sequences (which terminals that don't support typically will ignore, though windows has a special case where it must be ignored). That said, you can query the terminal for support for this sequence if you wanted to.

Other than that, it's using standard ANSI sequences: `\r` to return the cursor to the beginning of the line, `\x1bM` (Reverse Index) to move the cursor up a single line (repeated n times), and then `\x1b[J` to clear the screen below the cursor position. All of these are sequences defined at least since the VT220, probably the VT100.

I guess my point is that even for key input, you don't need terminfo. Modern terminals, and I would agree with your definition of that, all use the same keyboard encodings. There is the notable case of backspace/delete you mentioned but as I said - you can treat both as a backspace press.

All of that said, I am a huge proponent of the kitty keyboard protocol. I would love to live in a world where the "default" encoding of keys is done with the that protocol (with the disambiguate flag on)

Do you still need terminfo? It depends. If you just want to style some text and maybe do some basic cursor operations: probably not. If you want to use more advanced operations or read key input: probably yes.

I disagree. The vast majority of terminals will send the same sequences. There is almost never a case where handling the two options for backspace the same way will result in a bad user experience. What complicates this even more is that many terminals allow the user to modify which sequence the `Backspace` key sends (0x08 vs 0x7F). Any application relying on terminfo, where a user did not modify their terminfo entry, will interpret these wrong if a user has manually changed it.

Terminfo is not needed anymore. It served a purpose to let applications know how to talk to a terminal. That era is gone.

Neovim already supports these keys as long as you are using a terminal that supports the Kitty keyboard protocol (Kitty, wezterm, alacritty, foot, ghostty)

Kitty keyboard protocol does indeed support modifier sides.

I don't see why not. 1.0 would mean the API isn't changing. And they can certainly swap out the language and still keep the API the same.

https://git.sr.ht/~rockorager/vaxis

A(nother) golang TUI library. Targeting modern terminal features, and a few different APIs for building applications. I really like notcurses, but the CGO cost when setting individual cells is very high...so this was my attempt to "port" what notcurses does to go. I handle things a little differently than notcurses, but in general am taking a lot of the same approaches for finding out terminal capabilities. Just not nearly as many optimizations when it comes to the render side (but Vaxis can render at about 5000 FPS in typical cases, so I haven't tried to optimize anything more there than it already is).

The main design decision I am going back and forth on how much I have used globals. Initially the design was a big struct, but I liked being able to use globals so when I write widgets as part of the library, they can send messages into the event queue without needing access to an application struct or something. I can't think of a single use case where a user would need more than one instance, so globals have seemed fine (and even notcurses says you can have only one notcurses instance per process...so I'm not even straying from that).

Thanks for any feedback!

There aren’t any that go direct to maildir. There is mujmap that syncs to notmuch. I wasn’t able to get it to work the way I wanted, and wrote my own that I’d be happy to share. I’ve been using it for around a month with no issues but that’s certainly not much confidence yet!

The advantage of going straight to notmuch is that the data model is so similar to JMAP that synchronizing is just that much easier. Both ends can give you a state and all emails which have changed from that state. Then it’s just a matter of updating the tags on those to each end or uploading/downloading the email if it’s new.

I get something like 1.7kB round trip data usage when there are no updates (really it’s 0kB save for the keepalive when used in daemon mode) and ~100ms for that round trip. This is in comparison to several megabytes for a single mbsync poll (even when there are 0 changes) and ~5 seconds

I'm a chemical engineer myself, and often wondered if there were any others interested in programming as much as I am. I'd be interested to see what sorts of marriages you have made between the two fields. Do you have any links you could post or send me?

There are very few "sit down and read" type books about chemical engineering. That being said, there are two books that I reference every day: the first physically, the second philosophically.

1) Perry's Handbook for Chemical Engineers (Perry)

2) Conceptual Design of Chemical Processes (Douglas)

Perry's is the end all be all for technical reference.

Conceptual Design is incredibly useful for learning how to quickly and accurately design an entire process. If anything, it'll teach you the best methods to go about "back of the hand" calculations for sanity checks.