[Top][All Lists]

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

Re: screen + xterm scrollback

From: Phil!Gregory
Subject: Re: screen + xterm scrollback
Date: Wed, 21 Jul 2004 01:02:24 -0400
User-agent: Mutt/

* 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.

> 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
---- --- --

reply via email to

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