GNU bug report logs - #64347
30.0.50; Some customize faces shown as edited with -Q

Previous Next

Package: emacs;

Reported by: Stephen Berman <stephen.berman <at> gmx.net>

Date: Thu, 29 Jun 2023 10:16:01 UTC

Severity: normal

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stephen.berman <at> gmx.net, 64347 <at> debbugs.gnu.org
Subject: Re: bug#64347: 30.0.50; Some customize faces shown as edited with -Q
Date: Sun, 9 Jul 2023 20:12:38 -0300
Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Sun, 9 Jul 2023 08:44:23 -0300
>> Cc: 64347 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>  > I guess I'm missing something here: why do we need those pre-filter
>>  > and post-filter conversions?  The C code understands both forms of
>>  > :line-width, so there should be no need for Lisp to do any
>>  > conversions, right?  So why do we do that? why not simply leave the
>>  > spec as it was originally?
>>
>> Custom needs the pre-filter in order to present a Custom buffer to edit
>> the face.
>> Let's say there's a face:
>> (defface foo
>>    '((t (:box (:line-width 1 :color "black"))))
>>    "...")
>>
>> And let's say a user wants to customize it via Custom.
>> M-x customize-face RET foo
>> should show the user a buffer with all the capabilities to edit it.
>> Because we have an integer for the :line-width property, the user will
>> be presented with an integer Widget to edit the value, without giving
>> the user the opportunity to edit the HWIDTH and VWIDTH separately.
>>
>> So the pre-filter takes the (:line-width 1), and converts it into
>> (:line-width (1 . 1)), and now the Custom buffer will have
>> a cons Widget.  If we didn't do that conversion, that would be a Bug
>> report, I'm sure.
>
> OK, but why does it have to do that on the original value? It could
> do that on a copy that serves for the display and editing, in which
> case the original value could be left intact if the user didn't change
> it or did change, but didn't click Apply.  (If the user does modify
> the original value, then any conversions are okay, since the variable
> is really "edited".)

I think my description was inaccurate, because it seemed to imply that
it is a destructive operation.  It is not, it leaves the original value
intact.

But when deciding to set a state, Custom always consults the spec built
from the data the face Widget has.





This bug report was last modified 1 year and 311 days ago.

Previous Next


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