ANSI escape sequences not handled correctly

[multiplexd]

I have observed some strange behaviour from lxterminal when running a mksh shell script, uhr (included in the Debian package under /usr/share/doc/mksh/examples and available from MirBSD CVS here), under lxterminal. This script renders an analogue clock face using ANSI escape sequences and unicode characters.

The expected behaviour is that it will render the boundary of the clock face in non-bold white font (by default rendered as light grey) and the background in black. When the script is started and when the window size is changed, the script recalculates some internal values and displays a progress bar, which is rendered with yellow text on a blue background. This expected behaviour can be observed when I run the script under xterm, gnome-terminal or in tmux under lxterminal.

However, the observed behaviour when the script is run under lxterminal directly (i.e. without tmux) is that after the script has finished loading, the background colour of the terminal is set to blue and the boundary of the clock is yellow, like the progress bar. It should also be noted that the hands of the clock are rendered normally (light grey text and black background) and that the blue background is erased by hands being rendered over it.

I have contacted the maintainer of mksh (and the author of this script) about this behaviour, and their suspicion is that lxterminal is either improperly handling some of the escape sequences in use by the script or improperly reporting the window size in some manner.

This behaviour has been observed with commit hash 1e9f2d4 compiled against GTK+2 on Debian Stretch and with version 0.3.1 compiled against both GTK+2 and GTK+3 on OpenBSD.

[egmontkob]

This was fixed in VTE 0.40 (gtk3): bug, commit.

[multiplexd]

Indeed it has been - I retested with a GTK+3 version of lxterminal and the behaviour was as expected (that is, no buggy behaviour was observed). (I'm unwilling to upgrade to GTK+3 on some of my systems, so I'll work around the bug in the older version of vte; I took a look at the patch which was linked, but it's too complicated to backport by the looks of it)

[egmontkob]

Are you personally affected by this bug, e.g. do you use uhr or a similar app that is affected by this bug on a regular basis?

gtk2-based vte-0.28 has been abandoned for 6-7 years now. If you look at VTE's changes between that version and current HEAD, you'll see about a thousand nontrivial (e.g. not translation, version bump etc.) commits, pointing to about 300 different bugs and feature requests. I'd guess at least 50 or so out of these bugs are similar to the current one in the sense that you could easily find a use case at least as important as uhr where the behavior is broken.

It's a tough question what could be done to remain at gtk2 (for low memory fingerprint etc.) and in the mean time have a better terminal emulation.

While gtk3 might be a resource hog compared to gtk2, I'm not sure if the same holds in combination with VTE. VTE has received lots of resource improments, e.g. a 10x speedup, significantly smaller number of file descriptors used for storing the scrollback (it used to be up to 12 files per terminal, now it's up to 3), 3-4x smaller disk usage (the scrollback data is now compressed before written to disk). These, at least to some extent, mitigate the extra resources taken by gtk3.

Plus there was a significant privacy/security fix (scrollback is also encrypted now, not stored as plain text), data corruption fixes, tons and tons of emulation fixes and so on.

If you backport this one fix to vte-0.28, it might be a noticeable improvement for your use case in particular, but probably won't significantly improve the situation in general. In order to do that, one would have to fork vte-0.28 and backport at least about a hundred or so fixes from git. The speedup and the incorrect handling of bracketed paste mode are the two most frequently requested ones in distribution's bugtrackers. It's probably a lot of work, especially since each and every skipped (non-backported) change potentially makes subsequent changes harder to backport.

Another approach could be for someone to take current VTE, and change it from gtk3 to gtk2. I've no clue how much work it could be, probably a lot.

The best solution (in the long run), in case a gtk2 port is really required, would be to finally implement the model/view split, so that VTE would be split into two libraries: a lower component doing headless emulation, and an upper one displaying it as a gtk3 widget. In that case, only the upper one would need to be ported/rewritten for gtk2. Again, it's an enormous amont of work.

Or just give up and let those who wish to have a better emulation give up on gtk2 and pay the price of gtk3's overhead. This is sure a tough call for the project, or anyone distributing it. Just for the record, Debian and Ubuntu are about to drop vte-0.28 (targeted at Buster and Bionic, respectively) and have just recently switched lxterminal to use gtk3.

[multiplexd]

I don't use any applications which trigger this bug on a regular basis. Most of the time I use lxterminal as bundled by the distro, although there was a feature added a month or two back which I wanted which prompted me to compile from source on a few systems.

GTK+3 is pulled in on a lot of my systems anyway due to applications such as Firefox. I really only have one system (an old iBook G4 running OpenBSD) where GTK+3 is a bit of an annoyance, as I currently have no other applications installed which use it and lxterminal compiled against GTK+3 consumes significantly more resources than when compiled against GTK+2.

Given that this issue only impacts my very specific use case, my course of action will be to move to GTK+3 lxterminal when the Linux distros I use upgrade and on the resource constrained system I will continue to use GTK+2 lxterminal and work around the VTE bugs.

[egmontkob]

Yeah, I guess lxterminal's gtk2 / vte-0.28 usage will just slowly (really slowly) fade out.

[medicalwei]

In Debian the vte-0.28 is deprecated and we are forced to move to GTK+3 build.

I will check things out later. On Sat, 24 Feb 2018 at 23:58 egmontkob notifications@github.com wrote:

Yeah, I guess lxterminal's gtk2 / vte-0.28 usage will just slowly (really slowly) fade out.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lxde/lxterminal/issues/44#issuecomment-368238037, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEi8Z_3Ys-80MnoByuWoG9nYP1xgjDVks5tYDG2gaJpZM4Q98U_ .