I agree with your second point that it will send a lot of data down the line uselessly. I don't think it's a great idea but I couldn't think of any other way to do it.
However, I did just think of something.... What if there were a text based scrollbar in Screen that sat on the left (or right) inside the putty window made out of ascii characters. Putty will send the mouse clicks. It should be possible to nearly exactly mimic scrolling the Screen copy buffer remotely. It won't be as fast as local scrolling but it might work. On Sat, Mar 15, 2014 at 9:50 PM, Jim Mahood <j...@mahood.com> wrote: > On Sat, 15 Mar 2014, Michael Grant wrote: > > >> Yes I'm aware of this. But what would be cool is if the scrollbar could >> be somehow linked to the scrolling in copy mode. >> >> One thing I can imagine is just filling the of screen lines each time one >> changes screens. This would of course create extra flicker as lines >> scrolled by. >> >> I have a script that does this bound to a key. >> >> It would be nice if those lines could be filled offscreen somehow. As >> in first the visible area was redrawn then the copy area so the user might >> not >> notice. >> >> > I don't think that putty's scrollbar action is going to send anything > downstream to the session, but you could potentially detect/hook keystrokes > or mouse usage with the right libraries. If you already have a key bound > to enter copy mode, why does the putty scrollbar still matter to you? > > I can't see a lot of people wanting something like this -- it would mean > sending a potentially-large amount of data down the wire every time you > switch windows.
_______________________________________________ screen-users mailing list screen-users@gnu.org https://lists.gnu.org/mailman/listinfo/screen-users
