screen-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hardstatus and putty scrolling


From: Bob Proulx
Subject: Re: hardstatus and putty scrolling
Date: Wed, 26 Aug 2020 19:05:57 -0600

Michael Grant wrote:
> I’m referring to scrolling the window by moving the elevator in
> PuTTY up/down to inspect the previous output in the shell history.

As far as I know this is not possible because the terminal (putty in
this case) scrollback buffer is unknown to the curses terminal
applications running with it.  The application running in the terminal
has no interface to know that the user has scrolled back to look at
something that was in the terminal memory.  And in fact in my
experience when things scroll off in screen those lines are only
stored in screen's scrollback memory and not in the terminal
scrollback memory.  Therefore when using screen it usually makes no
sense to scrollback in terminal memory.  That's my experience anyway.

Screen itself maintains a scrollback of text and using the "copy"
command can scroll back through it.  But using the terminals
scrollback memory is completely outside of it.  It's an independent
thing.  And screen does not know about it at all.

A good mental model is if your terminal size is rows and columns for
an active part of the display.  Wth the terminal also maintaining a
history scrollback above this.  Using the terminal scrollbar zings the
display through this history.  Since the hardstatus line is at the
bottom it is in the active display area of rows and columns.

I don't know about putty but most terminals have a mode where they
will automatically scroll to the bottom upon any output to the
screen.  That's the normal way I use XTerm.  Which means that I can
scroll back through the terminal history but as soon as any output is
produced the terminal refreshes itself at the bottom.  This is good
because that's where the program output is going to go.

> I know what you mean by going into a sort of edit mode in screen and
> using the cursor keys to inspect Screen’s internal buffer, that’s
> not what I mean.  But hmmm, it would be kind of cool if there was a
> way to use the mouse to control scrolling around in Screen’s
> scrollback buffer instead of PuTTY’s scrollback buffer.  Emacs does
> something like this come to think of this... but I’m way off subject
> here.

I'll just put a plea in here that if someone codes up such a thing
that they do not make it the default.  I hate it when applications
steal the mouse.  It usually breaks cut-n-paste.  Then I must work
through how to disable it.

> What I am trying to do is glue that hard status line to the bottom
> of the PuTTY window so that when I scroll up in PuTTY using the
> mouse wheel or move the window’s scroll elevator up, that the hard
> status line always stays at the bottom of the visible window.  Hope
> that’s more clear.  If not, I will post an image.

I am sure I understand what you want.  But I don't think it is
pracical.  Because usually what has scrolled off is not in terminal
memory when running screen.

Since screen is usually used by people using multiple screen windows
active simultaneously.  When screen is running there really isn't a
single terminal scrollback buffer anymore.  Everything would all get
jumbled together.  Which still might be possible for a user to realize
this and make use of it but I think would generally be confusing for
many.

> I have a feeling there’s no way to do this in PuTTY and that it
> would mean modifying PuTTY.

Probably.

> Those old terminals like the VT100, they didn’t have mice and scroll
> bars or even scrollback buffers.  It’s my opinion that the hard
> status line shouldn’t scroll with the rest of the window when you
> scroll it into these scrollback buffers.

And my opinion would be that the terminal scrollback shouldn't be used
when using screen.  (Note I am just another screen user here.)

> So maybe the only way to solve this in Screen is to implement
> something so that one could ignore PuTTY’s (and any other SSH
> client’s) scrollback buffer and capture the mouse clicks and
> movements to move around in Screen’s scrollback buffer instead.
> This way Screen controls the display and that status line can be
> kept at the bottom no matter where the window above it is scrolled
> to.   Anyone thought about this?  Does this already exist?

Don't break cut-n-paste! :-)

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]