[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?