bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64347: 30.0.50; Some customize faces shown as edited with -Q


From: Mauro Aranda
Subject: bug#64347: 30.0.50; Some customize faces shown as edited with -Q
Date: Sun, 9 Jul 2023 20:12:38 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 9 Jul 2023 08:44:23 -0300
>> Cc: 64347@debbugs.gnu.org, stephen.berman@gmx.net
>> From: Mauro Aranda <maurooaranda@gmail.com>
>>
>> Eli Zaretskii <eliz@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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]