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
