RE: 4855 does not work in all cases

["Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>]

>
> Andrej Borsenkow wrote:
> >
> > > Variable            Cap Name  I. Code  Description
> > > eat_newline_glitch  xenl      xn       Ignores new-line character after 80
> > >                                        columns
> > Unfortunately, it is not defined for dtterm (at least on our
> system). It seems
> > to be defined for xterm and one more terminal type that do have the
> feature. But
> > this is the general problem - how can you be sure that
> terminfo/termcap reflect
> > the truth? Users are free to modify settings on the fly :-(
>
> I'm no terminfo expert so correct me if I'm wrong but I'm assuming that
> this xenl can either be set to true or false or can be not defined?

Sorry. Of course, it is boolean and can either be defined (== TRUE) or be not
defined ( == FALSE).


If
> this is correct then we should be all right as long as we can make a
> good assumption in the case of not defined (the xterm behaviour I
> suppose). Is xenl correct in the case of aixterm?

Exactly for my xterm it is set (defined) and that is correct. I cannot tell
anything about aixterm as I've never seen it .

                                                                          When
you say 'users
> are free to modify settings on the fly', does this include xenl or just
> things like am which are on the various mouse menus?

I meant am and friends. xenl is probably too obscure ...

If users are
> modifying xenl, then surely they deserve everything they get so I
> wouldn't see that as a problem. If terminfo/termcap entries are
> occasionally wrong it might be better to mention how to fix them in the
> FAQ than to write a load of nasty hacks to the code.
>

Agreed (if only system updates won't overwrite fixed entries :-)

> > if (!am || xenl) puts("\r\n");
> > Not sure, that "\r\n" looks much better than " \n", but this works without
> > auto-margin as well. Funnily enough, it will work even on my dtterm (that is
> > configured for am but with terminfo that does not list this :-)
>
> What doesn't it work for - only incorrect terminfo/termcap?
>

Yes. But in this case terminal must do am, do not do xenl and terminfo must have
both wrong. Too much I presume. In mu case terminfo has them both wrong,  my
dtterm does am - but it also does xenl :-)

But actually, as I discovered, the original problem was much simpler. Consider:

bor@itsrm2:~%> foo-list () {
function> compadd -- "axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxx" "ayyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
yyyyyyyyyyyyyyyyyyyyyyyyy"
function> }
bor@itsrm2:~%> compdef foo-list foo-list
bor@itsrm2:~%> echo $$
13
bor@itsrm2:~%> foo-list a<TAB>
axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

ayyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

And when I truss it, I see:

bor@itsrm2:/tools/src/zsh-3.1.5-pws-25/Functions/Zle%> truss -w 10 -t write -p 1
3
write(10, " a", 1)                              = 1
    Received signal #18, SIGCLD, in sigsuspend() [caught]
      siginfo: SIGCLD CLD_EXITED pid=1664 uid=0 status=0x0001
write(10, "\r\n", 2)                            = 2
write(10, 0x00000000004E8950, 190)              = 190
   a x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
   x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
   x x x x x x x x x x x x x x x x  \n a y y y y y y y y y y y y y
   y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y
   y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y y
   y y  1B [ 4 A1B [ 0 m1B [ 2 2 ; 2 7 m1B [ 2 4 m\r1B [ 1 5 C
write(10, 0x00000000004E8950, 13)               = 13
  1B [ 2 2 ; 2 7 m1B [ 1 0 C

Note the extra "  " at the end of every match that is listed. I have no idea,
where it comes from. Probably, without this extra " " nobody would even notice
this problem.


/andrej