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

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

[Hendrik Tews]

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)

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

[Kevin Rodgers]

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

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

[Hendrik Tews]

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

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

[Stefan Monnier]

> 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

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

[Hendrik Tews]

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

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

[Stefan Monnier]

>    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

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

[Hendrik Tews]

   > 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

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

[Lars Magne Ingebrigtsen]

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?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Hendrik Tews]

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?

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

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

[Eli Zaretskii]

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

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

[Hendrik Tews]

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@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.  

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

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

[Stefan Monnier]

> 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

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

[Eli Zaretskii]

> From: Hendrik Tews <tews@os.inf.tu-dresden.de>
> Date: Wed, 11 Apr 2012 15:25:46 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>     larsi@gnus.org,
>     kevin.d.rodgers@gmail.com,
>     9663@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.

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

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@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/