[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: |
Tue, 10 Apr 2001 19:55:16 -0400 |
User-agent: |
Mutt/1.2.5i |
On Tue, Apr 10, 2001 at 06:24:42PM -0500, Benjamin C. W. Sittler wrote:
> I already ran tack. In fact, I used it extensively while developing this
> terminfo (which I based originally on the one for "vt100".)
ok (I'm checking on the things that I would -- no problem)
> > "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
> 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.)
maybe it's a bug in tic (xterm's sgr also begins with a '0', but I don't
see the warning -- I'll revisit that when I'm debugging: the check is
supposed to just hit some of the possibly incorrect cases, and I did find
some errors with the check, so it's not that bad).
> The details were later in my original mail:
I did read that, but didn't associate it properly.
> 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.
> > > 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.
>
>
> _______________________________________________
> Bug-ncurses mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-ncurses
--
Thomas E. Dickey <address@hidden>
http://dickey.his.com
ftp://dickey.his.com