unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
@ 2014-05-29 17:45 Christopher Schmidt
  2014-05-29 18:48 ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Christopher Schmidt @ 2014-05-29 17:45 UTC (permalink / raw)
  To: 17633

    emacs -q
    # Drag the mode line with the mouse.

    mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p

This is a regression.

    In GNU Emacs 24.3.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
    Repository revision: 117171 eliz@gnu.org-20140529164749-nz9x3hi1ipkv9cfk
    Windowing system distributor `The X.Org Foundation', version 11.0.11204000





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-29 17:45 bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p Christopher Schmidt
@ 2014-05-29 18:48 ` Stefan Monnier
  2014-05-29 19:06   ` Christopher Schmidt
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2014-05-29 18:48 UTC (permalink / raw)
  To: 17633

>     emacs -q
>     # Drag the mode line with the mouse.
>     mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p

Indeed, we have a call to that function, while I removed it a year ago.
Not sure how I managed not to notice that call.  I do wonder tho: do you
have a recipe to reproduce the problem?
I tried to hit the bug, but wasn't able to (even after reading the code
and trying to infer the circumstances that would lead to it).

This is a piece of code that we should probably revisit, so having such
a recipe would help me understand how the code works.


        Stefan





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-29 18:48 ` Stefan Monnier
@ 2014-05-29 19:06   ` Christopher Schmidt
  2014-05-29 20:32     ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Christopher Schmidt @ 2014-05-29 19:06 UTC (permalink / raw)
  To: 17633

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I do wonder tho: do you have a recipe to reproduce the problem?  I
> tried to hit the bug, but wasn't able to (even after reading the code
> and trying to infer the circumstances that would lead to it).

>>     emacs -q
>>     # Drag the mode line with the mouse.

That is my recipe.

FWIW there is another major bug:

    emacs -q
    # Click the mode line's buffer identification string ("*GNU Emacs*")

    button-activate: Symbol's function definition is void: nil

This bug only occurs when point is on a character with a keymap.  emacs
seems to use the keymap of the character at point rather than the one of
the character that was actually clicked at.





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-29 19:06   ` Christopher Schmidt
@ 2014-05-29 20:32     ` Stefan Monnier
  2014-05-29 20:47       ` Christopher Schmidt
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2014-05-29 20:32 UTC (permalink / raw)
  To: 17633

>>> emacs -q
>>> # Drag the mode line with the mouse.
> That is my recipe.

Hmm.... when I try that, I get a frame with a single window, so I can
try to drag the mode line, but it won't budge.  And I don't get
any error.
So, I tried to add a C-x 2.  I can then move the mode line, but then
again, I don't get any error.

Oh, wait, right, I see it now: I had used "emacs -Q" rather than "emacs -q".
Thanks.

> FWIW there is another major bug:

>     emacs -q
>     # Click the mode line's buffer identification string ("*GNU Emacs*")
>     button-activate: Symbol's function definition is void: nil
> This bug only occurs when point is on a character with a keymap.  emacs
> seems to use the keymap of the character at point rather than the one of
> the character that was actually clicked at.

Can you make it a separate bug-report?


        Stefan





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-29 20:32     ` Stefan Monnier
@ 2014-05-29 20:47       ` Christopher Schmidt
  2014-05-31 12:34         ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Christopher Schmidt @ 2014-05-29 20:47 UTC (permalink / raw)
  To: 17633

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> FWIW there is another major bug:
>
>>     emacs -q
>>     # Click the mode line's buffer identification string ("*GNU Emacs*")
>>     button-activate: Symbol's function definition is void: nil
>> This bug only occurs when point is on a character with a keymap.
>> emacs seems to use the keymap of the character at point rather than
>> the one of the character that was actually clicked at.
>
> Can you make it a separate bug-report?

AFAICS both issues are manifestations of the same bug because both of
them only come up if point is on a character with a dedicated keymap.





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-29 20:47       ` Christopher Schmidt
@ 2014-05-31 12:34         ` Stefan Monnier
  2014-05-31 12:55           ` Christopher Schmidt
  2014-05-31 13:00           ` Eli Zaretskii
  0 siblings, 2 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-05-31 12:34 UTC (permalink / raw)
  To: 17633

> AFAICS both issues are manifestations of the same bug because both of
> them only come up if point is on a character with a dedicated keymap.

Indeed, I installed the patch below which seems to fix them.
Can you confirm it fixes the problems you've seen?


        Stefan


=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2014-05-31 01:01:19 +0000
+++ lisp/ChangeLog	2014-05-31 12:32:03 +0000
@@ -1,5 +1,8 @@
 2014-05-31  Stefan Monnier  <monnier@iro.umontreal.ca>
 
