[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-grep] Re: [patch #3644] --initial-tab and 3 newly colorized ite
Re: [bug-grep] Re: [patch #3644] --initial-tab and 3 newly colorized items
Thu, 27 Jan 2005 18:05:36 -0500
* On Thursday 2005-01-27 at 12:13:27 +0100, Stepan Kasal wrote:
> On Wed, Jan 26, 2005 at 03:10:15PM -0500, Charles Levert wrote:
> > ... it could be expensive for a slow terminal to perform,
> yes, we can ignore this. It takes some time to paint all the colours.
> > but more importantly, some terminals may not
> > even support EL (Erase in Line, "\33[K") at all.
> Do you know of any such terminal?
I ran an automated search of my terminfo database and got this meager
bounty (compared to the total number of entries).
The following terminals documents some SGR sequences but no clr_eol
aaa+rv|ann arbor ambassador in reverse video
aaa-rv-unk|ann arbor unknown type
ansi+sgr|ansi graphic renditions
ansi+sgrbold|ansi graphic renditions; assuming terminal has bold; not dim
ansi+sgrdim|ansi graphic renditions; assuming terminal has dim; not bold
ansi+sgrso|ansi standout only
ansi+sgrul|ansi underline only
att5310|att5320|AT&T Model 53210 or 5320 matrix printer
dg+color|Color info for Data General D470C terminals in ANSI mode
dg+color8|Color info for Data General D220 and D230C terminals in ANSI mode
ecma+color|color control for ECMA-48-compatible terminals
ecma+sgr|attribute capabilities for true ECMA-48 terminals
ibm+16color|IBM aixterm color definitions
ibm+color|IBM color definitions
klone+color|color control for ansi.sys and ISO6429-compatible displays
klone+sgr|attribute control for ansi.sys displays
klone+sgr-dumb|attribute control for ansi.sys displays (no ESC [ 11 m)
ln03|dec ln03 laser printer
ln03-w|dec ln03 laser printer 132 cols
nsterm+c|AppKit Terminal.app v51+ full color support (including 16 colors)
nsterm+c41|AppKit Terminal.app v41 color support
xnuppc+c|Darwin PowerPC Console ANSI color support
Of these, some are actually printers, some are synthetic entries,
leaving only a few real terminals (which may even support an EL clr_eol
capability but have not documented it). Of the real ones, only "dg+color"
and "dg+color8" document back_color_erase; does anyone know if they in
fact support EL ("\33[K")?.
The following terminals documents some SGR sequences and an incompatible
(non-EL) clr_eol capability:
ansi.sys-old|ANSI.SYS under PC-DOS 2.1
att4424-1|tty4424-1|teletype 4424 in display function group I
mai|basic4|MAI Basic Four in ansi mode
cit500|CIE Terminals CIT-500
msk22714|mskermit22714|UCB MS-DOS Kermit 2.27 UCB 227.14 IBM PC
rbcomm|IBM PC with RBcomm and EMACS keybindings
rbcomm-nam|IBM PC with RBcomm without autowrap
rbcomm-w|IBM PC with RBcomm in 132 column mode
tvi912-2p|tvi920-2p|tvi-2p|televideo w/2 pages
tvi912|tvi914|tvi920|old televideo 912/914/920
tvi912c|tvi912b|new televideo 912
tvi912cc|tvi912 at cowell college
tvi920b|tvi920c|new televideo 920
These are problematic, but none of them are back_color_erase.
The following terminals documents some SGR sequences and a clr_eol
capability which includes "\33[K" but also other stuff besides "\33[m":
pt100w|pt200w|wrenw|fenixw|prime pt100/pt200 in 132-column mode
pt250w|Prime PT250 in 132-column mode
Not really problematic to send just "\33[K" here, but none of these are
> I think cl should be the default.
> I think we can hardwire it at the moment.
> It's up to you whether you
> want to remove the code for boolean capabilities or not.
Should use of "\33[m\33[K" be the default, it is clear that the "cl"
capability must be gone as such by the very nature of a boolean capability
in a termcap-like string ("true" must not be the default as it cannot
be reverted; "false" is not having it at all in the whole string).
The question would then be, should it be replaced by another boolean
capability (with a different name and opposite semantics) whose very
presence would imply reverting to use of plain "\33[m" (without the
The other possibility would be a limited set of boolean capabilities
to support each of the other clr_eol variants ("\33[k", "\33z", "\36",
"\33K", "\20\20", "\33T", and "\33[K\33[t"). This would be useless since
all the targetted terminals can live with just an opposite-cl capability
since they are not back_color_erase.
I think I will submit a new patch with an opposite-semantic "ne"
[bug-grep] Re: [patch #3644] --initial-tab and 3 newly colorized items, Charles Levert, 2005/01/26