Re: screen + xterm scrollback

[Zenaan Harkness]

On Tue, 2004-07-20 at 14:13, Phil!Gregory wrote:
> * Zenaan Harkness <address@hidden> [2004-07-20 09:03 +1000]:
> > termcapinfo xterm|xterms|xs|rxvt ti@:te@
> > 
> > Which is all very well, but what I need is to figure out how to do key
> > mapping properly, so that SHIFT+PgUp and SHIFT+PgDn do the
> > scroll-half-page-[up|down] thing, for it to actually work the same as an
> > xterm.
> > 
> > And what should I put for scrollback buffers - should xterm and screen
> > both have 5000 (or whatever) buffer, just xterm, or just screen?
> 
> * Zenaan Harkness <address@hidden> [2004-07-20 11:08 +1000]:
> > with xterm, if I use less, it blanks the screen, and asks me to press a
> > key to end. When I press a key, whatever was on the screen before
> > returns, and the output from less disappears.
> > 
> > Does someone know why this is?
> 
> These are related.  One capability that a terminal may have is an
> "alternate screen".  xterm has it, and you have seen its effects--a
> program will request the alternate screen, the terminal switches there,
> and then it goes back to the normal screen, leaving all the text there
> intact.  It is recommended that all full-screen apps use this, so as to
> minimize their impact on any purely command-line stuff.  It makes sense,
> for instance, for vi to use the alternate screen.  less probably does
> because it's technically a full-screen app, but it's kind of annoying,
> because using the alternate screen doesn't put things into the terminal's
> main scrollback buffer.
>
> My solution is to run everything in screen (heh) and use the termcapinfo
> command above to disable the alternate screen.  Disabling the alternate
> screen also has the side effect of putting stuff into xterm's scrollback
> buffer, which is sometimes useful.

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.

And when commented out, screens scrolled output is indeed _not_ put into
xterms buffer (dumping some output and using scrollwheel and/ or
SHIFT-PgUp and SHIFT-PgDn verifies this).

> Not always, however, because if you scroll a little in screen, then change
> screen windows and scroll a little more, xterm gets bits from both
> windows.  For this reason, I keep a relatively short xterm scrollback
> buffer (just enough for immediate "oh, what was that up there?") while
> giving screen a big buffer.

Yes, I see this effect, and that makes sense.

> I played a little while back with trying to use Shift-PgUp to go into
> screen's scrollback instead of xterms, but it didn't really work because
> the two programs take different approaches to how their scrollback buffers
> work.

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?

This is the last significant "my fingers just do this all the time and
it never works" type problem with screen, for me.

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.

Is the only current answer at the moment welcome"?

thanks heaps
zen