After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 672210 - Bad handling of initc (initialize_color)
Bad handling of initc (initialize_color)
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.29.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
[fixed-0-36][needed-next][commit:a5fe...
Depends on:
Blocks:
 
 
Reported: 2012-03-16 07:49 UTC by Keith Winstein
Modified: 2014-04-06 18:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Demonstrates two initc bugs (897 bytes, text/plain)
2012-03-16 07:49 UTC, Keith Winstein
  Details
Fix for (1) (812 bytes, patch)
2014-01-08 22:27 UTC, Egmont Koblinger
committed Details | Review

Description Keith Winstein 2012-03-16 07:49:07 UTC
Created attachment 209903 [details]
Demonstrates two initc bugs

VTE seems to have two bugs regarding the initc escape sequence.

(1) Changes to the system colors (<16) can never be reset, even by an RIS (ESC c), or by the user choosing "Reset and Clear" in e.g. gnome-terminal. (Changes to colors >= 16 work properly.)

(2) initc is supposed to change the appearance of all colors on the screen. But VTE does not alter the display of the terminal when receiving an initc -- it only affects new output after the initc.

The attached Perl script demonstrates both bugs when run under gnome-terminal vs. under xterm.
Comment 1 Christian Persch 2013-09-16 18:03:12 UTC
(2) should be fixed already (bug 702415).
Comment 2 Egmont Koblinger 2014-01-08 22:27:22 UTC
Created attachment 265793 [details] [review]
Fix for (1)
Comment 3 Egmont Koblinger 2014-01-08 22:32:59 UTC
The patch is ugly, but I'm too lazy to clean up the initialization in spirit of bug 705985.
Comment 4 Egmont Koblinger 2014-01-10 01:46:59 UTC
I figured out memcpy is not that ugly after all :)

Fixed in vte-0-36, keeping the bug open for vte-next.