konsole inverts $COLUMNS and $LINES when resized from vi

[Alain Baeckeroot]

Binary package hint: kdebase

This simple command does a resize from vi (enlarge by 3 columns)

$ resize; vi /tmp/a +"set co=$(($COLUMNS + 3))" +:q; echo; resize

We see that Konsole is totaly messed-up, due to the fact that it inverts the number of lines and the number of columns.

To have a normal display agin, it is enougth to resize the windo with the mouse, then correct values are taken into account (and set as env vars).

-------------------

$ lsb_release -rd
Description: Ubuntu 9.10
Release: 9.10

$ konsole --version
Qt : 4.5.2
KDE : 4.3.2 (KDE 4.3.2)
Konsole : 2.3.2

------------------

ProblemType: Bug
Architecture: i386
Date: Sun Jul 25 15:05:06 2010
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: fglrx
Package: konsole 4:4.3.2-0ubuntu3
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-22.60-generic
SourcePackage: kdebase
Uname: Linux 2.6.31-22-generic i686

[Sundance (sundance-greydragon)]

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.

[Kurt Hindenburg (kurt-hindenburg)]

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

[Alain Baeckeroot (alain-baeckeroot)]

Doing the same command line in gnome-terminal 2.28 (karmic) just works fine, the terminal is correctly resized when vi ask for it.

Just no affect in xterm, or xfce4-terminal.

[adaptee (adaptee)]

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.

[adaptee (adaptee)]

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

[adaptee (adaptee)]

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

[adaptee (adaptee)]

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

[adaptee (adaptee)]

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

[Alain Baeckeroot (alain-baeckeroot)]

Why invalid ?

This bug has a patch upstream and is not yet included in ubuntu !

[Alain Baeckeroot (alain-baeckeroot)]

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

[Alain Baeckeroot (alain-baeckeroot)]

https://bugs.kde.org/show_bug.cgi?id=223302

[Alain Baeckeroot (alain-baeckeroot)]

https://bugs.kde.org/show_bug.cgi?id=238073 is the correct one, 223302 is a mistake in url

[adaptee (adaptee)]

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

[Harald Sitter (apachelogger)]

Closing in favor of upstream report as this ultimately needs to be resolved in Konsole itself rather than Kubuntu.

[Alain Baeckeroot (alain-baeckeroot)]

This bug is VALID and has a patch upstream

So please, don't mark it as invalid, when one can just cherry pick a one line patch to fix it :-).

[Alain Baeckeroot (alain-baeckeroot)]

maybe you can mark it as "Won't fix" , it would be clearer.

[adaptee (adaptee)]

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

[adaptee (adaptee)]

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

[adaptee (adaptee)]

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

[Kurt Hindenburg (kurt-hindenburg)]

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

[Harald Sitter (apachelogger)]

Our bug triage policy mandates that upstream bugs be handled upstream, so for this particular bug it is invalid for us, it's not invalid in general.

[sandeep (sandy-8925)]

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.

[Adriaan de Groot (groot)]

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

[Adriaan de Groot (groot)]

Created attachment 142329
Konsole at 160x41

[Adriaan de Groot (groot)]

Created attachment 142330
Konsole text size 80x25