Date: Tue, 12 Sep 1995 16:07:15 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mbarkah@hemi.com (Ade Barkah) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: xterm and status-line Message-ID: <199509122307.QAA03742@phaeton.artisoft.com> In-Reply-To: <199509122223.QAA11426@hemi.com> from "Ade Barkah" at Sep 12, 95 04:23:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm running FreeBSD 2.0.5 and xfree86. The included xterm
> advertises that it has a status-line, but I haven't been
> able to figure it out (enable it or write to it.)
>
> I've tried the following code (fragment) so I can write
> to the status line:
>
> if (tgetflag ("hs")) {
> pEnterSL=tgetstr ("ts", &_capptr);
> tputs (pEnterSL, 1, outfn);
> ...
>
> I get garbage in the current cursor position. Currently I have
> a function which simply emulates a status line but I'd like
> to get the hardware stuff to work.
Typically, a status line on an ANSI escape sequence terminal is
implemented using a scrolling region.
This works on VMS because escape sequences are always written atomically.
The Status line is updated by an escape sequence to get to the line,
a data dump, and an escapesequence to end the dump.
This is the same problem as transparent print, where an escape sequence,
print data, and another escape sequence must occur atomically.
The problem you will find in the UNIX case is that since not everyone
uses atomically correct escape sequences from TERMCAP, you may in fact
interrupt your application with your data, or interrupt your data with
your application as writes are interleaved.
Basically, all escape sequences must be transmitted in their entirety
with the terminal (or emulator) in the ground state for the transmission
to be successful.
Several multiport board manufacturer's include transparent print devices
as part of their board drivers. These operate by having an escape
sequence automaton in the driver for the terminal type attached to the
device; the atomicity of state 0 initiated sequence seta from one device
or another are arbitrated in the kernel to ensure ground state for the
mode switch.
This is also ho DECServer's implement multisession on VT330/340's.
This type of thing is also why VMS shells do not echo queued characters
while an application is running.
To ensure proper behaviour, you would have to guarantee the atomicity
of the escape sequences in the tput() code in the termcap, and you
would have to guarantee that everyone abided by this rule by using
the library instead of doing their own I/O.
That means no more apps that do 'puts("\033[2J");" to clear the screen,
etc. (use of standard I/O could break the writes up such that an
interleaved I/O from another application was not atomic).
If you could guarantee atomicity like this (VMS does it by expressly
supporting a subset of all terminal types), then it's a short way to
transparent printing, status lines, and VMS style "broadcast" alerts.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509122307.QAA03742>