+	* mouse.el (mouse-posn-property): Ignore posn-point for mode-line
+	clicks (bug#17633).
+
 	* leim/quail/latin-pre.el ("latin-2-prefix"): Use ",," rather than ", "
 	for the single comma, since ", " is *very* common in normal French text
 	(bug#17643).

=== modified file 'lisp/mouse.el'
--- lisp/mouse.el	2014-05-18 22:53:27 +0000
+++ lisp/mouse.el	2014-05-31 12:30:47 +0000
@@ -658,7 +658,10 @@
 	    (str (posn-string pos)))
 	(or (and str
 		 (get-text-property (cdr str) property (car str)))
-	    (and pt
+            ;; FIXME: mouse clicks on the mode-line come with a position in
+            ;; (nth 5).  Maybe we should change the C code instead so that
+            ;; mouse-clicks don't include a position there!
+	    (and pt (not (memq (posn-area pos) '(mode-line header-line)))
 		 (get-char-property pt property w))))
     (get-char-property pos property)))
 






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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-31 12:34         ` Stefan Monnier
@ 2014-05-31 12:55           ` Christopher Schmidt
  2014-05-31 13:00           ` Eli Zaretskii
  1 sibling, 0 replies; 15+ messages in thread
From: Christopher Schmidt @ 2014-05-31 12:55 UTC (permalink / raw)
  To: 17633-done

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> AFAICS both issues are manifestations of the same bug because both of
>> them only come up if point is on a character with a dedicated keymap.
>
> Indeed, I installed the patch below which seems to fix them.  Can you
> confirm it fixes the problems you've seen?

The problems are gone now.  Thanks a lot!





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-31 12:34         ` Stefan Monnier
  2014-05-31 12:55           ` Christopher Schmidt
@ 2014-05-31 13:00           ` Eli Zaretskii
  2014-05-31 14:55             ` Stefan Monnier
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-05-31 13:00 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 17633

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 31 May 2014 08:34:28 -0400
> 
>  2014-05-31  Stefan Monnier  <monnier@iro.umontreal.ca>
>  
> +	* mouse.el (mouse-posn-property): Ignore posn-point for mode-line
> +	clicks (bug#17633).
> +
>  	* leim/quail/latin-pre.el ("latin-2-prefix"): Use ",," rather than ", "
>  	for the single comma, since ", " is *very* common in normal French text
>  	(bug#17643).
> 
> === modified file 'lisp/mouse.el'
> --- lisp/mouse.el	2014-05-18 22:53:27 +0000
> +++ lisp/mouse.el	2014-05-31 12:30:47 +0000
> @@ -658,7 +658,10 @@
>  	    (str (posn-string pos)))
>  	(or (and str
>  		 (get-text-property (cdr str) property (car str)))
> -	    (and pt
> +            ;; FIXME: mouse clicks on the mode-line come with a position in
> +            ;; (nth 5).  Maybe we should change the C code instead so that
> +            ;; mouse-clicks don't include a position there!
> +	    (and pt (not (memq (posn-area pos) '(mode-line header-line)))
>  		 (get-char-property pt property w))))
>      (get-char-property pos property)))

Can you explain the problem in more detail?  I'm afraid I don't
understand the problem with mouse clicks on mode line.





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-31 13:00           ` Eli Zaretskii
@ 2014-05-31 14:55             ` Stefan Monnier
  2014-05-31 16:44               ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2014-05-31 14:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17633

> Can you explain the problem in more detail?  I'm afraid I don't
> understand the problem with mouse clicks on mode line.

I think the real fix (which I intend to install into trunk) is the
one below: including `point' in a mouse-click is simply incorrect since
the current position of point has nothing to do with the mouse event.


        Stefan


=== modified file 'src/keyboard.c'
--- src/keyboard.c	2014-05-30 04:12:08 +0000
+++ src/keyboard.c	2014-05-31 13:42:02 +0000
@@ -5266,9 +5266,7 @@
 				     &object, &dx, &dy, &width, &height);
 	  if (STRINGP (string))
 	    string_info = Fcons (string, make_number (charpos));
