[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Colascione
Subject: bug#15899: 24.3.50; regression: `region' overlay is lower priority than default
Date: Sun, 17 Nov 2013 04:25:53 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]