bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Dmitry Gutov
Subject: bug#15899: 24.3.50; regression: `region' overlay is lower priority than default
Date: Sat, 16 Nov 2013 15:49:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

On 16.11.2013 13:24, Eli Zaretskii wrote:
What way is that?  Before region highlighting was reimplemented as an
overlay, it had a fixed "priority" that couldn't be controlled or
worked around.  So what exactly did easy-kill expect from that
behavior?

That behavior was broken on Leo Liu's system (don't know how) and on mine too (with some themes only).

See https://github.com/leoliu/easy-kill/issues/3 for more details.

But the region always has point on one of its ends, so both the places
where point was and where it is are clearly visible when the region is
active.

In many times point wasn't at any of region ends. That's how `easy-mark' works, it selects some unit of text *around* the point.

So why is there a need for the easy-mark to be visible in
that situation (which is transient and therefore short-lived)?

Just for user information. Looks kinda nice.

The part of the region that overlaps the easy-mark overlay will not be
visible, if the region's priority is lower.

That just means that easy-mark will need to set its priority higher than the *documented* region priority.

That's not the race I had in mind.  What I had in mind was users
complaining about their favorite overlay-based features being obscured
by the region, lobbying the maintainers to increase the priorities of
those overlays above the region (and possibly also above the easy-mark
overlay), or increase the priority of the region overlay; then other
users complaining about the effects of that, and so on and so forth ad
nauseam.

This will have to be solved on a package-by-package basis, like every contentious feature. One user complaint: change the priority of a package-specific overlay. More complaints to change it in different directions: add a user option that will set the priority that overlay.

> How can you even assume that the "region overlay priority
won't change", given the possibility and enough pressure from users?
Once out of the bottle, this genie cannot be easily put back.

Region priority will have to be set once (to 100, or something), documented, and then never changed again. Any changes will have to be made to other overlays' priorities.





reply via email to

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