Bug 238073

Yes you are correct.  I remember implementing this in KDE3.  It looks like someone switched the method parameters.  Still it should resize it.

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.

*** Bug 198613 has been marked as a duplicate of this bug. ***

*** Bug 272386 has been marked as a duplicate of this bug. ***

*** Bug 185645 has been marked as a duplicate of this bug. ***

*** Bug 245746 has been marked as a duplicate of this bug. ***

the fix is given in http://bugs.kde.org/show_bug.cgi?id=245746  with references to the commit

(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.

*** Bug 192699 has been marked as a duplicate of this bug. ***

*** Bug 292452 has been marked as a duplicate of this bug. ***

[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.

If anyone tries to look at this - https://git.reviewboard.kde.org/r/104038 might be helpful

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.

[[ 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.

Created attachment 142329 [details]
Konsole at 160x41

Created attachment 142330 [details]
Konsole text size 80x25