Re: screen-256color terminfo entry?

[Alain Bench]

 On Thursday, May 25, 2006 at 17:16:44 +0100, Stéphane Chazelas wrote:

> On Fri, May 19, 2006 at 01:55:59PM +0200, Alain Bench wrote:
>> named yet longer "screen-256color.xterm-256color"...
> Well, screen.xterm-256color lets screen select it automatically.

    Select automatically between "screen" with 8 colors, and
"screen.xterm-256color" with 256, right. OTOS with in screenrc "term
screen-256color", it would select automatically between a generic
"screen-256color" (portable across terminals), and your Xterm-specific
enhenced entry. Which may also make sense.


    [pairs#32767]
> Debian aptitude bugs. It can't support more than 256 color pairs
> supports only ansi type color settings but insists in getting the
> color pair number from terminfo and do some unclean thing with it.

    Thanks. :-(


> I don't know of any application that uses that [comment] field

    I could very paradoxaly answer: « Me toe ». ;-)


    [ccc/initc]
> screen would need to catch those sequences anyway and record the
> values of the color settings for each window and change the whole
> color pallette when switching from window to window, which doesn't
> sound reasonable, to truly support initc.

    I hadn't thought of that, right. OTOH it doesn't anihiliate all
interest of customizing color palette; It just limits the flexibility
and possible usage scenarios. One palette per Xterm: Already good.


> There's probably a lot more other things that are irrelevant as well
> in the entry I came up with.

    If it's the case: May I suggest the construction plan I used for
"screen.putty"? I started with the latest straight "screen" changing
nearly nothing, added all supplementary keys, and added one by one only
the rare capabilities that both make sense, and work in Screen. I
carefully checked each step, with tack, the test tools of the ncurses
tarball, script, and some "normal" apps. OK: Now that I know one can
inject sequences, I'll have to review the whole thing.

    BTW even with your approach, some extended capabilities lack. You
should use the -x option of infocmp/tic.


> So Nikolai's screen-256color is the best approach, as it is terminal
> independant

    Well: Both approaches make perfect sense, and each has pros and
cons. One is portable but meagre; the other is powerful but specific.
Users having a wide range of terminals may prefer "screen" 8 colors and
universal portability, those liking enough colors may prefer
"screen-256color", and those that in practice only use Xterm may prefer
your specific entry. The choice must be proposed.


> a screen where the 256 color support is advertised (on terminals
> without 256 colors, screen translates the colors)

    Wait: That color reduction is a good feature. But the result on an 8
color terminal might be not as good. I mean: An app thinking that 256
colors are available may make use of them. Once reduced to 8, some
nuances disappear. While the same app in 8 color mode may make better
use of the 8 from the beginning.


> Yes, \007 would do it.

    Great!


Bye!    Alain.
-- 
Everything about locales on Sven Mascheck's excellent site at new
location <URL:http://www.in-ulm.de/~mascheck/locale/>. The little tester
utility is at <URL:http://www.in-ulm.de/~mascheck/locale/checklocale.c>.