Not disagreeing but scrolling works just fine in vim/emacs/etc. Wouldn't it be just managing the scroll back buffer yourself rather than the terminals?

▲

jdiff 3 hours ago | parent | next [-]

Yes, but this does come with differences and tradeoffs. If the terminal isn't managing the scrollback, you don't get scrollbars and you lose any smooth/high resolution scrolling. You also lose fancy terminal features like searching the scrollback, all that needs to be implemented in your application. Depending on the environment it can also wind up being quite unpleasant to use with a trackpad, sometimes skipping around wildly for small movements.

▲

_verandaguy 3 hours ago | parent [-]

The other part (which IMO is more consequential) is that once the LLM application quits or otherwise drops out of the alternate screen, that conversation is lost forever.

With the usual terminal mode, that history can outlive the Claude application, and considering many people keep their terminals running for days or sometimes even weeks at a time, that means having the convo in your scrollback buffer for a while.

	▲	jaredsohn 2 hours ago \| parent [-]
		>that conversation is lost forever. You should be able to find it in ~/.claude You can also ask Claude to search your history to answer questions about it.

▲

bombela 3 hours ago | parent | prev [-]

I think they were saying that in "cup" screen mode (CUP: CUrsor Position, activated with smcup termcap), when you exit (rmcup) the text is lost, as well as the history since it was managed by the application, not the terminal.

Their hypothesis was that maybe there was aj intention to have claude code fill the terminal history. And using potentially harzardous cursor manipulation.

In other words, readline vs ncurse.

I don't see python and ipython readline struggling as bad tho...