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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

The "default priority" at least is able to handle those things
sometimes, by making overlays's ordering depending on nesting.

> In any case, the moment you reimplemented the region as an overlay,
> you got us this issue, because it is inherent in the use of overlays,
> and cannot be escaped.

It was present before as well.  The behavior was different but was also
a source of "priority problems".

My intuition tells me that if Emacs had use the current system for the
last 20 years and had just changed to the "region is always at the very
top", people would complain just as much.


        Stefan