GNU bug report logs - #13718
prevent hl-line from overriding highlight-mode

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>, "'Fei'" <fei.yuanbw <at> gmail.com>
Cc: 13718 <at> debbugs.gnu.org
Subject: bug#13718: [patch] prevents hl-line from overriding highlight-mode
Date: Fri, 15 Feb 2013 09:45:21 -0800

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.