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

["Drew Adams" <drew.adams@oracle.com>]

> 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."