GNU bug report logs - #43396
27.1; Customized "cursor" face has no effect in daemon mode

Previous Next

Package: emacs;

Reported by: Teemu Likonen <tlikonen <at> iki.fi>

Date: Mon, 14 Sep 2020 13:24:02 UTC

Severity: normal

Found in version 27.1

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Teemu Likonen <tlikonen <at> iki.fi>
Cc: 43396 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: bug#43396: 27.1; Customized "cursor" face has no effect in daemon mode
Date: Tue, 29 Jun 2021 15:21:45 +0300
> From: Teemu Likonen <tlikonen <at> iki.fi>
> Cc: larsi <at> gnus.org, 43396 <at> debbugs.gnu.org
> Date: Mon, 28 Jun 2021 21:47:24 +0300
> 
> > And if, instead of custom-set-faces, you use
> >
> >   (add-to-list 'default-frame-alist '(cursor-color . #0f0))
> 
> That works -- using the string "#0f0". The client session now has a
> cursor with background color "#0f0".
> 
> I sent my original report about "Customized 'cursor' face" after reading
> Emacs reference manual section "(emacs) Cursor Display". It says:
> 
>     On a graphical display, many more properties of the text cursor can be
>     altered. To customize its color, change the ‘:background’ attribute of
>     the face named ‘cursor’ (*note Face Customization::).
> 
> It seems to me that it's a bug if customizing cursor face doesn't work.

But it does work, as you have just demonstrated.  The color of the
'cursor' face does change -- except that it changes to a color that is
the closest approximation on a text-mode frame to the color you
requested.  That's because the frame that is selected when the daemon
applies the customizations via custom-set-faces is the daemon frame,
which is not a GUI frame.

> It would be odd to define that a feature, so that in normal session we
> customize cursor face's background and in daemon we must use
> default-frame-alist variable instead.

custom-set-faces recalculates the face attributes and then applies
those attributes to the frame(s).  I don't know how to defer that
recalculation to some future time, when a GUI frame is available,
without hurting more important use cases with face customizations,
which generally need such an immediate recalculation of attributes.

Yes, we have a design bug here (and in some other places):
customizations that need GUI features don't work well when invoked at
startup time in daemon sessions.  If someone knows how to fix
custom-set-faces so that the face is re-evaluated when the first GUI
frame is created, patches and/or ideas are welcome.  Failing that, I
thought I was doing well by helping you resolve this issue in your
init files...




This bug report was last modified 4 years and 13 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.