Re: a double-width character can transgress to the next row

[Thomas Dickey]

On Wed, Apr 15, 2020 at 12:18:46PM +0200, Benno Schulenberg wrote:
> 
> Op 15-04-2020 om 01:56 schreef Thomas Dickey:
> >> Now, going from dump number 4 to 5, the screen has narrowed again and
> >> all rows lose an \s at the end -- except for row 21 and 25: they don't
> >> lose the \u307f and \u7d0d at the end!  [...]
> >>
> >> So, it seems something goes wrong when ncurses shrinks a window: a
> >> double-width character that overshoots the total width of the window
> >> does not get replaced with a space (or something) but is left alone.
> > 
> > It's more complicated than that: some of the characters are "known"
> > to be "fullwidth" (2 cells) and some are not.  It's not clear in the
> > dump which are (so counting characters can be misleading).
> 
> Looking at all the characters in the ^R line and at
> 
>     http://unicode.org/reports/tr11-2/
> 
> all characters that are not space (and not ^ or R) are either in the
> category Wide or in the category Fullwidth.  So most likely wcwidth()
> will give 2 for all of those -- it ought to, otherwise nano wouldn't
> draw things correctly when it redraws the screen.

I wasn't certain, so I verified that by extracting the codes from
the PutAttrChar lines in the trace and using a test-program for
xterm's wcwidth.  They're all 2, as you indicated :-)

-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature