emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#32072: closed (27.0.50; clear-face-cache in an X f


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#32072: closed (27.0.50; clear-face-cache in an X frame breaks tty colors)
Date: Thu, 19 Jul 2018 18:25:02 +0000

Your message dated Thu, 19 Jul 2018 21:23:57 +0300
with message-id <address@hidden>
and subject line Re: bug#32072: 27.0.50; clear-face-cache in an X frame breaks 
tty colors
has caused the debbugs.gnu.org bug report #32072,
regarding 27.0.50; clear-face-cache in an X frame breaks tty colors
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
32072: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32072
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 27.0.50; clear-face-cache in an X frame breaks tty colors Date: Fri, 06 Jul 2018 10:18:39 -0700
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))



--- End Message ---
--- Begin Message --- Subject: Re: bug#32072: 27.0.50; clear-face-cache in an X frame breaks tty colors Date: Thu, 19 Jul 2018 21:23:57 +0300
> From: Istvan Marko <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Thu, 19 Jul 2018 11:18:53 -0700
> 
> 
> Eli Zaretskii <address@hidden> 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.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]