Re: screen-256color terminfo entry?

[cga2000]

On Sun, May 14, 2006 at 07:46:58AM EDT, Stephane Chazelas wrote:
> On Sat, May 13, 2006 at 08:19:19PM -0400, cga2000 wrote:
> [...]
> > Now one thing that I had not mentioned earlier is that apart from the
> > 256-color business, I had also enabled UTF-8 by doing two things:
> > 
> > 1. changing my locale to en_US.UTF-8
> > 2. running "xterm -u8"
> 
> That may be that. Maybe groff (the man macro processor) thinks
> your terminal talks UTF8 (because of the en_US.UTF-8), but your
> screen window is configured as to use some 8bit charset.
> 
I went back to an UTF-8 locale and tested - this time after setting the
"-U" command-line flag and still no luck. 

> What do you get when you type <Ctrl-A>i. 

Well right now I'm back to regular 8-bit and it does not say much,
things like the number of lines and columns of my terminal, 256 colors,
+flow app .. G0[B0BB] .. and the screen I'm on (3 mutt).

> If there's no mention
> of UTF-8, then type <Ctrl-A>:encoding utf8
> 
> and see if that makes any difference.

I briefly re-tested the whole thing with locale set to en_US.UTF-i,
uxterm, screen -U, and your terminfo entry and I was still getting the
truncated status line in mutt/weechat and the man/groff formatting
problem. It appears that the lines that are not rendered correctly in
man (with PAGER="less -isX") all start with the '-' (minus) or '+'
(plus) character. 
> 
> Then, you may need to put a defencoding utf8, or a defutf8
> in your ~/.screenrc
> 
> Also, maybe screen thinks your terminal doesn't understand utf8,
> but it should if the locale is correct at the time screen is
> started. You may want to try and play with the -U option to see
> if that makes a difference.
> 
> With encoding set to UTF8, LC_ALL set to en_US.UTF-8, xterm -u8
> and groff sgr reenabled (as you seem to have it), I have no
> problem. With encoding iso8859-1, I can see some formating
> problems, but not on the line with -132. But maybe you have a
> different version of groff that uses some UTF8 character for "-"
> for instance instead of the ASCII dash.
> 
> It would be nice to know what groff (it grotty backend) is
> actually outputting.
> 
> <Ctrl-A>H
> PAGER='env LC_ALL=C cat -vte' man xterm
> <Ctrl-A>H
> grep DECCOL screenlog.$WINDOW
> 
Well here's a hopefully raw version copied via screen's copy/paste capabilities:

       -^H-1^H13^H32^H2    Normally,  the VT102 DECCOLM escape sequence that 
switches between 80 and 132 column mode is ignored.  This option causes the 
DECCOLM escape sequence to be recognized, and the _^Hx_^Ht_^He_^Hr_^Hm window 
will resize$
               Specifies whether or not the VT102 DECCOLM escape sequence, used 
to switch between 80 and 132 columns, should be honored.  The default is 
``false.''$

Not sure you'll get it as I see it. If not, I could upload the entire log file 
to the web.

> Nikolai's entry is:
> 
> screen-256color|VT 100/ANSI X3.64 virtual terminal,
>         am, km, mir, msgr, xenl,
>         cols#80, it#8, lines#24, colors#256, pairs#32767,
>         bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z,
>         clear=\E[H\E[J, cr=\r, csr=\E[%i%p1%d;%p2%dr,
>         cub=\E[%p1%dD, cub1=\b, cud=\E[%p1%dB, cud1=\n,
>         cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
>         cuu=\E[%p1%dA, cuu1=\EM, dch=\E[%p1%dP, dch1=\E[P,
>         dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K,
>         enacs=\E(B\E)0, home=\E[H,
>         ht=\t, hts=\EH, ich=\E[%p1%d <at> , il=\E[%p1%dL, il1=\E[L,
>         ind=\n, is2=\E)0, kcub1=\EOD, kcud1=\EOB,
>         kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kf1=\EOP,
>         kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf2=\EOQ,
>         kf3=\EOR, kf4=\EOS, kf5=\E[15~, kf6=\E[17~,
>         kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\E[1~, kend=\E[4~,
>         kich1=\E[2~, knp=\E[6~, kpp=\E[5~, nel=\EE,
>         rc=\E8, rev=\E[7m, ri=\EM, rmcup=\E[?1049l, rmir=\E[4l,
>         rmkx=\E[?1l\E>, rmso=\E[23m, rmul=\E[24m, rs2=\Ec, sc=\E7,
>         sgr0=\E[m, smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=,
>         smso=\E[3m, smul=\E[4m, tbc=\E[3g, smacs=^N, rmacs=^O, flash=\Eg,
>         civis=\E[?25l, cnorm=\E[34h\E[?25h, cvvis=\E[34l,
>         op=\E[39;49m, setab=\E[48;5;%p1%dm, setaf=\E[38;5;%p1%dm,
>         
> acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++\054\054hhII00,

Nikolai's entry corrects the mutt/weechat display issue and causes man +
less/most's output to be correctly formatted - as far as I can tell.

But so far it has caused the following problems:

1. the bash Ctrl+R (search history) command does not function
correctly. I hit Ctrl+R and for each character I enter I see a "t >"
overlaying the bash prompt and the command currently selected by the
incremental search is not visible. ehich makes it unusable - for all I
know the selected command could be an "rm" command that I absolutely do
not want to (re-)execute.

2. the weechat irc client mentioned earlier crashes at startup
(SIGSEGV). Running it under your terminfo entry corrects the problem.

[ <- differences between the two terminfo entries snipped .. -> ]

> 
> So, pretty similar. Nikolai ommits a lot of features. I included
> all the function keys that xterm implement and that screen
> should let pass through untranslated. Same of the redefinition
> of colours, the kmous that is missing as well in the official
> screen entry although screen supports it.
> 
> For smacs, rmacs, it's not clear who's right, the documentation,
> and $TERMCAP seem to say it's me, but the "screen" entry and the
> code would suggest it's Nikolai. \E(0 sets the G0 charset to be
> the graphical charset, While ^N selects the G1 charset
> (initialised by Nikolai's enacs with \E)0). Both approaches look
> valid to me, but I find Nikolai's one neater, though it is
> apparently not the one chosen by screen (according to $TERMCAP).
> 
> For xterm, it's probably better to set bce to true (both at
> screen and terminfo level, as xterm is bce)
> 
> In any case, it shouldn't have any incidence on the problems
> you're seeing, I think.

Well, I'd say that this is the only useful part of my modest findings:
The two problems I was experiencing with your terminfo entry - and
xterm-256color regarding the "truncated highlights" - are fixed by his
screen-256color. But as mentioned above it introduces at least two
other (more serious, imo) problems. 

My personal feeling is that I should modify your (more complete)
screen-256color to fix my two problems but I honestly have no idea how
this should be done. And using the diff's to randomly change your
terminfo entry without a clue what I am looking for does not sound
like realistic approach. 

On the other hand considering all the trouble you have taken over this I
am quite willing to make any changes you suggest and run more tests
until I get this right - the problem being that I have zero experience
with terminfo.

In any case since nobody seems to have provided an official
screen-256color terminfo entry as yet, it certainly would be worth the
effort as far as I am concerned. vim in particular has some really nice
color schemes for 256-color terminals.

Please let me know if you have the time to pursue this.

Thanks,

cga