Re: hi-lock and overlays

[Tassilo Horn <tassilo@member.fsf.org>]

Lennart Borgman <lennart.borgman@gmail.com> writes:

Hi Lennart,

>> I was wrong with my previous mail.  The problem that hi-lock pattern
>> on the current line are not highlighted, when `hl-line-mode' is
>> enabled is not due to conflicting overlays.  The problem is that
>> hi-lock uses overlays only when the undocumented variable
>> `font-lock-fontified' is nil (see `hi-lock-set-pattern').  Else, it
>> uses normal fontification, and overlays (like the one for the current
>> line created by `hl-line-mode') take precedence over that.
>
>
> I would rather turn the question this way:
>
> - Why can't an overlay have a priority that is lower than text?

,----[ (info "(elisp)Overlay Properties") ]
| `priority'
|      This property's value (which should be a nonnegative integer
|      number) determines the priority of the overlay.  No priority, or
|      `nil', means zero.
| 
|      The priority matters when two or more overlays cover the same
|      character and both specify the same property; the one whose
|      `priority' value is larger overrides the other.  For the `face'
|      property, the higher priority overlay's value does not completely
|      override the other value; instead, its face attributes override
|      the face attributes of the lower priority `face' property.
| 
|      Currently, all overlays take priority over text properties.  Please
|      avoid using negative priority values, as we have not yet decided
|      just what they should mean.
`----

Hm, reading the last paragraph, this would be an option.  A negative
priority could be used to make text properties precede overlay
properties.

Anyway, the two other questions of my previous mail still stand.

Bye,
Tassilo