Re: hardstatus and putty scrolling

[Nicholas Marriott]

tmux has the same limitations as screen here - no terminal provide a way
for applications to manipulate their scrollback beyond turning it off
and on and scrolling lines into it. So both tmux and screen have to
provide their own scrollback to work across multiple inner terminals.

tmux has good support for the mouse and searching in the scrollback but
this is only useful if you use it in the first place.

So your choices with tmux are the same as screen - either use putty's
own scrollback and live with the limitations (and tmux makes even less
effort to work around them than screen), or use the internal copy and
paste and live with it being different and the awkwardness of copying to
the system clipboard.

Personally, I do a bit of both - I use the internal scrollback to find
anything that has scrolled off the visible terminal but I tend to copy
and paste by using the mouse and the terminal's own copy for small bits
of text once they are visible.


On Thu, Aug 27, 2020 at 01:28:32PM +0100, Michael Grant wrote:
>    Yeah I suspected this wouldn't be possible.  I think about the only way
>    might be to have PuTTY (or KiTTY) add an option to remove that line from
>    it's scrollable region-a hack at best.
> 
>     
> 
>    Last night I did some reading up on tmux.  Tmux apparently has something
>    like what I was talking about.  Tmux lets you enable scrolling up tmux's
>    scrollback buffer with the mousewheel.  But this seems to break
>    copypaste.  I didn't play with it enough.
> 
>     
> 
>    I've only been using Screen for about 30 years.  I've never really played
>    much with tmux.  I don't relish the thought of moving 30 years of tweaks
>    and customizations to tmux to fix this little annoyance!
> 
>     
> 
>    I am very well aware of what the scrollback buffer is in PuTTY (and other
>    modern windowed ssh clients or ssh in xterm/terminal) and it's
>    limitations.
> 
>     
> 
>    I rarely use the scrollback buffer in Screen.  It's painful at best to go
>    into the edit mode to go and get stuff.  
> 
>     
> 
>    Most of the time in Screen, I flip back and forth between 2 or 3 shells
>    and an emacs screen.  This messes up the PuTTY scrollback buffer which is
>    to be expected.  But often, I scroll up to look at something or copy
>    something from above.  If that thing had scrolled off the screen before I
>    switched screens, it's probably there hiding just off screen.  It gets a
>    bit messy for sure, it's not pretty, but it's very useful.  Of course, if
>    start a new PuTTY, all the buffer is gone.
> 
>     
> 
>    So I created a hack which Attention Ctrl-L (where Attention is Ctrl-A by
>    default) repaints the PuTTY scrollback buffer from Screen's internal
>    scrollback buffer.  I have posted that hack before here a couple times. 
>    It doesn't retain any color in the text but gets the job done.
> 
>     
> 
>    In my ideal world, I wouldn't use PuTTY's scrollback buffer at all.  What
>    I'd like to see is Screen manage the scrollback buffer and let me use the
>    mouse to access it with a simulated scrollbar on the side of the window. 
>    Bob, you're spot on when you say don't capture the mouse!  What I imagine
>    being the correct way to do this is for Screen only to capture the mouse
>    over the areas which are managed by it, meaning the simulated scrollbar
>    and maybe the hard status line.  Things get a little tricky when you start
>    to talk about copypasting the text, who's copypaste buffer are you
>    managing?  Probably both.  The thing though that's important to me is that
>    PuTTY work the same with Screen as without.  Meaning, if I select text
>    with the mouse, a right-click somewhere pastes it back in.  Since Screen
>    and PuTTY are separate, it's not reasonable that Screen know anything
>    about PuTTY's mouse behavoir and should just pass that through just as it
>    does today.  Screen should work regardless of what terminal program you
>    are using.  Screen should NOT need any special PuTTY mode and nor should
>    it be needed to implement what I'm talking about.
> 
>     
> 
>    Things like scrolling with the mousewheel, I know that when I'm in Emacs
>    inside of Screen, Emacs sends some escape sequence to turn off the putty
>    scroll bar and the captures the scrollwheel.  That's great, just what I
>    expect.  Similarly with my idea above, getting into Emacs in a shell
>    window, Emacs would send that sequence and the scroll wheel, instead of
>    scrolling up Screen's internal buffer, would scroll the Emacs buffer. 
> 
>     
> 
>    And bringing this back to the hard status line, then, Screen would manage
>    fully the screen and that hard status line could stay at the bottom or top
>    or wherever, regardless of how the window was scrolled!
> 
>     
> 
>    And furthermore, restarting screen or opening screen on another computer,
>    all the scrollback buffer is there and copypaste probably would work
>    across computers (within Screen).  Sounds like a win-win-win if you ask
>    me!
> 
>     
> 
>    Can this work?  Comments?
> 
>     
> 
>    Michael Grant
> 
>     
> 
>     
> 
>     
> 
>     
> 
>     
> 
>