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.
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
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.
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.
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!
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)
I’ve had agents find similar “performance bottlenecks” that are indeed BS.