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

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

bug#37774: 27.0.50; new :extend attribute broke visuals of all themes an


From: Dmitry Gutov
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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.





reply via email to

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