About Scrollback Wrapping and Copying in the Pager

[zzhaolei]

I wanted to ask about the intended behavior of scrollback when it is opened in the pager.

From a user perspective, the main issue I am seeing is with copying text in less:

• A long line that is logically a single line can end up being copied as multiple lines from the scrollback pager.
• This is especially noticeable for simple output such as a long echo line that only wrapped visually in the terminal because of the window width.
• If I pipe the same output directly to less, copying behaves as expected, so the difference seems to come from how scrollback is prepared before it is passed to the pager.

Because of that, I am wondering whether it would make sense to let the pager handle long-line display more directly, instead of preserving terminal wrap positions in the scrollback data.

I realize changing the default behavior here could be somewhat breaking, especially if existing workflows depend on the current screen-layout-preserving behavior. So I am not necessarily suggesting that the default should be changed immediately.

What I mainly want to understand is:

• Is the current behavior intentional because scrollback is meant to preserve the visual terminal layout as closely as possible?
• Or would it be reasonable to support an alternative mode where logically continuous lines stay continuous when opened in the pager, so copying from less is closer to copying the original command output?

If this is something you would consider, my preference would probably be a configurable or opt-in approach rather than a global default change.

My motivation is mainly copy behavior: when I copy from the pager, I would prefer text that was originally one line to stay one line, even if it had wrapped visually on screen.

[kovidgoyal]

scrollback includes \r for softbreaks and \n for hard breaks. How these are interpreted as far as copying behavior is pager dependent. If and when I get around to finishing the kitty native pager, it will work automatically.