GNU bug report logs -
#32072
27.0.50; clear-face-cache in an X frame breaks tty colors
Previous Next
Reported by: Istvan Marko <mi-ebugs <at> kismala.com>
Date: Fri, 6 Jul 2018 21:32:02 UTC
Severity: normal
Tags: confirmed
Found in versions 26.1, 27.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#32072: 27.0.50; clear-face-cache in an X frame breaks tty colors
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 32072 <at> debbugs.gnu.org.
--
32072: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32072
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> From: Istvan Marko <mi-ebugs <at> kismala.com>
> Cc: npostavs <at> gmail.com, 32072 <at> debbugs.gnu.org
> Date: Thu, 19 Jul 2018 11:18:53 -0700
>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Thanks, pushed to emacs-26 branch.
>
> emacs-26 looks good here too now, thanks!
Thanks, I'm therefore closing the bug.
> The fix will be needed in master too, right? It was broken in both 26
> and master.
The fix will be merged to master soon enough.
[Message part 3 (message/rfc822, inline)]
When an Emacs session has both an X11 frame and a tty frame on a 256
color capable terminal calling (clear-face-cache) in the X11 frame
results in the colors getting messed up in the existing tty frame. Newly
created tty frames are OK. Running (clear-face-cache) in the tty frame
fixes the affected frame.
Non-256-color tty frames don't seem to be affected.
I am running into this regularly because I often have Emacs sessions
with both X and tty frames, switching back and forth between them.
Sometimes when I switch back to the tty frame I find that the colors are
messed up. I suspect that this is triggered by redisplay_internal
periodically calling clear-face-cache.
I am able to reproduce this with the current master and emacs-26 using
the following steps:
Start Emacs in X11 mode and start Emacs server:
emacs -Q
M-x server-start
Then in a 256 color terminal with TERM=xterm-256color or similar:
emacsclient -t
Then switch back to the X frame and evaluate:
M-: (clear-face-cache) RET
This immediately corrupts the colors of the tty frame. Not sure if all
faces are affected but the mode-line face for example always turns black
or green for me so it's very obvious.
Running (clear-face-cache) in the tty frame restores the correct tty
faces. The X frame is not affected.
Looking at the git log e573d08ef15f0431ad8289b4242c49826f20efb6 ("Make
face realization be more frame-specific") seems like a potential suspect
but unfortunately I am no longer able to build that revision on my Linux
hosts (temacs loading gobbles up all available memory for some reason)
In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu)
of 2018-07-06 built on somehost
Repository revision: 3bbd4ffc68bcc2b3e003a2179a508b82055ad770
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
System Description: Linux
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item
Configured using:
'configure --without-x-toolkit --without-gpm --without-rsvg
--without-gconf --without-xim --without-gsettings
--with-file-notification=inotify --without-lcms2'
Configured features:
XPM JPEG TIFF GIF PNG IMAGEMAGICK SOUND DBUS NOTIFY ACL GNUTLS LIBXML2
FREETYPE XFT ZLIB OLDXMENU X11 THREADS
Important settings:
value of $LANG: C
locale-coding-system: nil
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
easymenu mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting font-render-setting x multi-tty make-network-process
emacs)
Memory information:
((conses 16 95891 6947)
(symbols 48 20447 1)
(miscs 40 40 85)
(strings 32 29147 1543)
(string-bytes 1 759273)
(vectors 16 15030)
(vector-slots 8 508852 6900)
(floats 8 52 65)
(intervals 56 243 142)
(buffers 992 12))
This bug report was last modified 7 years and 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.