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

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

bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` f


From: Eli Zaretskii
Subject: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces.
Date: Sat, 07 Dec 2024 20:25:38 +0200

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 7 Dec 2024 12:13:20 -0500
> Cc: monnier@iro.umontreal.ca, trevor.m.murphy@gmail.com, me@eshelyaron.com, 
>       73862@debbugs.gnu.org
> 
> On Sat, Dec 07, 2024 at 7:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > It shouldn't. If you apply it and see something like that, it should be
> > considered a bug somewhere (but I would be very surprised if it did happen).
> >
> 
> Ok, I tested it and you're right, I couldn't see this happen.
> 
> What I did see happen was if I did this:
> 
> (custom-set-faces '(header-line-active ((t (:inherit highlight)))))
> (face-remap-set-base 'highlight 'default)
> 
> Then the remapping doesn't work.

Repeat after me: "basic faces cannot follow remapping due to face
inheritance".

They are called "basic" because they aren't supposed to inherit from
anything, but be used to inherit _from_.

The patch I posted is supposed to make Emacs be more
backward-compatible, in that people who used to remap header-line will
see their remapping propagate to header-line-active etc., but only as
long as they inherit from header-line, which they do by default.
Making header-line inherit from highlight didn't work before, and
should not be expected to work now.

If we install the patch I posted, I wouldn't even document this
special handling of these faces, because its only purpose is to help
with backward compatibility.

> I'm not surprised at this point, but it's still "surprising".

It had never worked!  And was not supposed to work!

> Given it's highly unlikely people would do something
> like this, one could get away with a patch like this most likely.

If people were doing something like that, they would be complaining
long ago.

> > Tab bar mode is another one that comes to mind that probably shouldn't use
> > remaps at all when rendering.
> >
> > Why not?
> 
> Because it's rendered outside of a single buffer.

It doesn't have to be.  It's just a face.  Granted, when a face is
used without relation to a buffer, then using a buffer-local
customization of it (which is what face-remapping is) is not a good
idea.

As with many Emacs features, users shoot themselves in the foot by
(ab)using the features outside of their intended design space, and
then complain that things fall apart.  Emacs trusts the users that
they know what they are doing, although that trust is not always
justified, it seems...





reply via email to

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