unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#9663: 23.2; feature wish: put priority on vcursor overlay
@ 2011-10-03 19:48 Hendrik Tews
  2011-10-06  4:10 ` Kevin Rodgers
  0 siblings, 1 reply; 14+ messages in thread
From: Hendrik Tews @ 2011-10-03 19:48 UTC (permalink / raw)
  To: 9663

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)





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2011-10-03 19:48 bug#9663: 23.2; feature wish: put priority on vcursor overlay Hendrik Tews
@ 2011-10-06  4:10 ` Kevin Rodgers
  2011-11-01  8:57   ` Hendrik Tews
  0 siblings, 1 reply; 14+ messages in thread
From: Kevin Rodgers @ 2011-10-06  4:10 UTC (permalink / raw)
  To: 9663

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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2011-10-06  4:10 ` Kevin Rodgers
@ 2011-11-01  8:57   ` Hendrik Tews
  2011-11-01 19:59     ` Stefan Monnier
  0 siblings, 1 reply; 14+ messages in thread
From: Hendrik Tews @ 2011-11-01  8:57 UTC (permalink / raw)
  To: Kevin Rodgers; +Cc: 9663

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2011-11-01  8:57   ` Hendrik Tews
@ 2011-11-01 19:59     ` Stefan Monnier
  2011-11-01 21:23       ` Hendrik Tews
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2011-11-01 19:59 UTC (permalink / raw)
  To: Hendrik Tews; +Cc: Kevin Rodgers, 9663

> 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2011-11-01 19:59     ` Stefan Monnier
@ 2011-11-01 21:23       ` Hendrik Tews
  2011-11-02  1:19         ` Stefan Monnier
  2012-04-11 11:35         ` Lars Magne Ingebrigtsen
  0 siblings, 2 replies; 14+ messages in thread
From: Hendrik Tews @ 2011-11-01 21:23 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Kevin Rodgers, 9663

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2011-11-01 21:23       ` Hendrik Tews
@ 2011-11-02  1:19         ` Stefan Monnier
  2011-11-02  7:37           ` Hendrik Tews
  2012-04-11 11:35         ` Lars Magne Ingebrigtsen
  1 sibling, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2011-11-02  1:19 UTC (permalink / raw)
  To: Hendrik Tews; +Cc: Kevin Rodgers, 9663

>    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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2011-11-02  1:19         ` Stefan Monnier
@ 2011-11-02  7:37           ` Hendrik Tews
  0 siblings, 0 replies; 14+ messages in thread
From: Hendrik Tews @ 2011-11-02  7:37 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Kevin Rodgers, 9663

   > 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2011-11-01 21:23       ` Hendrik Tews
  2011-11-02  1:19         ` Stefan Monnier
@ 2012-04-11 11:35         ` Lars Magne Ingebrigtsen
  2012-04-11 11:54           ` Hendrik Tews
  1 sibling, 1 reply; 14+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-04-11 11:35 UTC (permalink / raw)
  To: Hendrik Tews; +Cc: Kevin Rodgers, 9663

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/





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2012-04-11 11:35         ` Lars Magne Ingebrigtsen
@ 2012-04-11 11:54           ` Hendrik Tews
  2012-04-11 12:22             ` Eli Zaretskii
  0 siblings, 1 reply; 14+ messages in thread
From: Hendrik Tews @ 2012-04-11 11:54 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: Kevin Rodgers, 9663

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2012-04-11 11:54           ` Hendrik Tews
@ 2012-04-11 12:22             ` Eli Zaretskii
  2012-04-11 13:25               ` Hendrik Tews
  0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2012-04-11 12:22 UTC (permalink / raw)
  To: Hendrik Tews, Stefan Monnier; +Cc: larsi, kevin.d.rodgers, 9663

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2012-04-11 12:22             ` Eli Zaretskii
@ 2012-04-11 13:25               ` Hendrik Tews
  2012-04-11 13:43                 ` Stefan Monnier
  2012-04-11 14:14                 ` Eli Zaretskii
  0 siblings, 2 replies; 14+ messages in thread
From: Hendrik Tews @ 2012-04-11 13:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, kevin.d.rodgers, 9663

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2012-04-11 13:25               ` Hendrik Tews
@ 2012-04-11 13:43                 ` Stefan Monnier
  2012-04-11 14:14                 ` Eli Zaretskii
  1 sibling, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2012-04-11 13:43 UTC (permalink / raw)
  To: Hendrik Tews; +Cc: kevin.d.rodgers, larsi, 9663

> 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2012-04-11 13:25               ` Hendrik Tews
  2012-04-11 13:43                 ` Stefan Monnier
@ 2012-04-11 14:14                 ` Eli Zaretskii
  2012-04-11 14:27                   ` Lars Magne Ingebrigtsen
  1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2012-04-11 14:14 UTC (permalink / raw)
  To: Hendrik Tews; +Cc: larsi, kevin.d.rodgers, 9663

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#9663: 23.2; feature wish: put priority on vcursor overlay
  2012-04-11 14:14                 ` Eli Zaretskii
@ 2012-04-11 14:27                   ` Lars Magne Ingebrigtsen
  0 siblings, 0 replies; 14+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-04-11 14:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: kevin.d.rodgers, 9663, Hendrik Tews

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/





^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2012-04-11 14:27 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-03 19:48 bug#9663: 23.2; feature wish: put priority on vcursor overlay Hendrik Tews
2011-10-06  4:10 ` Kevin Rodgers
2011-11-01  8:57   ` Hendrik Tews
2011-11-01 19:59     ` Stefan Monnier
2011-11-01 21:23       ` Hendrik Tews
2011-11-02  1:19         ` Stefan Monnier
2011-11-02  7:37           ` Hendrik Tews
2012-04-11 11:35         ` Lars Magne Ingebrigtsen
2012-04-11 11:54           ` Hendrik Tews
2012-04-11 12:22             ` Eli Zaretskii
2012-04-11 13:25               ` Hendrik Tews
2012-04-11 13:43                 ` Stefan Monnier
2012-04-11 14:14                 ` Eli Zaretskii
2012-04-11 14:27                   ` Lars Magne Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).