Still there's a little zle_refresh bug

Still there's a little zle_refresh bug

[Zoltan Hidvegi]

The last patch from Geoff really fixes almost all zle_refresh problems
except one.  This does not happen on all machines.  It is reproducible on
Linux with ncurses and on Solaris with Linux console or xterm.  Both use
terminfo.  Type in a long line which appears wrapped on the screen.  Then
insert a charater near the end of the first screen line, e.g. here -------|
                                                                          V
hzoli ~ % 12345678901234567890123456789012345678901234567890123456789|1234567890
1234567890

Here is what happens if you inserted a `*':

hzoli ~ % 12345678901234567890123456789012345678901234567890123456789|1234*56789
00234567890

As you see the 0 is duplicated on the wrapped line and 1 disappears.
But this only happens if you insert something after the `|' character above.
Also there should be at least 10 characters in the second screen line.

Bye,

Zoltan

Re: Still there's a little zle_refresh bug

[Mark Borges]

Geoff posted a second patch (in article #831) for zle_refresh. Was
that supposed to fix this particular bug (which was posted before the
2nd patch), or not?

If it was, I'm still seeing it on my solaris-2.3/2.5 platforms, and will
invetigate further if it is in fact platform-dependent.

Just curious.

  -mb-

>> On Fri, 15 Mar 1996 16:02:05 +0100 (MET),
>> Zoltan Hidvegi(ZH) wrote:
ZH> The last patch from Geoff really fixes almost all zle_refresh problems
ZH> except one.  This does not happen on all machines.  It is reproducible on
ZH> Linux with ncurses and on Solaris with Linux console or xterm.  Both use
ZH> terminfo.  Type in a long line which appears wrapped on the screen.  Then
ZH> insert a charater near the end of the first screen line, e.g. here -------|
ZH>                                                                           V
ZH> hzoli ~ % 12345678901234567890123456789012345678901234567890123456789|1234567890
ZH> 1234567890

ZH> Here is what happens if you inserted a `*':

ZH> hzoli ~ % 12345678901234567890123456789012345678901234567890123456789|1234*56789
ZH> 00234567890

ZH> As you see the 0 is duplicated on the wrapped line and 1 disappears.
ZH> But this only happens if you insert something after the `|' character above.
ZH> Also there should be at least 10 characters in the second screen line.

Re: Still there's a little zle_refresh bug

[Wayne Davison]

Mark Borges writes:
> I'm still seeing [a zle_refresh bug] on my solaris-2.3/2.5 platforms

It's a problem that depends on the insert-character terminal attribute
being present.  Using your example of a series of '1234567890's on a
line with a '0' as the last character before the line-wrap, I get the
following output when I type the '*' prior to the '5' (using an xterm
that includes the insert-character attribute as "^[[@"):

*567890^M^[[@0

As you can see, it outputs enough characters to get down to the next
line (which includes outputting the NEW first character on the next
line) and then tries to do an insert at the start of the line.  If
it had output the OLD first character when forcing a line wrap (or
had done the insert of the '1' at the second position) it would have
worked correctly.

In the case of a terminal without any insert character, it outputs the
following:

*567890^M01234567890

In this case it would still be OK for the force-a-line-wrap character
to be the OLD first character on the line since it gets overwritten.

I don't have time to fix the problem at the moment, but I hope that
this diagnosis will allow someone else to tweak the code.

..wayne..

Re: Still there's a little zle_refresh bug

[mason]

:Geoff posted a second patch (in article #831) for zle_refresh. Was
:that supposed to fix this particular bug (which was posted before the
:2nd patch), or not?
:If it was, I'm still seeing it on my solaris-2.3/2.5 platforms, and will
:invetigate further if it is in fact platform-dependent.
:Just curious.
                                                                         *
original two lines with insert at * % 1234567890123456789012345678901234567890
1234567890

I just worked out the logic of the bug and I'll post a patch for this in a 
few hours.  The problem was on the second line: at the start, the first char
'0' then '\r' got printed due to automargin stuff, then an insert char,
then '0' to fill the blank spot - when the code was originally written
there would not have been the first char '0' written.  There's an obvious hack
in the code here, but for other reasons I don't want to do that, so I'll write
a nice complex, hard-to-understand patch for it instead :-)
-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"

Re: Still there's a little zle_refresh bug

[mason]

I wrote:
:I just worked out the logic of the bug and I'll post a patch for this in a 
:few hours.  The problem was on the second line: at the start, the first char
:'0' then '\r' got printed due to automargin stuff, then an insert char,
:then '0' to fill the blank spot - when the code was originally written
:there would not have been the first char '0' written.  There's an obvious hack
:in the code here, but for other reasons I don't want to do that, so I'll write
:a nice complex, hard-to-understand patch for it instead :-)

You won't have to wait a couple of hours.  I came up with another way to fix
this which is fairly easy to understand (damn!).  People will have to put up
with getting an extra two characters outputted in these situations (probably
increase the output to the terminal by around 0.001% during most sessions).
Hopefully won't matter that much, as the previous patches I sent decreased it
by slightly more.

This goes on top of patches from 820 & 831.

*** zle_refresh.c.~4~	Thu Mar 28 20:14:22 1996
--- zle_refresh.c	Thu Mar 28 21:22:50 1996
***************
*** 541,549 ****
  	    return;
  	}
  
!     /* if there's no right-prompt,
!        see whether we can insert or delete characters */
! 	if (ln || !put_rpmpt || !oput_rpmpt) {
  
  	/* deleting characters - see if we can find a match series that
  	   makes it cheaper to delete intermediate characters
--- 541,551 ----
  	    return;
  	}
  
!     /* inserting & deleting characters: we're allowed to if there's no
!        right-prompt, and we're not in the one situation where the screen
!        display isn't `guaranteed' to match ol */
! 	if ((ln || !put_rpmpt || !oput_rpmpt)
! 	    && !((ccs == 0) && hasam && ln)) {
  
  	/* deleting characters - see if we can find a match series that
  	   makes it cheaper to delete intermediate characters



-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"