[PATCH] Readline not being able to handle long lines

[Mihail Konev]

Configuration Information:
OS: Happens both under Linux and MSYS2 (i.e. Cygwin), both 32 and 64 bit
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' \
                     -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' 
-DCONF_VENDOR='unknown' \
                     -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' 
-DSHELL \
                     -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g -O2
          Note on CFLAGS: -DNO_MULTIBYTE_SUPPORT=1 helps.
          But then I cannot use anything non-ASCII :)
uname output: Irrelevant (see OS)
Machine Type: Irrelevant (see OS)

Bash Version: 3.2
Patch Level: 0
Release Status: release

Description:
        Readline is unable to handle long lines.
        This was introduced in bash 3.2.0.
        Didn't check the readline, through.
        Maybe just updating would help.

Repeat-By:
        git checkout 0628567a28f3510f506ae46cb9b24b73a6d2dc5d
        git clean -dfx
        ./configure --enable-multibyte
        make
        ./bash
        export PS1='[bash]$ '
        #
        # Now begin typing. On 40-th character, typing Home
        # would no longer succeed, instead moving cursor somewhere in
        # the middle of the line.
        # And then you cannot do End either.
        # This is verified to be pure displaying issue - you can use
        # editing keys and they would affect the command line.
        # But display would be just-broken.
        #
        export PS1='[bash123]$ '
        #
        # Now it would happen on 53-th character
        #
        export PS1='[bash1234567890]$ '
        #
        # Now it would happen on 65-th character
        #

Fix:
        Maintainer side:
        1. Please Use Git Submodules For Things Like lib/readline.
           'git bisect' would then result in 10-20 lines diff, not 40000
           lines one with *unrelated* changes.
        2. Please Use Git Commits For Every Small Self-Contained Change.
        3. For Versioning Releases, Please Use Git Tags.
           Git Branches Are Also Ok.

        It is **pure luck** I was able to do that (thanks to change
        being on top of the file).

        Even after I constrained the diff to lib/readline, it still
        constituted 2000 lines.

        Unfixedness of *this* for **ELEVEN** years is a **shame** for bash as a
        program with which a **lot** of people interact *every* day.

        The same also applies for Readline.

        To clarify: ANY git user has very little respect to both
        projects for how do they break 'git bisect'.

        Oh, and one more: I just found the 'devel' branch.

        Big thanks for it NOT being the master !!!!!!!

        And still, git bisect would fail very short with this
        "development" branch.

        Also, "git commit" is really meant to have a *description*, not
        a *revision* or *date*; for versioning, Git Tags are meant.

        I am happy bash do not contain any more serious bugs.
        Also, from now on, I would have troubles capitalizing the
        program's name.

---
 lib/readline/display.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/readline/display.c b/lib/readline/display.c
index 47ff06159747..690f9f9b1ef3 100644
--- a/lib/readline/display.c
+++ b/lib/readline/display.c
@@ -78,7 +78,11 @@ static int inv_lbsize, vis_lbsize;
 /* Heuristic used to decide whether it is faster to move from CUR to NEW
    by backing up or outputting a carriage return and moving forward.  CUR
    and NEW are either both buffer positions or absolute screen positions. */
-#define CR_FASTER(new, cur) (((new) + 1) < ((cur) - (new)))
+#if defined (HANDLE_MULTIBYTE)
+#  define CR_FASTER(new, cur) 0
+#else
+#  define CR_FASTER(new, cur) (((new) + 1) < ((cur) - (new)))
+#endif
 
 /* _rl_last_c_pos is an absolute cursor position in multibyte locales and a
    buffer index in others.  This macro is used when deciding whether the
-- 
2.9.2