On Fri, Apr 17, 2026 at 15:27:48 -0400, Chet Ramey wrote:
> On 4/17/26 9:37 AM, Alan Mackenzie wrote:
> > Hello, readline.

> > I'm using readline 8.3_p3 and bash 5.3.9(1)-release on Linux 6.18.18,
> > with an up-to-date Gentoo GNU/Linux.

> > Background: I am trying to enhance the Linux virtual terminal to handle
> > full-width glyphs.

> > A problem I encountered with (probably) readline is reproducible on a
> > release kernel:

> > To reproduce:
> > (i) At the bash command line, type (with auto-repeat) any character
> >    almost to the end of the screen line (240 columns in my case).
> > (ii) Insert a full width character, for example U+2614 (UMBRELLA WITH
> >    RAIN DROPS) by holding <AltGr> and typing "2614" on the numeric keypad.
> >    This will be displayed as an inverse-video question mark followed by a
> >    space.

> You're saying the terminal can't display the character yet?

This is the case, yes.

> > (iii) Type "abc" directly after this full width character.  "c" should be
> >    the last character on the line.
> > (iv) Type <Ctrl-a>, and type further characters or press <Delete> until
> >    the U+2614's ? is at the right edge of the screen.  The "abc" will be
> >    on a continuation line.

> > (v) Type <Ctrl-e> to go to EOL.  There is a spurious space between the
> >    "c" and the cursor.  This looks like a bug.

> I can't reproduce this using macOS Terminal, which correctly displays the
> Unicode character. I imagine your terminal will, too, when you're
> finished.

I see the bug only when a full-width character is straddling a line
break.  Is the UMBRELLA WITH RAIN DROPS a full-width character on your
Mac?  Another character I've used for this is U+ff11, FULLWIDTH DIGIT
ONE.

>From (v), when I attempt to type in a character with cursor on the
spurious space, it inserts itself _before_ the preceding character "c",
though this only becomes visible on deleting stuff near BOL to move the
full-width char away from the line break.

In my development version of the kernel, I see these things happening
also with the full width characters which it can display.

With a full-width character at the start of the continuation line,
deleting a char near BOL moves it, leaving it covering the line break,
but also wrongly leaves a ghost copy of the right-hand half-glyph in its
original position.  This may be happening in kernel 6.18.18 too, though I
can't be sure.  I can't honestly exclude my own code as causing this
particular bug.

Somehow there seems a misunderstanding between readline and the kernel on
how to handle full-width glyphs straddling line breaks.

> Chet
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/

-- 
Alan Mackenzie (Nuremberg, Germany).

Reply via email to