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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14635 in the body.
You can then email your comments to 14635 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Regression in Customize: no revert changes
Date: Sun, 16 Jun 2013 02:18:36 -0700 (PDT)

emacs -Q
M-x customize-face default

Make some changes.  Then choose Set for current session from the State
button.

Then try to revert your changes using button `Revert...' > `Revert this
session's customizations'.  There is no effect: no change in the
appearance of the buffer.  And trying to revert or undo edits using the
State button is also impossible: `Revert this session's customizations'
is now dimmed out.  This is with emacs -Q.

The change of state to revert to no changes seems completely broken (a
regression).



In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-06-13 on ODIEONE
Bzr revision: 112978 xfq.free <at> gmail.com-20130613224333-3yfl8navh3c1vmxy
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS='-O0 -g3' CPPFLAGS='-Ic:/Devel/emacs/include'
 LDFLAGS='-Lc:/Devel/emacs/lib''

Message #8 received at 14635 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 14635 <at> debbugs.gnu.org
Subject: Re: bug#14635: 24.3.50; Regression in Customize: no revert changes
Date: Sun, 16 Jun 2013 12:30:07 +0200

On Sun, Jun 16, 2013 at 11:18 AM, Drew Adams <drew.adams <at> oracle.com> wrote:

> emacs -Q
> M-x customize-face default
>
> Make some changes.  Then choose Set for current session from the State
> button.
>
> Then try to revert your changes using button `Revert...' > `Revert this
> session's customizations'.  There is no effect: no change in the
> appearance of the buffer.

Some things can be reverted (underline, etc.) and some not (font
family, slant...). Weird.

    Juanma

Message #15 received at 14635 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 14635 <at> debbugs.gnu.org
Subject: Re: bug#14635: 24.3.50; Regression in Customize: no revert changes
Date: Fri, 30 Oct 2020 10:35:33 -0300

[Message part 1 (text/plain, inline)]

Drew Adams <drew.adams <at> oracle.com> writes:

> emacs -Q
> M-x customize-face default
>
> Make some changes.  Then choose Set for current session from the State
> button.
>
> Then try to revert your changes using button `Revert...' > `Revert this
> session's customizations'.  There is no effect: no change in the
> appearance of the buffer.  And trying to revert or undo edits using the
> State button is also impossible: `Revert this session's customizations'
> is now dimmed out.  This is with emacs -Q.
>
> The change of state to revert to no changes seems completely broken (a
> regression).
>

I can reproduce this issue on master.

IIUC, this bug is very similar, if not a duplicate, to Bug#13476.  But
here, we are dealing with the default face, so perhaps it is trickier.

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.

So, if customizing the foreground color:
M-x customize-face RET default
Move to Foreground and change it to green
C-c C-c to set it for the session
Click State and select: Revert this session's customizations

The default face is still green.  And:
(face-attribute 'default :foreground) ==> "green"

On a TTY the above recipe works just fine, because we do pass default
values here.


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?

[Message part 2 (text/html, inline)]

Message #18 received at 14635 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 14635 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#14635: 24.3.50; Regression in Customize: no revert changes
Date: Fri, 30 Oct 2020 15:43:22 +0200

> 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.

> 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.

Message #21 received at 14635 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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)]

Message #24 received at 14635 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 14635 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#14635: 24.3.50; Regression in Customize: no revert changes
Date: Fri, 30 Oct 2020 16:16:27 +0200

> From: Mauro Aranda <maurooaranda <at> gmail.com>
> Date: Fri, 30 Oct 2020 11:03:39 -0300
> Cc: Drew Adams <drew.adams <at> oracle.com>, 14635 <at> debbugs.gnu.org
> 
> > 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.

I'd begin with doing this in Customize, since it is the only user of
this property.

Message #27 received at 14635 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#14635: 24.3.50; Regression in Customize: no revert changes
Date: Fri, 30 Oct 2020 11:23:51 -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 11:03:39 -0300
>> Cc: Drew Adams <drew.adams <at> oracle.com>, 14635 <at> debbugs.gnu.org
>>
>> > 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.
>
> I'd begin with doing this in Customize, since it is the only user of
> this property.

I'll try to do it.  Thank you.

[Message part 2 (text/html, inline)]

Message #30 received at 14635 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#14635: 24.3.50; Regression in Customize: no revert changes
Date: Sat, 31 Oct 2020 11:56:59 -0300

[Message part 1 (text/plain, inline)]

Mauro Aranda <maurooaranda <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>> Date: Fri, 30 Oct 2020 11:03:39 -0300
>>> Cc: Drew Adams <drew.adams <at> oracle.com>, 14635 <at> debbugs.gnu.org
>>>
>>> > 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.
>>
>> I'd begin with doing this in Customize, since it is the only user of
>> this property.
>
> I'll try to do it.  Thank you.

I attach a patch that makes Customize store the original value of the
default face if the user ever changes it, and then uses it when
reverting.

Basically, Customize tell faces.el the exactly spec to set, by putting a
fake entry under the user theme (and later removing it).

[Message part 2 (text/html, inline)]

[0001-Fix-reverting-the-default-face-to-standard-themed-st.patch (text/x-patch, attachment)]

Message #33 received at 14635 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 14635 <at> debbugs.gnu.org,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#14635: 24.3.50; Regression in Customize: no revert changes
Date: Sun, 06 Feb 2022 00:39:05 +0100

Mauro Aranda <maurooaranda <at> gmail.com> writes:

> I attach a patch that makes Customize store the original value of the
> default face if the user ever changes it, and then uses it when
> reverting.
>
> Basically, Customize tell faces.el the exactly spec to set, by putting a
> fake entry under the user theme (and later removing it).

Looks like this patch was forgotten, so I've now pushed it to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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