Bug 238073 - Konsole doesn't support resize ANSI escape codes anymore
Summary: Konsole doesn't support resize ANSI escape codes anymore
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 21.08.2
Platform: Compiled Sources All
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
: 185645 192699 198613 245746 272386 292452 (view as bug list)
Depends on:
Reported: 2010-05-18 20:16 UTC by P. Varet
Modified: 2021-10-11 11:16 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:

Konsole at 160x41 (132.46 KB, image/png)
2021-10-11 11:16 UTC, groot
Konsole text size 80x25 (58.03 KB, image/png)
2021-10-11 11:16 UTC, groot

Note You need to log in before you can comment on or make changes to this bug.
Description P. Varet 2010-05-18 20:16:04 UTC
Version:            (using KDE 4.4.3)
OS:                Linux
Installed from:    Ubuntu Packages

Konsole 3 used to support the ANSI escape sequences to resize the window. Konsole 4 no longer does.

This for instance causes some Vim plug-ins to completely screw up the display.

How to reproduce:
Open Konsole;
Resize to, say, 140x60 with the mouse;
Type: echo -ne "\033[8;25;80t"

Expected result:
The terminal window is resized to 80 columns and 25 lines.

Actual result:
1/ The display gets screwed up.
2/ The window isn't resized.

The screw up part actually looks like Konsole tries to apply the resize, but with the width and height inverted! I.e. it seems to expect "ESC[8;width;height;t" instead of the correct "ESC[8;height;width;t". So this at least should be easy to correct.

But the window should still resize itself accordingly.
Comment 1 Kurt Hindenburg 2010-06-02 04:30:44 UTC
Yes you are correct.  I remember implementing this in KDE3.  It looks like someone switched the method parameters.  Still it should resize it.
Comment 2 Jekyll Wu 2011-07-20 20:00:16 UTC
I think #245746 is actually the same as this one.  

And #185645 and #272386 are both the consequences of this bug. They all use 
':set columns=xxx' in the .vimrc, which triggers the resize ANSI escape code.
Comment 3 Jekyll Wu 2011-07-30 13:12:10 UTC
*** Bug 198613 has been marked as a duplicate of this bug. ***
Comment 4 Jekyll Wu 2011-07-30 14:16:04 UTC
*** Bug 272386 has been marked as a duplicate of this bug. ***
Comment 5 Jekyll Wu 2011-07-30 14:17:48 UTC
*** Bug 185645 has been marked as a duplicate of this bug. ***
Comment 6 Jekyll Wu 2011-08-03 15:18:26 UTC
*** Bug 245746 has been marked as a duplicate of this bug. ***
Comment 7 Alain BAECKEROOT 2011-08-03 19:37:15 UTC
the fix is given in http://bugs.kde.org/show_bug.cgi?id=245746  with references to the commit
Comment 8 Jekyll Wu 2011-08-03 19:55:51 UTC
(In reply to comment #7)

Yeah, I know.

That commit fixed the first problem in this report: reverted column and line argument when interpreting the ANSI escape code.

But the second problem is still not fixed: the window does not actually resize.
Comment 9 Jekyll Wu 2011-09-21 04:52:56 UTC
*** Bug 192699 has been marked as a duplicate of this bug. ***
Comment 10 Jekyll Wu 2012-01-26 11:46:33 UTC
*** Bug 292452 has been marked as a duplicate of this bug. ***
Comment 11 Jekyll Wu 2012-01-26 11:48:25 UTC
[copied from bug 292452]

I thought for some time that the Esc[8;<rows>;<cols>t escape sequence no longer
did anything.   However, I find that, for example "Esc[8;40;24t" makes the
terminal work as though it is 40x24 (lines wrap at column 40) although the
window size doesn't change.

setImageSize(), called when the escape sequence is received, calls
resizeImage() and which does all the work necessary to make the size as
specified but doesn't do anything at all to set the window size.

Interestingly, perhaps, when a new tab is created, setImageSize() is also
called to set the image size for the new tab.  In this case, of course, you
wouldn't expect the window size to change.

In KDE 3.5 there was a global configuration option to allow programs to change
the window size and setting this allows Esc[8;<cols>;<rows>t to resize the
window and seems to be otherwise ignored (I haven't checked in detail to see
what happens, sorry).

Fixing this would also allow those people who want an easy way to set specific
geometries to be satisfied: the menu entry would simply call the same function
that the escape sequence calls.
Comment 12 Kurt Hindenburg 2014-02-12 14:57:19 UTC
If anyone tries to look at this - https://git.reviewboard.kde.org/r/104038 might be helpful
Comment 13 Sandeep 2014-09-19 22:05:21 UTC
I think I may be facing the same problem:

When I resize konsole to a bigger size using the mouse,  the text displayed tries to wrap around to the next line, as if the konsole window is still small (i.e even if there is enough space for text to be displayed). However, the text doesn't wrap around correctly and is garbled instead (i.e displayed in previous line, with gaps between text).

For example, I initially open up a konsole window of size: 105x26 and then resize to 136x34. Then, I type in a long line of text (say a git commit command) and the text cuts off at the point where it would have if the window was still 105x26 and then continues on the previous line, and then jumps around, with long gaps, moving to the right, and then to even earlier lines.
Comment 14 groot 2021-10-11 11:15:30 UTC
[[ Since I can still reproduce with current releases, on a platform totally different from the OP, I'm updating platform and version values in the bug. ]]

This is easy to demonstrate with the new text-reflowing: you can see that the logical text-size is changed and text is reflowed (so the "terminal" idea is resized), but the window size (the "GUI around a terminal") does not change.

I'll attach two screenshots: konsole after / during resize using the window-manager handles, and then the "text-size-terminal" changed to 80x25. You can see right after the text-size-change codes, that the text is reflowed with the new text-size, but the graphical window size does not change. Opening a new tab, or switching tabs, triggers a *new* resize and reflow event, and the text-size goes back to matching the GUI-size (e.g. it reflows back to the "size1" screenshot).

With all that said, though, it's not clear to me if resizing the **GUI** part to match the **text** size makes sense: what about other tabs in konsole? They would end up being resized as well, by an ANSI code emitted in one tab! Or consider tabs with different profiles that have different font sizes: resize to 80x25 means different things (in terms of GUI-size, and so in terms of text-size for other tabs) in different tabs.

I would consider closing this as "WONTFIX", because a tabbed, paned, multi-layout multi-themed terminal widget doesn't have a good model for "resize the GUI" based on text events.
Comment 15 groot 2021-10-11 11:16:18 UTC
Created attachment 142329 [details]
Konsole at 160x41
Comment 16 groot 2021-10-11 11:16:36 UTC
Created attachment 142330 [details]
Konsole text size 80x25