Large command in bash history breaks rendering

[Flightkick]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -flto=auto -g  -D_GNU_SOURCE 
-DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-switch-enum 
-Wno-unused-variable -Wno-unused-parameter -Wno-parentheses -ftree-loop-linear 
-pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0 
-DDEFAULT_LOADABLE_BUILTINS_PATH='/usr/lib64/bash'
uname output: Linux hephaestus 6.7.2-1-default #1 SMP PREEMPT_DYNAMIC Fri Jan 
26 11:01:28 UTC 2024 (a52bf76) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu

Bash Version: 5.2
Patch Level: 26
Release Status: release

Description:
        Let me preface this bug report by stating that I am not entirely sure 
as to whether this issue is caused by bash, or by another component related to 
the bash ecosystem. I hope that someone more knowledgeable in this area may 
help to direct this report to the right maintainers if this is not the correct 
place.

        The issue I'm experiencing occurs when a large command (one which 
exceeds the terminal size x*y, with wrapping enabled instead of horizontal 
paging), is present on the bash history. If the user then cycles through the 
history or lands on that command by Ctrl+R search, the terminal then fails to 
render the prompt correctly when cycling to another (shorter) entry. Instead 
showing blank spaces up until the cursor position. With real-life cases, 
navigation through history and moving the caret results in more glitchy 
representation of the selected command. To work around this issue, one could 
hit Ctrl+L in order to clear the terminal and re-render the prompt. But it's 
ultimately not a great experience when working with such large commands present 
in the history.

        I managed to reproduce the behavior in freshly installed VM's on both 
OpenSUSE Tumbleweed KDE with Konsole and Fedora GNOME with GNOME Terminal. 
However, strangely enough I was not able to reproduce the behavior on either 
ubuntu or opensuse/tumbleweed Docker containers running on my OpenSUSE 
Tumbleweed host. I suspect that xterm or GNU Readline could be the differential 
factor but I'm not familiar enough with the architecture to make any decisive 
statements on that.

        I *think* I was able to reproduce this behavior in both sh, bash and 
fish. Although I am not sure if my tests on these shells were completely valid, 
as I may not have been able to spawn a clean/standalone shell without inherited 
environment variables or may have experienced influence from spawning a 
subshell.

        I originally opened a discussion on the OpenSUSE Tumbleweed forums, 
which can be found here: 
https://forums.opensuse.org/t/large-command-in-bash-history-breaks-rendering/172299

        My host system info:
          Operating System: openSUSE Tumbleweed 20240206
          KDE Plasma Version: 5.27.10
          KDE Frameworks Version: 5.114.0
          Qt Version: 5.15.12
          Kernel Version: 6.7.2-1-default (64-bit)
          Graphics Platform: Wayland

Repeat-By:
        - Open the terminal
        - Execute a very large dummy command (which should be larger than the 
terminal size x*y, make sure wrapping is enabled instead of paging):
          `aaaaaaaaaaaaa` (... repeat a's until the size exceeds your visible 
area.)
        - Run another command: `echo test`
        - Press the UP arrow twice
        - You should now have the aaa command visible. Notice that the cursor 
is located at the end of the command. So the PS1 string/prompt shouldn’t be in 
the visible area right now. (so far so good)
        - Press the DOWN arrow once
        - Notice that the cursor is located at the end of where it would be if 
PS1 + ‘echo test’ would be rendered. But instead there’s only whitespace before 
the cursor.
        - Scroll up slightly and notice that ‘echo test’ has been appended to 
the aaa characters.
        - Press ENTER and notice that the echo command is correctly executed. 
(Proves that this is issue is related to rendering).