GNU bug report logs - #37774
27.0.50; new :extend attribute broke visuals of all themes and other packages

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37774 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages
Date: Sat, 16 Nov 2019 01:50:22 +0200

On 15.11.2019 10:08, Eli Zaretskii wrote:

>> Lots of themes out there, though. Lots of said authors. Who will have to
>> do a version check and the splat-unquote thing, every one of them. I
>> think that's pretty bad.
> 
> It's not bad, because IMO most faces don't need to be changed at all.
> That Jonas and others went ahead and decided to change almost all of
> them is IMO a mistake.

I'm not sure which faces he changed exactly, but IIUC there were at 
least 5 faces that need to be changed (maybe more). And that would have 
to happen in every theme.

>>> If the backward compatibility (or, rather, transparent DWIM-ish
>>> operation) is the overriding consideration, then you are actually
>>> saying that any face attribute we will introduce in the future will
>>> have to be treated the same?
>>
>> I don't know what attributes we will introduce, and whether the default
>> values will be a departure from the previous behavior like this one is.
> 
> It doesn't matter if the default face definition uses that attribute,
> does it?

Well, it kind of does. At least, if the default value of the new 
attribute is in line with the previous behavior, most faces won't have 
to change. They *might* (or some of them might), but that would be on 
the authors of that code, and the new feature would trickle down 
gradually, like we usually do with Emacs.

>> But please note that having it a face attribute was your choice (or
>> maybe Ergus's). I suggested using a symbol property instead. Though I
>> was admittedly late to the party. Doing it in this way would side-step a
>> number of questions like the ones you just asked.
> 
> Using a symbol property is extremely unclean, IMO, and would
> unnecessarily complicate the face-merging code.

Fair enough.

Another option that had been voiced is to split the value into two 
attributes: :extend-foreground and :extend-background. Then we can set 
the default values for both an immediate improvement (:extend-foreground 
to nil) and maximum compatibility (:extend-background to t).

But that brings me to a question. I think whether the 'region' face has 
:extend-background to nil or not is a personal choice. Would the user 
have to fight and convince the author of the theme they are using to 
change that attribute? Or will it be easy to apply personal 
customization and call it a day?

> I guess the best solution at this point is to require all themes to
> make the appropriate changes.

Or that.

Previous Next

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