[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: |
Thomas Dickey |
Subject: |
Re: Description of Apple's MacOS X Terminal.app "VT-100" emulator |
Date: |
Wed, 11 Apr 2001 05:15:56 -0400 |
User-agent: |
Mutt/1.2.5i |
On Tue, Apr 10, 2001 at 08:31:14PM -0500, Benjamin C. W. Sittler wrote:
> 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?
no - there's no higher-level interface that knows about status line.
My interest here is for whatever applications might get this information
directly from termcap/terminfo and use it for positioning (I don't
have any in mind, but could of course construct one - would do that if
I implemented status line for xterm).
> 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
not really - I add some of that info to XFree86 xterm just to distinguish
(and retain some history) for older versions. But since there's nothing
that automatically sets $TERM appropriately it's just for informational
purposes.
> 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.
I'm not sure: first, it's not something that I would anticipate being
widely used (for terminals whose description is both evolving and capable
of being automatically recognized), and also how I could encode it to
fit in the existing structure (though I suppose if the need arose, we
could solve the latter issue).
--
Thomas E. Dickey <address@hidden>
http://dickey.his.com
ftp://dickey.his.com