bug-hurd
[Top][All Lists]
Advanced

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

Re: smcup and rmcup support for the console server


From: Marcus Brinkmann
Subject: Re: smcup and rmcup support for the console server
Date: Wed, 6 Aug 2003 02:34:53 +0200
User-agent: Mutt/1.5.4i

On Tue, Aug 05, 2003 at 11:54:58PM +0200, Marco Gerards wrote:
> A later version will support 3 options:
> --rmcup=on
> --rmcup=off
> --rmcup=to-scrollback-buffer
> 
> I know that these argument names suck and I'd like to hear a good
> alternative name. :)

Don't focus on technicalities, nobody knows what the hell rmcup is anyway.
Rather, focus on the feature it provides to the user.  For example:

--alt-screen=on,off,scrolls

or something like that.
 
> rmcup=on
> 
> Works more or less the same as on xterm. Xterm really
> switches to an alternative screen, this patch doesn't work that way. It
> just backups the visible screen and cleans it. Because of this the
> scrollback buffer still works.

Ah, I see.  We didn't consider that when we talked about this feature.

> There is one problem with this mode. Because I just backup the visible
> screen and don't put any other restrictions on the screen (is this
> possible and do we want this?). The "smcup application" can destroy
> the scrollback buffer a bit as I have noticed. less does this for
> example. (It can clear one screen of the scrollback buffer).
>
> Perhaps I don't understand the console good enough to see why this
> exactly happens. I know this can be prevented by backing up the whole
> buffer instead of just the visible screen.

Possibly it just tries to clean the screen by letting everything scroll off.

I have an idea how to make this work:  When in alt-screen mode, just disable
scrolling into the scrollback buffer.  The function display.c:linefeed()
does the check if a scrolling region is active: If yes, it doesn't scroll
into the scrollback buffer, but just scrolls within the scrolling region.

For a smcup/xterm style alternate screen, I guess it is sufficient to just
set a scrolling region that is as big as the screen.  This is in fact what
xterm seems to do, too:  If you try "echo `tput smcup`" you will notice that
the alt screen has no scrollback buffer.  "echo `tput rmcup`" takes you back.

One small implementation problem is that currently a screen sized scrolling
region is interpreted as no scrolling region.  This is easily fixed by
changing the meaning of csr (for example, top == (uint32_t) -1 can mean that
no scrolling region is active).  Then the existing code only needs minimal
changes to make it work as expected.

Note that if you use the scrolling region for this hack, you still need to
support setting and clearing the scrolling region for the alt screen!  So it
is probably better just having a flag alt-screen that is checked, rather
than actually using a scrolling region of 0/lines-1 directly.

The only difference left is that the console clients will still be able to
see the scrollback buffer.  A flag in the shared memory can be used to
indicate to clients that the alternate screen mode is in effect, and that
the client might want to disable scrollback while this flag is set (if it
wants to do that).  This would be sufficient to be able to fully emulate
xterms behaviour.  Adding such a flag is trivial.  Implementing it in the
client is almost as easy, but it's not even important to implement it right
now.

So, to summarize: Have a flag in the shared mem page.  Use this flag in
linefeed() to determine if to scroll into the scrollback buffer or not.

> rmcup=to-scrollback-buffer
> 
> This nice feature was a really good idea of Marcus. It does the same
> as rmcup, but puts the alternate screen in the scrollback buffer
> instead of overwriting it.

To clarify this: At smcup it would scroll one screen's full of content into
the scrollback buffer.  At rmcup it would just leave the screen content
intact.  The scrolling stuff would work as above.

BTW, I think that if less indeed can corrupt the scrollback buffer if smcup
is used, then, because we will declare smcup/rmcup in the terminfo
description unconditionally, we might need to preserve the scrolling
behaviour as above during smcup even if rmcup=off is used, just so that less 
doesn't do
anything destructive.  We will see by trying out what works.

>       * display.c (struct display): New member ALT_CURSOR and ALT_SCREEN.
>       (screen_to_alternate): New function.

> +  struct
> +  {
> +    /* Width of screen matrix.  */
> +    uint32_t width;
> +    /* Number of lines in visible area following
> +       (and including) CUR_LINE.  */
> +    uint32_t height;
> +    /* Is NULL when the alternate screen is not active.  */

Do you need to duplicate width and height here?

> +    conchar_t *_matrixp;
> +  } alt_screen;
> +

> +  /* Save the cursor position. XXX: Should the visibility be saved?  */

I think we might need to save much of the state - including things
like scrolling region etc.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/




reply via email to

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