bug#71282: 30.0.50; hl-line overlay priority has no affect

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 30 Jun 2024 16:12:55 +0100
> Cc: Mohsin Kaleem <mohkale@kisara.moe>, stefankangas@gmail.com, 71282@debbugs.gnu.org
> 
> On Sun, Jun 30, 2024 at 3:47 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Mohsin Kaleem <mohkale@kisara.moe>
> > > Cc: stefankangas@gmail.com, 71282@debbugs.gnu.org
> > > Date: Sun, 30 Jun 2024 14:41:13 +0100
> > >
> > > Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think it's a "problem".  Overlay strings have their own faces,
> > and those override the faces of buffer text.
> 
> If I understand the scenario correctly, I agree with Moshin that this
> is a more general issue.  There should be some way for overlays
> used by a package X to easily combine with an existing an
> existing background color, even if that background color is mandated
> by some hl-current-line extension Y.  This mechanism shouldn't rely
> on making X aware of Y.

The mechanism exists: find the face of the buffer text, and use it (or
some of its attributes, like background color) in determining the face
of the overlay string.

In some cases, Emacs does this merging automatically, but this is not
one of those cases.  (I think in this case if hl-line uses text
properties instead of overlays, this will happen automatically.  But I
didn't try that, and I might be missing something in this complex
issue.)

> Maybe if the implementation of Y were moved to C display core, like
> display-line-numbers-mode.  Or maybe not, I haven't looked into it
> (and I don't plan to, sorry).

That's unrelated.  The order of merging face information is documented
in the ELisp manual, and changing it is out of the question, because
it worked like that for many years, and any change in it is bound to
break something out there.