Re: Description of Apple's MacOS X Terminal.app "VT-100" emulator

[Benjamin C. W. Sittler]

On Tue, 10 Apr 2001, Thomas Dickey wrote:

> On Mon, Apr 09, 2001 at 10:13:20PM -0500, Benjamin C. W. Sittler wrote:
> > Attached is a preliminary terminfo description of the Terminal.app
> > included in Apple's MacOS X. While not exhaustive, it does seem to work
> > with emacs, lynx, vi, less, bash, ls, ncurses, and screen. Also attached
> > is a termcap version automatically generated from the terminfo source.

> thanks.  "seems to work" is a little weak -- I find that if I run 'tack'
> from ncurses, that there are occasional small fixes to make, e.g., in
> bw, xenl, etc., which I would overlook.  Did you do that too?  (This looks
> complete, by eye).  You might also take a look at the checking options of
> tic (tic -cv).  The differences appear to be more than just the trailing ^O:

I already ran tack. In fact, I used it extensively while developing this
terminfo (which I based originally on the one for "vt100".)

> "foo.ti", line 1, terminal 'Apple_Terminal-ascii-m': tsl uses 0 parameters, 
> expected 1

This is not an error, the status-line is offscreen and is not
column-addressable.

> "foo.ti", line 1, terminal 'Apple_Terminal-ascii-m': enter_standout_mode 
> differs from sgr(1): "\e[0;1;7m\^O"
> "foo.ti", line 1, terminal 'Apple_Terminal-ascii-m': enter_underline_mode 
> differs from sgr(2): "\e[0;4m\^O"
> "foo.ti", line 1, terminal 'Apple_Terminal-ascii-m': enter_reverse_mode 
> differs from sgr(3): "\e[0;7m\^O"
> "foo.ti", line 1, terminal 'Apple_Terminal-ascii-m': enter_blink_mode differs 
> from sgr(4): "\e[0;5m\^O"
> "foo.ti", line 1, terminal 'Apple_Terminal-ascii-m': enter_bold_mode differs 
> from sgr(6): "\e[0;1m\^O"
[snipped identical messages for the other three terminals]

This "sgr" attempts to reset attributes before enabling the ones
specified, hence the leading SGR "0" argument and the SI. Is that not
correct behavior for sgr? The individual attribute setters (smso, smul,
rev, blink and bold) don't reset other attributes, since that would make
them non-mixable. This does have one side-effect: sgr clears all color
attributes, and gives no way to set them. Is this a bug? If so, the sgr
entry should be removed from the color variants (Apple_Terminal-ascii and
Apple_Terminal.)

[snip]
> > Version "41" of Terminal.app has a few oddities and shortcomings which
> > lead to the four included entries: character set support is slightly
> > broken, function keys are missing, color support is slightly broken, and
> > the user can enable or disable color using a checkbox in the preferences
> > panel.

> hmm - what sort of "slightly broken" (details would help everyone)

The details were later in my original mail:

  Terminal.app supports a fixed palette of eight colors using the ANSI
  foreground and background color-change sequences. However, changing
  background colors while the bold attribute is enabled causes the wrong
  background colors to be displayed. For this reason the terminal
  description forbids the use of bold in conjunction with color-change
  sequences. Since the user can disable color support using a checkbox in
  the preferences panel, monochrome terminal descriptions "Apple_Terminal-m"
  and "Apple_Terminal-ascii-m" have been provided.

Using the bold attribute (bold) in conjunction with background
color-change sequences (setab) causes Terminal.app's "internal" palette to
be displayed. This includes:

requested ANSI background color    actual color   Terminal.app internal use
                                   (in my setup)
0 BLACK                            YELLOW         ???
1 RED                              WHITE          Inverse Background
2 GREEN                            GRAY           Selected Text
3 YELLOW                           RED            ???
4 BLUE                             BLACK          ???
5 MAGENTA                          WHITE          ???
6 CYAN                             GREEN          ???
7 WHITE                            BLUE           ???

This bug was not present in some earlier versions of Terminal.app, and is
likely to disappear in future versions. Two of these internal colors are
configurable using the properties panel. Basically, it's a bug in
Terminal.app.

> > Strict VT-100 emulation mode is not accounted for by these terminal
> > descriptions, as most users leave it disabled. Mouse cursor position
> > reporting is not described by these descriptions, but appears to work in
> > Emacs [use Option-click to position the cursor.] The Terminal.app titlebar
> > is configurable using the same sequences understood by xterm, and is used
> > as a status line by these terminal descriptions.

> if we added kmous=\e[M, would that work for ncurses?

No, after further research the Option-click hack appears to be a
disgusting heuristic mess which simulates enough cursor key presses to
move the cursor from its current position to the requested position.
Obviously, this fails under a variety of conditions. We can hope for kmous
in a future version of Terminal.app, I guess.

Ben.