Re: Fun redraw issue with double-width characters

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 24 October 2010 20:12, Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx> wrote:
> On Sun, 24 Oct 2010 14:11:08 +0200
> Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>> I got a random thought, "what if i enter five doublewidth characters,
>> then go back to the start and enter a bunch of spaces". Turns out
>> doing that causes the line to clear and cursor to move up one line.
>> Doesn't happen with four or less.
>
> I think that may depend on what you're inserting: if you're inserting
> stuff such that the character you're inserting changes the line near
> the start, it may happen early.   But this may be a wild goose chase.
>
>> Long story short, it happens only if
>> ich1 is defined in the terminfo for the current $TERM, which it
>> happens to be for rxvt-unicode, but also for rxvt. It doesn't matter
>> if you're using xterm or rxvt or urxvt, just set TERM=rxvt, enter five
>> ã and go back to the start and hold down space. I don't really know
>> where to begin debugging this.
>
> Actually, there's only one use of insert in the entire source, which is
> in a quite short chunk in zle_refresh.c, so localising it was the easy
> bit.

Well, easy if you know ich1 means TCINS :).

> After staring enough I think I've worked out what's going on, but you
> might want to stare at it, too.  Much of this is reformatting for
> clarity, the important bit is near the end where I've moved an extra
> chunk inside an #ifdef MULTIBYTE_SUPPORT with a new comment.

I stared at it for a while, but nothing of interest happened. I did
test it though, and it works.


I am asking this only out of curiosity, how come updates on the first
line are done like this
write(10, " \343\201\276\343\201\276\343\201\276\343\201\276\343\201\276\33[10D",
21) = 21
while updates on the second line (ie after wrapping everything) are
done shorter, like this
write(10, "\33[@ \33[10C \33[11D", 15)  = 15
? (when inserting spaces in front of our five friends)

Also noticed this didn't seem to be documented. I usually have special
set to bold, but when looking at strace output in the first mail i did
unset zle_highlight and noticed this. (what i should have done was
zle_highlight=(none) ).

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 92b5f20..b9abaac 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -2350,6 +2350,11 @@ Not all systems support this: for it to work,
the system's representation of
 wide characters must be code values from the Universal Character Set,
 as defined by IS0 10646 (also known as Unicode).
 )
+item(Wrapped double-width characters)(
+When a double-width character appears in the final column of a line, it
+is instead shown on the next line. The empty space left in the original
+position is highlighted as a special character.
+)
 enditem()

 If tt(zle_highlight) is not set or no value applies to a particular

-- 
Mikael Magnusson