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

[Daniel Colascione]

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.