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?
> > (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've found the source of the bug, and have a simple fix for it.
In function rl_redisplay (display.c) ~L1197, a space is inserted into the
invisible buffer to prevent a full-width character from being split
between lines. Such splittinig would not be possible without a lot of
work amending the code since, for example, inv_lbreaks (the array of line
breaking position in the invisible buffer) cannot have a value in the
middle of a character.
The comment near this code says, somewhat misleadingly, /* The space will
be removed in update_line() */. In fact, the space is _not_ removed from
the buffer, but instead from the image displayed on the screen.
As a result, the screen image and the buffer don't match each other.
Around step (v) of my bug reproducer, place the cursor over the "c" and
press <delete>. The "c" get visibly deleted from the screen, but the
preceding "b" actually gets deleted from the buffer. This is suboptimal.
The simplest fix for the bug would appear to be not to remove the space
from the displayed screen image. This way a full-width character at EOL
on the screen will be moved fully onto the next screen line when a
character is inserted before it, leaving a dummy space on the screen.
Here is a patch which achieves this:
diff --git a/lib/readline/display.c b/lib/readline/display.c
index 9aa8c7b5..5f8fb776 100644
--- a/lib/readline/display.c
+++ b/lib/readline/display.c
@@ -1197,7 +1197,8 @@ rl_redisplay (void)
if (_rl_screenwidth < lpos + wc_width)
for (i = lpos; i < _rl_screenwidth; i++)
{
- /* The space will be removed in update_line() */
+ /* Insert a dummy space, since a glyph cannot be split
+ between buffer lines */
invis_addc (&out, ' ', cur_face);
_rl_wrapped_multicolumn++;
CHECK_LPOS();
@@ -1810,16 +1811,9 @@ update_line (char *old, char *old_face, char *new, char
*new_face, int current_l
int oldbytes, newbytes;
size_t ret;
- /* This fixes only double-column characters, but if the wrapped
- character consumes more than three columns, spaces will be
- inserted in the string buffer. */
/* XXX remember that we are working on the invisible line right now;
we don't swap visible and invisible until just before rl_redisplay
returns */
- /* This will remove the extra placeholder space we added with
- _rl_wrapped_multicolumn */
- if (current_line < line_state_invisible->wbsize &&
line_state_invisible->wrapped_line[current_line] > 0)
- _rl_clear_to_eol (line_state_invisible->wrapped_line[current_line]);
/* 1. how many screen positions does first char in old consume? */
memset (&ps, 0, sizeof (mbstate_t));
It may well be that _rl_wrapped_multicolumn mechanism can be removed
entirely, though I haven't yet tested this.
Please consider incorporating the patch into readline at the next release
of readline and bash.
Thanks!
> 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).
