GNU bug report logs -
#9663
23.2; feature wish: put priority on vcursor overlay
Previous Next
Reported by: Hendrik Tews <hendrik <at> askra.de>
Date: Mon, 3 Oct 2011 20:05:02 UTC
Severity: normal
Tags: fixed, patch
Found in version 23.2
Fixed in version 24.2
Done: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9663 in the body.
You can then email your comments to 9663 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Mon, 03 Oct 2011 20:05:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Hendrik Tews <hendrik <at> askra.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 03 Oct 2011 20:05:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
the vcursor is invisible in the locked regions of Proof General,
because the overlay of the locked region has priority 100 and the
vcursor overlay has no priority set.
Below I attach a patch that adds a defcustom
vcursor-overlay-priority to the vcursor package, which fixes this
problem. (I hereby assign copyright in this patch to the emacs
project/FSF.)
Bye,
Hendrik Tews
*** vcursor-23.2.el 2011-10-03 21:33:10.000000000 +0200
--- vcursor.el 2011-10-03 21:29:59.000000000 +0200
*************** scrolling set this. It is used by the `
*** 508,513 ****
--- 508,521 ----
:type 'boolean
:group 'vcursor)
+ (defcustom vcursor-overlay-priority 500
+ "Priority of the overlay that symbolizes the vcursor.
+ Increase this value if the vcursor becomes invisible when moving
+ into other specifically colored regions of text."
+ :type 'integer
+ :group 'vcursor
+ :version "23.4")
+
(defvar vcursor-temp-goal-column nil
"Keeps track of temporary goal columns for the virtual cursor.")
*************** another window. With LEAVE-W, use the c
*** 657,663 ****
(or window-system
(display-color-p)
(overlay-put vcursor-overlay 'before-string vcursor-string))
! (overlay-put vcursor-overlay 'face 'vcursor))
(or leave-w (vcursor-find-window nil t))
;; vcursor-window now contains the right buffer
(or (pos-visible-in-window-p pt vcursor-window)
--- 665,672 ----
(or window-system
(display-color-p)
(overlay-put vcursor-overlay 'before-string vcursor-string))
! (overlay-put vcursor-overlay 'face 'vcursor)
! (overlay-put vcursor-overlay 'priority vcursor-overlay-priority))
(or leave-w (vcursor-find-window nil t))
;; vcursor-window now contains the right buffer
(or (pos-visible-in-window-p pt vcursor-window)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Thu, 06 Oct 2011 04:11:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
On 10/3/11 1:48 PM, Hendrik Tews wrote:
> the vcursor is invisible in the locked regions of Proof General,
> because the overlay of the locked region has priority 100 and the
> vcursor overlay has no priority set.
>
> Below I attach a patch that adds a defcustom
> vcursor-overlay-priority to the vcursor package, which fixes this
> problem. (I hereby assign copyright in this patch to the emacs
> project/FSF.)
Wouldn't nil be a better default value than 500?
> *** vcursor-23.2.el 2011-10-03 21:33:10.000000000 +0200
> --- vcursor.el 2011-10-03 21:29:59.000000000 +0200
> *************** scrolling set this. It is used by the `
> *** 508,513 ****
> --- 508,521 ----
> :type 'boolean
> :group 'vcursor)
>
> + (defcustom vcursor-overlay-priority 500
> + "Priority of the overlay that symbolizes the vcursor.
> + Increase this value if the vcursor becomes invisible when moving
> + into other specifically colored regions of text."
> + :type 'integer
> + :group 'vcursor
> + :version "23.4")
> +
> (defvar vcursor-temp-goal-column nil
> "Keeps track of temporary goal columns for the virtual cursor.")
>
> *************** another window. With LEAVE-W, use the c
> *** 657,663 ****
> (or window-system
> (display-color-p)
> (overlay-put vcursor-overlay 'before-string vcursor-string))
> ! (overlay-put vcursor-overlay 'face 'vcursor))
> (or leave-w (vcursor-find-window nil t))
> ;; vcursor-window now contains the right buffer
> (or (pos-visible-in-window-p pt vcursor-window)
> --- 665,672 ----
> (or window-system
> (display-color-p)
> (overlay-put vcursor-overlay 'before-string vcursor-string))
> ! (overlay-put vcursor-overlay 'face 'vcursor)
> ! (overlay-put vcursor-overlay 'priority vcursor-overlay-priority))
> (or leave-w (vcursor-find-window nil t))
> ;; vcursor-window now contains the right buffer
> (or (pos-visible-in-window-p pt vcursor-window)
>
>
>
>
--
Kevin Rodgers
Denver, Colorado, USA
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Tue, 01 Nov 2011 16:09:03 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
Kevin Rodgers writes:
Date: Wed, 05 Oct 2011 22:10:52 -0600
Subject: Re: bug#9663: 23.2; feature wish: put priority on vcursor overlay
Wouldn't nil be a better default value than 500?
No, I don't believe so.
As a secondary cursor the virtual cursor should be visible under
almost all circumstances (in fact, I don't know a use-case, where
the virtual cursor should be hidden below some other overlay).
Therefore the priority of the vcursor should be reasonable high.
Using nil as default would mean that every user of vcursor that
uses a package which puts priorities on overlays, has to
reconfigure the priority.
On the other hand, having the defcustom vcursor-overlay-priority
with default nil would still be a big improvement over the
current situation, where vcursor users are forced to use advice
on vcursor-move.
Bye,
Hendrik
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Tue, 01 Nov 2011 20:02:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 9663 <at> debbugs.gnu.org (full text, mbox):
> As a secondary cursor the virtual cursor should be visible under
> almost all circumstances (in fact, I don't know a use-case, where
> the virtual cursor should be hidden below some other overlay).
> Therefore the priority of the vcursor should be reasonable high.
That makes sense. OTOH overlays that have the same priority are ordered
by size, so that a small overlay such as the vcursor one takes
precedence over most other overlays of the 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.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Tue, 01 Nov 2011 21:26:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 9663 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier 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.
Bye,
Hendrik
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Wed, 02 Nov 2011 01:23:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 9663 <at> debbugs.gnu.org (full text, mbox):
> 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.
I'm not sure why ProofGeneral messes with priorities, tho. Nor why it
chooses 100 as the "default raised priority", nor "raised with respect
to what".
The way I see it, overlay priorities are very little used and are fairly
problematic, so I'd rather recommend not to use them.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Wed, 02 Nov 2011 07:41:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 9663 <at> debbugs.gnu.org (full text, mbox):
> 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.
I'm not sure why ProofGeneral messes with priorities, tho. Nor why it
chooses 100 as the "default raised priority", nor "raised with respect
to what".
The way I see it, overlay priorities are very little used and are fairly
problematic, so I'd rather recommend not to use them.
I don't know either.
Nevertheless, priorities on overlays are a standard emacs
feature. Therefore, there should be a way to adjust the priority
of the vcursor without having to use advice in an inefficient
way.
Bye,
Hendrik
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Wed, 11 Apr 2012 11:37:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 9663 <at> debbugs.gnu.org (full text, mbox):
Hendrik Tews <tews <at> 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?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Wed, 11 Apr 2012 11:56:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 9663 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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?
I really don't understand this discussion about a very simple
feature wish with a very simple patch. Overlay priorities do
exist, so vcursor better should work in the presence of overlays
with non-zero priorities, shouldn't it?
Bye,
Hendrik
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Wed, 11 Apr 2012 12:26:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 9663 <at> debbugs.gnu.org (full text, mbox):
> From: Hendrik Tews <tews <at> os.inf.tu-dresden.de>
> Date: Wed, 11 Apr 2012 13:54:40 +0200
> Cc: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>, 9663 <at> 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 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Wed, 11 Apr 2012 13:28:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 9663 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii writes:
Date: Wed, 11 Apr 2012 15:22:47 +0300
Subject: Re: bug#9663: 23.2; feature wish: put priority on vcursor overlay
> From: Hendrik Tews <tews <at> os.inf.tu-dresden.de>
> Date: Wed, 11 Apr 2012 13:54:40 +0200
> Cc: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>, 9663 <at> 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 <at> 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.
I still don't understand why you suggest this is a bug in Proof
General?
However, if, as you say, vcursor should always be visible,
why not make its default priority most-positive-fixnum?
I agree, most-positive-fixnum would be a reasonable choice.
However, some day there might be a package with an overly that
should hide the vcursor. A large but not maximal number might be
a better choice.
And if we agree this is TRT, do we still need a defcustom?
Because the defcustom gives more freedom to users and without it
they have to resort to
(defadvice vcursor-move (after vcursor-overlay-set-priority activate)
"Change the priority of the vcursor overlay."
(and vcursor-overlay
(overlay-put vcursor-overlay 'priority 1000)))
Bye,
Hendrik
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Wed, 11 Apr 2012 13:45:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 9663 <at> debbugs.gnu.org (full text, mbox):
> I still don't understand why you suggest this is a bug in Proof
> General?
I don't know either, but I do agree that uses of overlay priorities are
generally wrong (i.e. they workaround a problem, introducing others).
> I agree, most-positive-fixnum would be a reasonable choice.
> However, some day there might be a package with an overly that
> should hide the vcursor. A large but not maximal number might be
> a better choice.
And that's the reason why I hate overlay priorities and they're never
a good solution, although once you go down that path, there's little
else you can do.
I see no need for a defcustom. Just put a large enough value (e.g. 200)
to fix the immediate problem, and hope for the best, since after all,
that's the best we can do at this point anyway.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Wed, 11 Apr 2012 14:18:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 9663 <at> debbugs.gnu.org (full text, mbox):
> From: Hendrik Tews <tews <at> os.inf.tu-dresden.de>
> Date: Wed, 11 Apr 2012 15:25:46 +0200
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
> larsi <at> gnus.org,
> kevin.d.rodgers <at> gmail.com,
> 9663 <at> debbugs.gnu.org
>
> > Could you explain why using a non-deprecated feature (priorities
> > of overlays) is a bug?
>
> It isn't.
>
> I still don't understand why you suggest this is a bug in Proof
> General?
But I just said it was NOT a bug, not in Proof General, not anywhere.
> However, if, as you say, vcursor should always be visible,
> why not make its default priority most-positive-fixnum?
>
> I agree, most-positive-fixnum would be a reasonable choice.
> However, some day there might be a package with an overly that
> should hide the vcursor.
We can bother about that when that day comes, if it ever does.
> A large but not maximal number might be a better choice.
Any other value is arbitrary, and I don't like arbitrary values.
But since it sounds like I'm the only one, I will have to live with
that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9663; Package
emacs.
(Wed, 11 Apr 2012 14:30:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 9663 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> A large but not maximal number might be a better choice.
>
> Any other value is arbitrary, and I don't like arbitrary values.
I've committed "200" to trunk, and noted in the comment that it's
arbitrary.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Added tag(s) fixed.
Request was from
Lars Magne Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 11 Apr 2012 14:30:03 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 24.2, send any further explanations to
9663 <at> debbugs.gnu.org and Hendrik Tews <hendrik <at> askra.de>
Request was from
Lars Magne Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 11 Apr 2012 14:30:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 10 May 2012 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 10 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.