> 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 wrote: > > From: Andrey Orst > > Date: Wed, 16 Oct 2019 14:17:27 +0300 > > Cc: Eli Zaretskii , 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