GNU bug report logs - #14635
24.3.50; Regression in Customize: no revert changes

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sun, 16 Jun 2013 09:19:01 UTC

Severity: normal

Tags: confirmed

Found in versions 25.1, 24.3.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14635 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: bug#14635: 24.3.50; Regression in Customize: no revert changes
Date: Fri, 30 Oct 2020 11:03:39 -0300
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>> Date: Fri, 30 Oct 2020 10:35:33 -0300
>> Cc: 14635 <at> debbugs.gnu.org
>>
>> For the default face, face-spec-reset-face only sets all attributes to
>> default values if (display-graphic-p frame) returns nil.  So on a
>> graphical display, it never resets :family, :foundry, :width, :height,
>> :weight, :slant, :foreground and :background.
>
> That's because on GUI frames there's no real default for these
> attributes (unlike on a TTY where we inherit the colors of the
> terminal).  So we simply _cannot_ reset the attributes like that,
> because there's nothing to reset to.  E.g., unspecified-fg only has
> meaning on a TTY frame.

I see, thanks.

>> What would be the right way for face-spec-reset-face to reset all the
>> attributes of the default face to the default values, in a graphic
>> display?
>
> Doesn't customizing a face record the original value in some property
> of the face symbol?  If so, reverting the customizations should use
> those recorded values, I think.

AFAICT, it doesn't right now.  I followed the recipe I gave, and then:
(symbol-plist 'default)
The relevant properties I see are:
* face-defface-spec ==> ((t nil))
which won't take us anywhere.
* theme-face, which has the customized value for the user theme, and
* customized-face, which again, has the customized value.

But I see no immediate reason why we shouldn't start doing it, if you
think it is OK to use that to solve this issue.  My only questions are
if it would be best to do it in Customize or in faces.el, and if we
should only special case the default face.
[Message part 2 (text/html, inline)]

This bug report was last modified 3 years and 165 days ago.

Previous Next


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