[Top][All Lists]

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

Re: Obsolete smir/rmir sequences for ansi-generic?

From: Thomas Dickey
Subject: Re: Obsolete smir/rmir sequences for ansi-generic?
Date: Sun, 16 Apr 2017 12:41:25 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Apr 16, 2017 at 12:44:22AM -0500, Rob King wrote:
> Hello,
>     The description for the "ansi-generic" terminal type includes a
> reference to the "ansi+idc" building block, which in turn defines
> both smir and rmir to \E6. This is the "zTI/Toggle IRM" sequence.
>     The only documentation I can find that references that sequence
> is for the Ambassador line of terminals (where it might be more
> accurately labeled as k{r,s}mir), and for the AIX High Function
> Terminal. The 1991 edition of ECMA-48 doesn't define it, and while I
> don't have a copy of X3.64, it doesn't show up in any summaries of
> ANSI escape sequences that I can find. xterm defines it as Back
> Index (DECBI).
>     Since the "ansi+idc" entry is designed to be used as a building
> block for other "ANSI-like" terminal definitions, I would recommend
> replacing those sequences with "\E[4h" and "\E[4l", since those seem
> to be universally supported. This greatly increases (IMHO) that
> entry's usefulness as a building block. The SRM-style sequences also
> have the benefit of being idempotent.

I generally agree (thanks).  Here's what I found in composing a response

The usage in hft appeared in 4.4BSD, but not in the earlier sources which I
have at hand.  A different hft (see below) appeared in 4.3BSD, but not in
4.2BSD (which was the point at which AT&T/SCO forked terminfo).

Using the jonathangray git, the 4.3BSD change was made in 1990:

        commit e60e05c2ca88b675bf902ced1f00366b87e6e29a
        Author: John A. Kunze <jak>
        Date:   Fri Apr 27 14:44:47 1990 -0700

            new IBM 8512 High Function Terminal (HFT) entry

            SCCS-vsn: 5.75

using this line (equivalent to what you're suggesting):


and the 4.4BSD change was made in 1991 (leaving the older one as "hft-c"):

        commit ca5db9385f15667e5e7e61b09269e5042361d058
        Author: John A. Kunze <jak>
        Date:   Tue Apr 30 15:30:29 1991 -0700

            added AIWS High Function Terminal from IBM

            SCCS-vsn: 5.87

Oddly, the SCO terminfo has this chunk:

                dch1=\E[P, ich=\E[%p1%d@, ich1=\E[@,
        #       smir=\E6, rmir=\E6,     commented out by ehr3

where the initials "ehr3" appear only once - but probably
        Ernest H Rice III

That block was used in its entry for "ansiterm":

        # Info:
        #       ANSI is a vanilla ANSI terminal. This is assumed to implement
        #       all the normal ANSI stuff with no extensions. It assumes
        #       insert/delete line/char is there, so it won't work with
        #       vt100 clones. It assumes video attributes for bold, blink,
        #       underline, and reverse, which won't matter much if the terminal
        #       can't do some of those. Padding is assumed to be zero, which
        #       shouldn't hurt since xon/xoff is assumed.
        #       We assume a 24x80 screen. This entry was derived from the
        #       Ann Arbor Ambassador, and is untested.
        ansiterm|generic ansi standard terminal,
                use=vanilla, am, cols#80, lines#24, xon,
                use=ansiterm+cup, use=ansiterm+rca,
                use=ansiterm+loc1, use=ansiterm+loc,
                use=ansiterm+idc, use=ansiterm+idl1, use=ansiterm+idl,
                use=ansiterm+sgrbd, use=ansiterm+arrow,

ncurses doesn't have an entry for "ansiterm" (I recall some discussion
about that omission a while back, but don't want to digress).

A quick check of the terminal database doesn't show that there's anything
currently using this block, so that correcting it shouldn't break anything.
>     Someone please correct me if I'm wrong.

That's hard to say.  Most of the entries are not testable, and those which
are take a chunk of time to review (when you see updates for terminfo.src,
just assume that took 3-4 hours).  Adding to the problem, many are cut/paste
from poorly-tested (or incomplete entries).  And of course, I can't simply
copy and collate content from the vendors (another digression postponed...)

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

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