Re: [bug-grep] Re: [patch #3644] --initial-tab and 3 newly colorized items

[Charles Levert]

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

True.  Ok.



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

  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
    clr_eol=\E[k
  att4424|tty4424|teletype 4424
    clr_eol=\Ez
  att4424-1|tty4424-1|teletype 4424 in display function group I
    clr_eol=\Ez
  mai|basic4|MAI Basic Four in ansi mode
    clr_eol=^^
  cit500|CIE Terminals CIT-500
    clr_eol=\EK
  msk22714|mskermit22714|UCB MS-DOS Kermit 2.27 UCB 227.14 IBM PC
    clr_eol=\EK
  rbcomm|IBM PC with RBcomm and EMACS keybindings
    clr_eol=^P^P
  rbcomm-nam|IBM PC with RBcomm without autowrap
    clr_eol=^P^P
  rbcomm-w|IBM PC with RBcomm in 132 column mode
    clr_eol=^P^P
  tvi912-2p|tvi920-2p|tvi-2p|televideo w/2 pages
    clr_eol=\ET
  tvi912|tvi914|tvi920|old televideo 912/914/920
    clr_eol=\ET
  tvi912c|tvi912b|new televideo 912
    clr_eol=\ET
  tvi912cc|tvi912 at cowell college
    clr_eol=\ET
  tvi920b|tvi920c|new televideo 920
    clr_eol=\ET

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

  pt100|pt200|wren|fenix|prime pt100/pt200
    clr_eol=\E[K\E[t
  pt100w|pt200w|wrenw|fenixw|prime pt100/pt200 in 132-column mode
    clr_eol=\E[K\E[t
  pt250|Prime PT250
    clr_eol=\E[K\E[t
  pt250w|Prime PT250 in 132-column mode
    clr_eol=\E[K\E[t

Not really problematic to send just "\33[K" here, but none of these are
back_color_erase either.



> I think cl should be the default.
> I think we can hardwire it at the moment.

Ok.

> 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
"\33[K").

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"
capability.