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
