From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mauro Aranda Newsgroups: gmane.emacs.bugs Subject: bug#14635: 24.3.50; Regression in Customize: no revert changes Date: Fri, 30 Oct 2020 11:03:39 -0300 Message-ID: References: <329c5dbd-dfc7-406e-9957-71f3b94409b0@default> <83o8kjakxx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c457cc05b2e3ddad" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29279"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 14635@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 30 15:04:57 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kYV1U-0007VP-SQ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Oct 2020 15:04:56 +0100 Original-Received: from localhost ([::1]:36304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYV1T-0006dL-UN for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Oct 2020 10:04:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYV0g-0006HP-78 for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2020 10:04:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47586) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kYV0b-00068z-Vz for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2020 10:04:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kYV0b-0000xR-RB for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2020 10:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mauro Aranda Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Oct 2020 14:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14635 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 14635-submit@debbugs.gnu.org id=B14635.16040666403674 (code B ref 14635); Fri, 30 Oct 2020 14:04:01 +0000 Original-Received: (at 14635) by debbugs.gnu.org; 30 Oct 2020 14:04:00 +0000 Original-Received: from localhost ([127.0.0.1]:59132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYV0a-0000xC-6j for submit@debbugs.gnu.org; Fri, 30 Oct 2020 10:04:00 -0400 Original-Received: from mail-wr1-f50.google.com ([209.85.221.50]:34914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYV0Y-0000wy-4F for 14635@debbugs.gnu.org; Fri, 30 Oct 2020 10:03:59 -0400 Original-Received: by mail-wr1-f50.google.com with SMTP id n15so6625494wrq.2 for <14635@debbugs.gnu.org>; Fri, 30 Oct 2020 07:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v6hYfk3jNac5CebhsnUXAvw1V0/6MBQbcnmL3ntDsk0=; b=hNvcNWX8iciAf92b/T/GD6Kyoy0WtwWDtqwoHpXS+eiGL+un4afjDx4zfU+KKDaNv2 uD39MKSX/k7hwZLvsc1yy17fLJccJ2xBlEFbEJqoZb9zs+XZBCndqGZtUNC67F5jj0gz ap5dKFikHOgiE9gvU7TVO31gCae4L1GR6TPMdtWfy5G+uf9tCwKgh9wOVx8hPNPRYB4V 87rlvrBq+O6TdoacDpV2OYyzwb4nSeDi25glqn0yfilqY/+cGPdSSQO9cKrXslFbI/C2 wN+6ot/yZeYwBaVQczyiopE39bJ7seBcfGZYNTt645CGcI3NKbQuVJ5fUnQLkee3MF6N wfeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v6hYfk3jNac5CebhsnUXAvw1V0/6MBQbcnmL3ntDsk0=; b=sS6hG3x0WP/oe3KEB+oy3io8/D7mVPduxyYDECihDKtuwKIKOBVrD8WR2P9+SDQo9e XDmaU+LbWiaRnLg6DSGW+APb/1UcyMmbN34Ju00sQScpgo1B3zkRFJ14V1hs5x2zzwpZ BpIJJBUoa7Zpwzei75BFLW2vUWLMmCHJmQehuXOzGfZ95yx7f5g5XZgAqu6Rk5r1SDPp z2C51UaV7km/fnFzoNAy93pPo+H8ioYqww5OahKckIv1e8h7hSn7iwcq6lWAFzE7DI7T lXwjqpjX54tzD03NaY/cVfYOUgjxMFQKLEUl50UGiYipOFYNSc+qJnxwChEJ44023gpx cBsg== X-Gm-Message-State: AOAM531s6uI+jN+Y8WXzVb0pp5o8G8rkvfZ1g69Ir70ENaFb38mzSHrR lw6j+eD/b9gb6Yd1kzRXdk4KZqgjg+QpIeUZ3Cs= X-Google-Smtp-Source: ABdhPJz7n6wpLXcrA8FNPuZSwu+iq1YKN1iNmPD4gRal+NoUetIQnpfRROx93kX+HSY3h86EcyMKW6d3CoTc1RAE+FU= X-Received: by 2002:a5d:69d1:: with SMTP id s17mr2166379wrw.77.1604066631504; Fri, 30 Oct 2020 07:03:51 -0700 (PDT) In-Reply-To: <83o8kjakxx.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192110 Archived-At: --000000000000c457cc05b2e3ddad Content-Type: text/plain; charset="UTF-8" Eli Zaretskii writes: >> From: Mauro Aranda >> Date: Fri, 30 Oct 2020 10:35:33 -0300 >> Cc: 14635@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. --000000000000c457cc05b2e3ddad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eli Zaretskii <eliz@gnu= .org> writes:

>> From: Mauro Aranda <maurooaranda@gmail.com>
>> Date:= Fri, 30 Oct 2020 10:35:33 -0300
>> Cc: 14635@debbugs.gnu.org
>>
>> For the d= efault face, face-spec-reset-face only sets all attributes to
>> d= efault values if (display-graphic-p frame) returns nil.=C2=A0 So on a
&g= t;> graphical display, it never resets :family, :foundry, :width, :heigh= t,
>> :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).=C2=A0 So we simply _cannot_ reset the attributes like that,> because there's nothing to reset to.=C2=A0 E.g., unspecified-fg o= nly has
> meaning on a TTY frame.

I see, thanks.

>&g= t; 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 graphi= c
>> display?
>
> Doesn't customizing a face recor= d the original value in some property
> of the face symbol?=C2=A0 If = so, reverting the customizations should use
> those recorded values, = I think.

AFAICT, it doesn't right now.=C2=A0 I followed the reci= pe I gave, and then:
(symbol-plist 'default)
The relevant propert= ies I see are:
* face-defface-spec =3D=3D> ((t nil))
which won'= ;t take us anywhere.
* theme-face, which has the customized value for th= e user theme, and
* customized-face, which again, has the customized val= ue.

But I see no immediate reason why we shouldn't start doing i= t, if you
think it is OK to use that to solve this issue.=C2=A0 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.
--000000000000c457cc05b2e3ddad--