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

[Andrey Orst]

> Are you saying that _all_ the faces will have to be modified to make
> them extended?  IOW, are you saying that this feature is wrong with
> most or all of the faces?

I don't know about /all/ faces, but I have experienced a lot of visual changes

when using `doom-one' theme provided by `doom-themes' package paired

with at least these packages: magit, ediff, solaire-mode, org-mode.

> The assumption behind this feature was that the absolute majority of

> faces don't need to be extended.  If you say this is wrong, can you
> show enough examples to back up that?

I understand this, and maybe package maintainers should adopt the change

but since Emacs doesn't ignore unknown attributes, this may result in a lot of

extra code in order to support both pre-27 Emacs, and 27+ Emacs to make

different versions look consistently.

On Wed, Oct 16, 2019 at 2:41 PM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Andrey Orst <andreyorst@gmail.com>
> Date: Wed, 16 Oct 2019 14:17:27 +0300
> Cc: Eli Zaretskii <eliz@gnu.org>, 37774@debbugs.gnu.org
>
> > So you are saying that you don't like the new appearance?  The Subject
> > says "broke visuals", which sounds like a much more serious problem.
>
> Well, "broke" may be wrong term, here, but lot of themes and packages crafted
> in a way to display things like that, and now all of those things displayed accordingly
> to a new setting, which in turn means that:
>
> a) package maintainers should update *all* their packages to look like before the change, and

Are you saying that _all_ the faces will have to be modified to make
them extended?  IOW, are you saying that this feature is wrong with
most or all of the faces?

The assumption behind this feature was that the absolute majority of
faces don't need to be extended.  If you say this is wrong, can you
show enough examples to back up that?

> b) maybe Emacs could treat `nil` here as "do not affect", and specify symbols to set this to different
>    settings, like `:extend t` or `:extend 'EOL`, and `:extend 'noextend` to disable. Though, I do not
>    know how code was changed, so maybe there's no way to treat `nil` as "do not affect".

Let's first find out how many faces would need to be modified to adapt
to this feature, and only after that discuss the details of the
solution(s).

--

Best regards,
Andrey Orst