[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: screen-256color terminfo entry?
Re: screen-256color terminfo entry?
Thu, 25 May 2006 22:19:18 +0200 (CEST)
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.
> 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.
> I don't know of any application that uses that [comment] field
I could very paradoxaly answer: « Me toe ». ;-)
> 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
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.
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>.
Re: screen-256color terminfo entry?, Alain Bench, 2006/05/19
Re: screen-256color terminfo entry?, Aaron Griffin, 2006/05/09
Re: screen-256color terminfo entry?, Buddy Burden, 2006/05/09
- Re: screen-256color terminfo entry?, (continued)
- Re: screen-256color terminfo entry?, Stephane Chazelas, 2006/05/14
- Re: screen-256color terminfo entry?, cga2000, 2006/05/15
- Re: screen-256color terminfo entry?, Stephane Chazelas, 2006/05/16
- Re: screen-256color terminfo entry?, cga2000, 2006/05/16
- Re: screen-256color terminfo entry?, Nikolai Weibull, 2006/05/17
- Re: screen-256color terminfo entry?, cga2000, 2006/05/17
- Re: screen-256color terminfo entry?, Nikolai Weibull, 2006/05/18
- Re: screen-256color terminfo entry?, cga2000, 2006/05/18