-	  textpos = (w == XWINDOW (selected_window)
-		     && current_buffer == XBUFFER (w->contents))
-	    ? PT : marker_position (w->pointm);
+	  textpos = Qnil;
 
 	  xret = wx;
 	  yret = wy;






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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-31 14:55             ` Stefan Monnier
@ 2014-05-31 16:44               ` Eli Zaretskii
  2014-05-31 20:11                 ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-05-31 16:44 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 17633

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 17633@debbugs.gnu.org
> Date: Sat, 31 May 2014 10:55:54 -0400
> 
> > Can you explain the problem in more detail?  I'm afraid I don't
> > understand the problem with mouse clicks on mode line.
> 
> I think the real fix (which I intend to install into trunk) is the
> one below: including `point' in a mouse-click is simply incorrect since
> the current position of point has nothing to do with the mouse event.

But why does it hurt to include the window's point in the click?
Other kinds of click on non-text parts do include some kind of
position, so why is this one a problem?

Btw, your patch won't compile, because 'textpos' is not a Lisp object.





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-31 16:44               ` Eli Zaretskii
@ 2014-05-31 20:11                 ` Stefan Monnier
  2014-06-01  2:41                   ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2014-05-31 20:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17633

> But why does it hurt to include the window's point in the click?

Because mouse-posn-property then checks the text-property at point.

> Other kinds of click on non-text parts do include some kind of
> position, so why is this one a problem?

Usually those positions are at least somewhat related to the position of
the mouse.  But indeed mouse-posn-property should probably ignore the
posn-point info for the other non-text parts.

> Btw, your patch won't compile, because 'textpos' is not a Lisp object.

Yes, it was just to show the intention.


        Stefan





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-05-31 20:11                 ` Stefan Monnier
@ 2014-06-01  2:41                   ` Eli Zaretskii
  2014-06-01 14:18                     ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-06-01  2:41 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 17633

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 17633@debbugs.gnu.org
> Date: Sat, 31 May 2014 16:11:02 -0400
> 
> > But why does it hurt to include the window's point in the click?
> 
> Because mouse-posn-property then checks the text-property at point.

It shouldn't do that.  This sounds like a problem with
mouse-posn-property rather than with make_lispy_position.





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-06-01  2:41                   ` Eli Zaretskii
@ 2014-06-01 14:18                     ` Stefan Monnier
  2014-06-01 14:57                       ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2014-06-01 14:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17633

>> > But why does it hurt to include the window's point in the click?
>> Because mouse-posn-property then checks the text-property at point.
> It shouldn't do that.  This sounds like a problem with
> mouse-posn-property rather than with make_lispy_position.

In the case of fringe clicks, I agree that these events's
buffer-position info is worthwhile and that mouse-posn-property should
ignore it, but in the case of mode-line clicks, the click is completely
unrelated to the particular position of point at that moment, os
including that info is just asking for trouble,


        Stefan





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-06-01 14:18                     ` Stefan Monnier
@ 2014-06-01 14:57                       ` Eli Zaretskii
  2014-06-01 21:13                         ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-06-01 14:57 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 17633

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 17633@debbugs.gnu.org
> Date: Sun, 01 Jun 2014 10:18:57 -0400
> 
> >> > But why does it hurt to include the window's point in the click?
> >> Because mouse-posn-property then checks the text-property at point.
> > It shouldn't do that.  This sounds like a problem with
> > mouse-posn-property rather than with make_lispy_position.
> 
> In the case of fringe clicks, I agree that these events's
> buffer-position info is worthwhile and that mouse-posn-property should
> ignore it, but in the case of mode-line clicks, the click is completely
> unrelated to the particular position of point at that moment, os
> including that info is just asking for trouble,

It's not necessarily unrelated.  Imagine some feature that wants to
change the effect of such a click depending on point.  There's nothing
especially hilarious about that.





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

* bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p
  2014-06-01 14:57                       ` Eli Zaretskii
@ 2014-06-01 21:13                         ` Stefan Monnier
  0 siblings, 0 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-06-01 21:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17633

> It's not necessarily unrelated.  Imagine some feature that wants to
> change the effect of such a click depending on point.  There's nothing
> especially hilarious about that.

No, but there's no need for point to be included in the click event.


        Stefan





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

end of thread, other threads:[~2014-06-01 21:13 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-29 17:45 bug#17633: 24.3.91; mouse-drag-line: Symbol's function definition is void: mouse--remap-link-click-p Christopher Schmidt
2014-05-29 18:48 ` Stefan Monnier
2014-05-29 19:06   ` Christopher Schmidt
2014-05-29 20:32     ` Stefan Monnier
2014-05-29 20:47       ` Christopher Schmidt
2014-05-31 12:34         ` Stefan Monnier
2014-05-31 12:55           ` Christopher Schmidt
2014-05-31 13:00           ` Eli Zaretskii
2014-05-31 14:55             ` Stefan Monnier
2014-05-31 16:44               ` Eli Zaretskii
2014-05-31 20:11                 ` Stefan Monnier
2014-06-01  2:41                   ` Eli Zaretskii
2014-06-01 14:18                     ` Stefan Monnier
2014-06-01 14:57                       ` Eli Zaretskii
2014-06-01 21:13                         ` Stefan Monnier

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