[Top][All Lists]

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

Re: Alternate buffer reset

From: Bryan Christ
Subject: Re: Alternate buffer reset
Date: Mon, 24 Dec 2018 15:31:25 -0600

Ya.  I figured that out to my dismay.  RXVT sets rs1 to a really long series of codes instead of \Ec.  My only option seems to be decoding for that really long sequence.

On Mon, Dec 24, 2018 at 2:26 PM Thomas Dickey <address@hidden> wrote:
On Mon, Dec 24, 2018 at 01:06:06PM -0600, Bryan Christ wrote:
> Okay.  So when I do a "reset" (by that I mean typing the bash reset
> command), these are the following sequences I see emitted.  Nothing really
> stands out according to it's descriptions that makes me think I need to pop
> my emulator out of alternate buffer mode.  Maybe it's implied by one of
> these?  ( perhaps esc[2J or esc[r )
> esc>
> esc[1;3;4;5;6l
> esc[?7h
> esc[m
> esc[r
> esc[2J
> esc[H
> esc[?1;3;4;6l
> esc[4l
> esc[?1000l
> esc[?25h
> esc]0

none of those would do it.  In xterm, a hard reset (\Ec) would switch
back from the alternate screen, or one of the modes listed in ctlseqs:

            Ps = 4 7  -> Use Normal Screen Buffer, xterm.

            Ps = 1 0 4 7  -> Use Normal Screen Buffer, xterm.  Clear the
          screen first if in the Alternate Screen Buffer.  This may be
          disabled by the titeInhibit resource.

            Ps = 1 0 4 9  -> Use Normal Screen Buffer and restore cursor
          as in DECRC, xterm.  This may be disabled by the titeInhibit
          resource.  This combines the effects of the 1 0 4 7  and 1 0 4
          8  modes.  Use this with terminfo-based applications rather
          than the 4 7  mode.

such as \E[?1049l
(that's in the rmcup capability)

> On Sun, Dec 23, 2018 at 5:37 PM Thomas Dickey <address@hidden> wrote:
> > On Sat, Dec 22, 2018 at 09:55:39AM -0600, Bryan Christ wrote:
> > > When I issue a "reset" command, there are quite a few control codes that
> > > get emitted.  When I cross reference them in the VT100 manual and the Xterm
> > > manual, none of the codes specifically state that they should "hard reset"
> > > the terminal.  Basically, I'm wondering what would be a good control code
> > > to regard for that so that I can flip my terminal buffer back to normal?
> >
> > well... usually there's no hard reset (for xterm) since it's intentionally
> > emulating a VT220 (or higher).  A real hardware terminal would do odd things
> > like resetting the connection to the host; xterm imitates some of that by
> > a bell - not something that users like a lot.

Thomas E. Dickey <address@hidden>


reply via email to

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