Created attachment 150097 [details] Screenshot STEPS TO REPRODUCE 1. openSUSE TW 2. Make Konsole's window small 3. zypper refresh && zypper dup 4. Press "v" to show the version changes 5. Maximize Konsole OBSERVED RESULT The text showing the version changes does not reflow. EXPECTED RESULT The text showing the version changes does reflow or is it a bug in zypper? SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220619 KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.2 Kernel Version: 5.18.4-1-default (64-bit) Graphics Platform: Wayland zypper 1.14.53
Probably zypper is doing explicit cursor movement to move to the next line in this case. Could you reproduce it in a script session and attach the resulting typescript file to see if that is the cause?
(In reply to ninjalj from comment #1) > Probably zypper is doing explicit cursor movement to move to the next line > in this case. Could you reproduce it in a script session and attach the > resulting typescript file to see if that is the cause? I am willing to try it out, but I am not quiet sure what you mean with script session. Could you please give me a more detailed step-by-step explanation what to do exactly? Thanks!
script(1) is a utility to record a shell session into a file. If you just run 'script' with no arguments, script(1) will launch your default shell while recording the input/output, as in the following transcript: lj@panoramix ~ $ script Script started, output log file is 'typescript'. lj@panoramix ~ $ printf '\e[31mHello world\e[0m\n' Hello world lj@panoramix ~ $ exit exit Script done. lj@panoramix ~ $ After exiting the inner shell spawned by script, the current working directory will contain a file named by default 'typescript' which will contain _all_ the input (including deleted characters and the backspaces that deleted them!) and output to the session. If your system's 'cat' command supports the '-v' switch, the real contents of the 'typescript' file can be viewed with it: lj@panoramix ~ $ cat -v typescript Script started on 2022-11-11 00:13:04+01:00 [TERM="xterm-256color" TTY="/dev/pts/1" COLUMNS="197" LINES="47"] ^[[?2004h^[]0;lj@panoramix:~^G^[[01;32mlj@panoramix^[[01;34m ~ $^[[00m exit^H^H^H^Hprintf '\e[31mHello world\e[0m\n'^M ^[[?2004l^M^[[31mHello world^[[0m^M ^[[?2004h^[]0;lj@panoramix:~^G^[[01;32mlj@panoramix^[[01;34m ~ $^[[00m exit^M ^[[?2004l^Mexit^M Script done on 2022-11-11 00:13:10+01:00 [COMMAND_EXIT_CODE="0"] lj@panoramix ~ $ On Linux, script(1) is typically included in the util-linux package, which will be typically be installed as part of the base system. script(1) comes from 3BSD, so it is widely available on Unix-like systems. A newer alternative would be asciinema, which allows creating nice screencasts. So, in summary, if you can run zypper inside a script(1) session reproducing the offending reflow behavior, and send the resulting 'typescript' file, it would allow us to determine what exactly is zypper sending to the terminal.
(In reply to ninjalj from comment #3) > (...) > So, in summary, if you can run zypper inside a script(1) session reproducing > the offending reflow behavior, and send the resulting 'typescript' file, it > would allow us to determine what exactly is zypper sending to the terminal. Thank you for this explanation! "Unfortunately", when I tried to reproduce it now with `script`, I noticed that the issue seems to be gone. :) I didn't expect this, otherwise I wouldn't have asked you for the long post. Nonetheless, it's still could turn out useful for future bugs. ;)