[Top][All Lists]

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

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

From: Benjamin C. W. Sittler
Subject: Re: Description of Apple's MacOS X Terminal.app "VT-100" emulator
Date: Tue, 10 Apr 2001 20:31:14 -0500 (CDT)

On Tue, 10 Apr 2001, Thomas Dickey wrote:

> On Tue, Apr 10, 2001 at 06:24:42PM -0500, Benjamin C. W. Sittler wrote:
> > > "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.

> grumble (I'm aware that several entries do this, but since I added checks
> to tparm and tic last year, I know that tsl "may" have a column parameter).

>        to_status_line            tsl    ts   move to status line,
>                                              column #1

So should ncurses simulate a cursor-addressable status line on
non-addressable status lines by storing an image of the status line and
writing it whole each time it changes? Do any apps actually use the
cursor-addressing feature of the status line, or overwrite only part of
the status line?

> >   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

> I would have thought the ncv value covered this (it says bold, reverse
> and standout do not work with color).  ncurses would interpret that as
> saying don't send bold/reverse/standout when colors are active on a
> given cell.  tack doesn't use that rule, to see if it is working I use
> the ncurses 'b' test.

Right, the ncv in the included terminfo works around the bug. I only
mentioned the bug in the email so that an author of Terminal.app
(address@hidden, CC'ed on this discussion) could fix it in a future
revision, at which point the bold bit can be removed from the ncv bitmask.

And now for a digression...

Do you have any suggestions about placing terminal/emulalor version
numbers in TERM names? Should Apple_Terminal have a name like
Apple_Terminal_1.0 or Apple_Terminal_v41 instead? Apple_Terminal has two
different version numbers, by the way: 1.0 (the "short version") and v41
(the "bundle version".) So it's really Apple_Terminal 1.0 v41 or something
like that, but there's no guarantee that a change in either version number
actually refers to a terminal with different ncurses-vissible
capabilities. How would you recommend encoding that in the terminal name?
I fully expect future revisions to use some incompatible extensions, and
it would be nice to use a name which reflects the differences. We could
call them Apple_Terminal_R1, Apple_Terminal_R2, etc., but then users would
have no idea which terminal name to use. It seems that using the
$TERM_PROGRAM followed by the $TERM_PROGRAM_VERSION (i.e. Apple_Terminal41
for the version I'm running) would allow complete automation [TERM could
be automatically constructed in /etc/profile] but would lead to an
ever-inflating list of aliases as new versions without different terminfo
were released.

It would be very nice to support the version nuimbers natively in ncurses,
so that (for example) TERM="Apple_Terminal:41" would automatically choose
the highest-numbered Apple_Terminal terminal description numbered 41 or
lower, and would fall back to plain "Apple_Terminal" if no such
description exists.


reply via email to

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