Re: [PATCH] Merge of readline 4.3 to mainline

[Michael Elizabeth Chastain <mec@shout.net>]

> Do you have anything strange in your .inputrc?  I skimmed through the
> readline docs and didn't see any variables that would produce this
> behavior, but I thought I'd ask just in case...

I don't have a .inputrc file at all.  And I'm sure I don't have a
different one than I had last week.

If other people have nice-looking gdb.log files, and I have a
funny-looking gdb.log file, that implies that readline is
conditionally acting on something that I have that other people
don't.  So my theory is that we just find that thing and hard-wire
it to "always print the simple way".  I guess I'm in the best
position to find the magic logic because I'm the guy with the
anomolous output.

I'm tracing through readline/display.c:rl_redisplay(), and I see
that it's got different code for HANDLE_MULTIBYTE.  This code is
definitely turned on for my system.  One of the big changes in
Red Hat Linux 8 is unicode support in the console.

There are two ways to check this: look in the build log for the
place that readline gets configured.  Mine says:

  checking for tgetent in -ltermcap... yes
  checking which library has the termcap functions... using libtermcap
  checking for wctype.h... yes
  checking for wchar.h... yes
  checking for langinfo.h... yes
  checking for mbsrtowcs... yes
  checking for wcwidth... yes
  checking for mbstate_t... yes

If all of wctype.h, wchar.h, and mbsrtowcs are turned on,
then HAVE_MULTIBYTE is defined, and rl_redisplay has different
logic.

You can also start gdb, break on rl_redisplay, and check for a local
variables named "wc" and "wc_bytes".  If they exist, then HAVE_MULTIBYTE
was configured in.

The old readline 4.1 does not have this HAVE_MULTIBYTE code at all.
I suspect that's why it worked on my system.

More source diving to follow ... at the moment I am just suspicious
of HAVE_MULTIBYTE, it could be something else.

Michael C