bug#13718: [patch] prevents hl-line from overriding highlight-mode

bug#13718: [patch] prevents hl-line from overriding highlight-mode

[Fei]

Hello,

I found that the overlays in highlight-mode do not override the
overlays from global-hl-line-mode, causing them to disappear on the
currently active line.  The solution I found was to edit hi-lock.el to
increase the priority of the overlay, as outlined in this patch:

--- hi-lock.el 2012-08-28 19:40:24.000000000 -0400
+++ hi-lock.el 2013-02-14 12:57:56.715031100 -0500
@@ -591,6 +591,7 @@
             (goto-char search-start)
             (while (re-search-forward regexp search-end t)
               (let ((overlay (make-overlay (match-beginning 0) (match-end 0))))
+                (overlay-put overlay 'priority 1)
                 (overlay-put overlay 'hi-lock-overlay t)
                 (overlay-put overlay 'hi-lock-overlay-regexp serial)
                 (overlay-put overlay 'face face))

My Emacs version is: 24.2.1 (i386-mingw-nt6.1.7601) 2012-08-28 on MARVIN

Thanks,
Fei

bug#13718: [patch] prevents hl-line from overriding highlight-mode

[Drew Adams]

> I found that the overlays in highlight-mode do not override the
> overlays from global-hl-line-mode, causing them to disappear on the
> currently active line.  The solution I found was to edit hi-lock.el to
> increase the priority of the overlay, as outlined in this patch:

Bad design.

The priority here should be a user option, or at least a defvar that a user can
tweak.  Likewise, for other overlay priorities in Emacs.

A library can reasonably set the _default_ priority for an overlay, but it
cannot know what priority might actually be most appropriate when the library is
used in combination with other code and when taking user preferences into
account.

bug#13718: [patch] prevents hl-line from overriding highlight-mode

[Stefan Monnier]

> I found that the overlays in highlight-mode do not override the
> overlays from global-hl-line-mode, causing them to disappear on the
> currently active line.

hl-line seems to leave its overlay's priority unspecified (good!), which
means that it should take precedence over overlays which are larger
(e.g. span multiple lines) while smaller overlays within the current
line should take precedence over it.

Can you describe your particular case?  What are the overlays that
"disappear", what do they cover, and why do you think they should not
"disappear" like that?

> The solution I found was to edit hi-lock.el to
> increase the priority of the overlay, as outlined in this patch:

I must admit to disliking explicit overlay priorities, which tend to
just lead to more problems down the road (needing to specify priorities
on more overlays, which in turn cause yet more problems, ...), so if at
all possible, I'd rather avoid doing that.


        Stefan

bug#13718: [patch] prevents hl-line from overriding highlight-mode

[Fei]

> hl-line seems to leave its overlay's priority unspecified (good!), which
> means that it should take precedence over overlays which are larger
> (e.g. span multiple lines) while smaller overlays within the current
> line should take precedence over it.
>
> Can you describe your particular case?  What are the overlays that
> "disappear", what do they cover, and why do you think they should not
> "disappear" like that?

That's actually a reasonable alternative to my hard-coded solution,
but the problem is that it doesn't seem to work in every case: when I
open a file that has syntax highlighting (e.g. Bash or Python) and
then use highlight-phrase/regexp, the global-hl-line will have higher
priority than the highlight, no matter what the size of the highlight
is.  If I do the same thing in text-mode, the problem does not occur.
(This was tested on 24.2.1-i386-mingw-nt6.1.7601  without any custom
configuration.)

> The priority here should be a user option, or at least a defvar that a user can
> tweak.  Likewise, for other overlay priorities in Emacs.

That's fine too, as long as it can be changed without directly messing
with the internals.  Currently there is no such variable available for
either hl-line or any of the highlights.

bug#13718: [patch] prevents hl-line from overriding highlight-mode

[Stefan Monnier]

>> hl-line seems to leave its overlay's priority unspecified (good!), which
>> means that it should take precedence over overlays which are larger
>> (e.g. span multiple lines) while smaller overlays within the current
>> line should take precedence over it.

> That's actually a reasonable alternative to my hard-coded solution,
> but the problem is that it doesn't seem to work in every case: when I
> open a file that has syntax highlighting (e.g. Bash or Python) and
> then use highlight-phrase/regexp, the global-hl-line will have higher
> priority than the highlight, no matter what the size of the highlight
> is.  If I do the same thing in text-mode, the problem does not occur.
> (This was tested on 24.2.1-i386-mingw-nt6.1.7601  without any custom
> configuration.)

That's a different issue: in most major modes, font-lock will be enable,
in which case hi-lock uses it, which implies that hi-lock will use
text-properties instead of overlays.  And text-properties always have
lower priority than overlays.
Problem is: in such a case, not only you do have a problem, but your
patch should make no difference, so overlays always take priority over
text-properties, no matter the value of the `priority' property.

IOW, are you sure your patch fixes the problem for you?


        Stefan

bug#13718: [patch] prevents hl-line from overriding highlight-mode

[Fei]

> IOW, are you sure your patch fixes the problem for you?

Oh hey, I guess it doesn't after all.  Silly me.  I guess then the
question becomes, why doesn't hi-lock use overlays?  Or conversely,
why doesn't global-hl-line-mode use font-locks?

bug#13718: [patch] prevents hl-line from overriding highlight-mode

[Fei]

Okay I realize this is very hackish solution, but I went ahead and
replaced every instance of font-lock-fontified with nil so that Emacs
will just use overlays for highlights at all times, which "fixed" the
problem that I have.

But a more general solution would be one of the following:

- Force highlight-regexp (and similar ones) to use overlays at all
times: I don't know why it uses two different methods to do the same
thing, but I suspect it may be for the sake of efficiency perhaps?  Or
to prevent highlights from trampling over the syntax highlighting?
Perhaps this could be made into a customizable option?

- Use font-lock for hl-line: maybe this is isn't possible because
font-lock doesn't provide the functionality to do so?

Or maybe there's a better solution out there -- I don't know.

Thanks,
Fei

bug#13718: [patch] prevents hl-line from overriding highlight-mode

[Drew Adams]

> Or maybe there's a better solution out there -- I don't know.

code: http://www.emacswiki.org/emacs-en/download/highlight.el
doc:  http://www.emacswiki.org/HighlightLibrary

bug#13718: [patch] prevents hl-line from overriding highlight-mode

[Drew Adams]

> hl-line seems to leave its overlay's priority unspecified 
> (good!), which
> means that it should take precedence over overlays which are larger
> (e.g. span multiple lines) while smaller overlays within the current
> line should take precedence over it.

Yes, that is a good _default_ behavior.  That does not mean it is the behavior
that everyone wants/needs in every context.

Being able to easily change a given overlay's priority helps users.  Being able
to do that does not mean that everyone will do it.  And the doc can of course
advise users _not_ to fiddle with overlay priorities, in general.

But hard-coding the behavior makes things harder for users.  Think default
behavior, not _the_ behavior.  Give the overlay a defvar.  Users can ignore the
variable (generally recommended) or they can change its value if needed,
globally or locally.

> I must admit to disliking explicit overlay priorities,

+1

> which tend to just lead to more problems down the road (needing
> to specify priorities on more overlays, which in turn cause yet
> more problems, ...), so if at all possible, I'd rather avoid
> doing that.

Agreed - essentially an unwinnable arms race.  Still, we should make it easy for
users to do just that: control specific overlay priorities when they need to.

Emacs has always provided more than enough rope to hang oneself.  That's part of
being "the extensible, customizable, self-documenting real-time display editor."