[Top][All Lists]

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

Re: screen + xterm scrollback

From: Quasar Jarosz
Subject: Re: screen + xterm scrollback
Date: Wed, 21 Jul 2004 08:26:49 -0500 (CDT)

On Wed, 21 Jul 2004, Phil!Gregory wrote:

> * Zenaan Harkness <address@hidden> [2004-07-21 11:41 +1000]:
> > When I comment out the above line again, it seems that screen is still
> > disabling the alternate buffer. And a quick read of the man page shows
> > that the default setting for "altscreen" is off, so that makes sense.
> altscreen controls whether screen tells programs inside it that i has an
> alternate screen.  The terminfo setting sontrols whether screen thinks
> your terminal emulator has an alternate screen.
> This is a useful concept to get your head around, because it pops up a lot
> with screen.  screen provides a terminal environment for anything you run
> in screen.  screen istelf runs in the environment provided by your
> terminal emulator.  If the two environments are different, screen converts
> between them as information flows back and forth.
> > Well this is the real question then. Your statement about "different
> > approaches" seems to imply that you had difficulty. I assume it's not
> > easy to get SHIFT-PgUp and SHIFT-PgDn to scroll around in (eg. half
> > pages of) screen's buffer?
> Not really.  In xterm, the scrollback buffer is modeless.  It's always
> there, just a Shift-PgUp away.  In screen, the scrollback is modal.  You
> have to enter copy mode and then you can jump around in the scrollback
> buffer.  The ideal solution for Shift-PgUp and Shift-PgDn mappings in
> screen would be that if screen was not in copy mode, they would put it in
> that mode and page up or do nothing else (for page down), while if it was
> already in copy mode they would just page up and down like their unshifted
> cousins.  In any case you would have to explicitly exit copy mode when you
> were done.
> A further subtelty is that paging up does slightly differnt things in
> xterm and screen.  xterm moves its view back a certain amount.  screen
> moves the cursor back and then adjusts the viewport to contain the
> cursor.  Depending on where the cursor is, this can lead to different
> behavior between the two.
> > Previously I mentioned that C-a a becomes tedious, well C-a [ followed
> > by some other keys (which I'm still learning) is that much more tedious.
> My fingers are by now well-trained to do 'C-a ESC' (a synonym for
> 'C-a [').  Not the best answer in the world, but true.  You could use
> bindkey to dedicate a key to entering copy mode if you want to save on
> keypresses, but the fact remains that screen is modal about that, and you
> have to do something to enter that mode.

I have succefully bound alt+PgUp to enter copy mode, and of course PgUp
and PgDown work while in copy mode, so i just hold alt for the first page
up press, and then use page up after that. It works good, and is not that
hard to get used to. You could probly bind Control+PgUp in the same
manner, however i was unable to get my terminal emulator (normally Putty
from windows) to ignore that key squence - it always intercepted it and
scrolled it's own buffer, even if that buffer was turned off. This might
be different for xterm.

I leave the escape key bound to C-a. I don't use emacs, so i don't really
ever use that combination. I also have my F1 through F10 keys bound to
various functions (including F5-F12 bound directly to certain windows).
I have found that this works very well, and i havn't run into many normal
applications that need the F-keys (mc is the only one i can think of off
the top of my head, though emacs might - i've never used it)


> > Is the only current answer at the moment "patches welcome"?
> Probably not even that, because the root of the problem is in the base
> functionality of copy mode.  You can attempt to make a patch that the
> maintainers will accept, I suppose.
> --
> contrarian of the first order... /
> PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
> --- --
> A debugged program is one for which you have not yet found the conditions
> that make it fail.
>                        -- Jerry Ogdin
> ---- --- --
> _______________________________________________
> screen-users mailing list
> address@hidden

reply via email to

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