4 ms·

FWIW I mentioned this in the thread (I am the guy in the big GH issue who actually used verbose mode and gave specific likes/dislikes), but I find it frustratin

by extr 8mo ago

FWIW I mentioned this in the thread (I am the guy in the big GH issue who actually used verbose mode and gave specific likes/dislikes), but I find it frustrating that ctrl+o still seems to truncate at strange boundaries. I am looking at an open CC session right now with verbose mode enabled - works pretty well and I'm glad you're fixing the subagent thing. But when I hit ctrl+o, I only see more detailed output for the last 4 messages, with the rest hidden behind ctrl+e. It's not an easy UI problem to solve in all cases since behavior in CC can be so flexible, compaction, forking, etc. But it would be great if it was simply consistent (ctrl+o shows last N where N is like, 50, or 100), with ctrl+e revealing the rest.

bcherny 8mo ago
Yes totally. ctrl+o used to show all messages, but this is one of the tricky things about building in a terminal: because many terminals are quite slow, it is hard to render a large amount of output at once without causing tearing/stutter. That said, we recently rewrote our renderer to make it much more efficient, so we can bump up the default a bit. Let me see what it feels like to show the last 10-20 messages -- fix incoming.
- extr 8mo ago
  thanks dude. you are living my worst nightmare which is that my ultra cool tech demo i made for cracked engineers on the bleeding edge with 128GB ram apple silicon using frontier AI gets adopted by everyone in the world and becomes load bearing so now it needs to run on chromebooks from 2005. and if it doesn't work on those laptops then my entire company gets branded as washed and not goated and my cozy twitter account is spammed with "why didn't you just write it in rust lel". o7
  - snovv_crash 8mo ago
    Your worst nightmare. For me this is the cool part.
- bethekidyouwant 8mo ago
  Why would you tailor your product for people that don’t know how to install a good terminal? Just tell them to install whatever terminal you recommend if they see tearing.
- bombela 8mo ago
  Just tell people to install a fast terminal if they somehow happen to have a slow one? Heck, simply handle the scrolling yourself a la tmux/screen and only update the output at most every 4ms? It's so trivial, can't you ask your fancy LLM to do it for you? Or you guys lost the plot at his point and forgot the most basics of writing non pessimized code.
  - SPICLK2 8mo ago
    I'm with you on this one. "Terminals are too slow to support lots of text so we had to change this feature in unpopular ways" is just not a plausible reason, as terminals have been able to dump ~1Mb per second for decades. The real problem is their ridiculous "React rendering in the terminal" UI.
  - troupo 8mo ago
    > It's so trivial, can't you ask your fancy LLM to do it for you? They did. And the result was a React render loop that takes 16ms to output a hundred characters to screen and tells them it will take a year to rewrite: https://x.com/trq212/status/2014051501786931427 https://x.com/trq212/status/2014051501786931427
    - yencabulator 8mo ago
      What's extra funny is that curses diffs a virtual "current screen" to "new screen" to produce the control codes that are used to update the display. Ancient VDOM technology, and plenty fast enough.
- SPICLK2 8mo ago
  Do you have any examples of slow terminals, and what kind of maximum characters per second they have?
- troupo 8mo ago
  > because many terminals are quite slow, it is hard to render a large amount of output at once without causing tearing/stutter. Only if you use React as your terminal renderer. You're not rendering 10k objects on screen in a few milliseconds. You're outputting at best a few thousand characters. Even the slowest terminal renderer is capable of doing that.
- wild_egg 8mo ago
  Terminals already solved how to do this decades ago: pagers. Write the full content to a file and have less display it. That's a single "render" you do once and write to a file. Your TUI code spawns `less <file>` and waits. Zero rendering loop overhead, zero tearing, zero stutter. `less` is a 40-year-old tool that exists precisely to solve this problem efficiently. If you need to stream new content in as the session progresses, write it to the file in the background and the user can use `less +F` (follow mode, like tail -f) to watch updates.

by extr 8mo ago

bcherny 8mo ago

Yes totally. ctrl+o used to show all messages, but this is one of the tricky things about building in a terminal: because many terminals are quite slow, it is hard to render a large amount of output at once without causing tearing/stutter. That said, we recently rewrote our renderer to make it much more efficient, so we can bump up the default a bit. Let me see what it feels like to show the last 10-20 messages -- fix incoming.

extr 8mo ago
thanks dude. you are living my worst nightmare which is that my ultra cool tech demo i made for cracked engineers on the bleeding edge with 128GB ram apple silicon using frontier AI gets adopted by everyone in the world and becomes load bearing so now it needs to run on chromebooks from 2005. and if it doesn't work on those laptops then my entire company gets branded as washed and not goated and my cozy twitter account is spammed with "why didn't you just write it in rust lel". o7
- snovv_crash 8mo ago
  Your worst nightmare. For me this is the cool part.
bethekidyouwant 8mo ago
Why would you tailor your product for people that don’t know how to install a good terminal? Just tell them to install whatever terminal you recommend if they see tearing.
bombela 8mo ago
Just tell people to install a fast terminal if they somehow happen to have a slow one? Heck, simply handle the scrolling yourself a la tmux/screen and only update the output at most every 4ms? It's so trivial, can't you ask your fancy LLM to do it for you? Or you guys lost the plot at his point and forgot the most basics of writing non pessimized code.
- SPICLK2 8mo ago
  I'm with you on this one. "Terminals are too slow to support lots of text so we had to change this feature in unpopular ways" is just not a plausible reason, as terminals have been able to dump ~1Mb per second for decades. The real problem is their ridiculous "React rendering in the terminal" UI.
- troupo 8mo ago
  > It's so trivial, can't you ask your fancy LLM to do it for you? They did. And the result was a React render loop that takes 16ms to output a hundred characters to screen and tells them it will take a year to rewrite: https://x.com/trq212/status/2014051501786931427 https://x.com/trq212/status/2014051501786931427
  - yencabulator 8mo ago
    What's extra funny is that curses diffs a virtual "current screen" to "new screen" to produce the control codes that are used to update the display. Ancient VDOM technology, and plenty fast enough.
SPICLK2 8mo ago
Do you have any examples of slow terminals, and what kind of maximum characters per second they have?
troupo 8mo ago
> because many terminals are quite slow, it is hard to render a large amount of output at once without causing tearing/stutter. Only if you use React as your terminal renderer. You're not rendering 10k objects on screen in a few milliseconds. You're outputting at best a few thousand characters. Even the slowest terminal renderer is capable of doing that.
wild_egg 8mo ago
Terminals already solved how to do this decades ago: pagers. Write the full content to a file and have less display it. That's a single "render" you do once and write to a file. Your TUI code spawns `less <file>` and waits. Zero rendering loop overhead, zero tearing, zero stutter. `less` is a 40-year-old tool that exists precisely to solve this problem efficiently. If you need to stream new content in as the session progresses, write it to the file in the background and the user can use `less +F` (follow mode, like tail -f) to watch updates.