[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.
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Eli Zaretskii, 2023/07/08
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Mauro Aranda, 2023/07/08
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Eli Zaretskii, 2023/07/09
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Mauro Aranda, 2023/07/09
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Eli Zaretskii, 2023/07/09
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q,
Mauro Aranda <=
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Eli Zaretskii, 2023/07/10
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Mauro Aranda, 2023/07/10
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Mauro Aranda, 2023/07/15
- bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Eli Zaretskii, 2023/07/20
bug#64347: 30.0.50; Some customize faces shown as edited with -Q, Mauro Aranda, 2023/07/15