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

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

bug#9663: 23.2; feature wish: put priority on vcursor overlay


From: Eli Zaretskii
Subject: bug#9663: 23.2; feature wish: put priority on vcursor overlay
Date: Wed, 11 Apr 2012 15:22:47 +0300

> From: Hendrik Tews <tews@os.inf.tu-dresden.de>
> Date: Wed, 11 Apr 2012 13:54:40 +0200
> Cc: Kevin Rodgers <kevin.d.rodgers@gmail.com>, 9663@debbugs.gnu.org
> 
> Lars Magne Ingebrigtsen writes:
>    Date: Wed, 11 Apr 2012 13:35:18 +0200
>    Subject: Re: bug#9663: 23.2; feature wish: put priority on vcursor overlay
>    
>    Hendrik Tews <tews@os.inf.tu-dresden.de> writes:
>    
>    >    same priority. Which makes me wonder: why other overlay have
>    >    you bumped into which has either higher priority than nil, or
>    >    nil priority but is not larger than vcursor.
>    >
>    > As I wrote in the feature wish: the locked region in Proof
>    > General (proof-locked-span). It has priority 100, see the call to
>    > span-raise inside proof-init-segmentation in
>    > generic/proof-script.el.
>    
>    So perhaps this is a bug in Proof General and doesn't really require an
>    overlay priority in Emacs?
> 
> Could you explain why using a non-deprecated feature (priorities
> of overlays) is a bug?

It isn't.  However, if, as you say, vcursor should always be visible,
why not make its default priority most-positive-fixnum?  And if we
agree this is TRT, do we still need a defcustom?

> I really don't understand this discussion about a very simple
> feature wish with a very simple patch.

Well, you can't stop people from discussing things, can you? ;-)

Stefan, do you object to increasing the priority of vcursor to
overcome such problems?  If not, my recommendation would be to set the
vcursor priority at most-positive-fixnum, and leave the defcustom out.

If you do object, then how would you suggest to solve this?





reply via email to

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