GNU bug report logs - #15899
24.3.50; regression: `region' overlay is lower priority than default

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Thu, 14 Nov 2013 22:58:01 UTC

Severity: normal

Found in version 24.3.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #113 received at 15899 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 15899 <at> debbugs.gnu.org
Subject: Re: bug#15899: 24.3.50; regression: `region' overlay is lower priority
 than default
Date: Sun, 17 Nov 2013 04:25:53 -0800
On 11/16/2013 09:45 AM, Stefan Monnier wrote:
>>>> Isn't it confusing that the region highlighting is non-contiguous when
>>>> an overlay is in its middle?
>>> 1- you need more than "an overlay in its middle": you need this overlay
>>> to put a face property that happens to completely cancel the region's
>>> own face properties (since the `face' properties of overlapping
>>> overlays are merged).
>> It's enough for that face to specify a background color, no?
>
> In some cases, yes, because the region's foreground color is
> often unnoticeable (e.g. same as default).
>
>>> I most-positive-fixnum-ly hate overlay priorities.
>> No offense, but I think we can live with that downside ;-)
>
> The downside is not that I hate it, but the reasons why I hate it: it's
> as much a source of problems as a solution.  `priorities' impose a total
> ordering, where often there isn't one: in some circumstance one overlay
> should be on top, in others it's the other way around.

Can you provide an example of an actual case where two overlays should 
be ordered one way in one context and another in a different context? 
Nothing comes to mind at the moment.

I don't think numeric priorities are as big a social problem as you 
suspect: in other cases where we use priorities to manage interaction of 
unrelated modifiers on some base behavior (e.g., NT filter driver 
altitudes), priorities work well enough and don't lead to arms races. 
I'd have preferred an ordered list to numeric priorities, but numeric 
priorities are good enough.




This bug report was last modified 11 years and 102 days ago.

Previous Next


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