bug#1586: prefix arg when mouse clicking on header line

bug#1586: prefix arg when mouse clicking on header line

[Roland Winkler]

If a command takes a mouse event and an (optional) prefix arg as its
arguments, the interactive specifications are

  (interactive "e\nP")

or

  (interactive (list last-input-event current-prefix-arg))

This works fine inside the main part of a window. For a command
that does the same thing in the header line, these interactive
specifications do not work. Instead one needs, e..g,

  (interactive (list last-input-event last-prefix-arg))

i.e., current-prefix-arg needs to be replaced by last-prefix-arg.
This problem occured in the context of the command
proced-sort-header in proced.el, which provides a complete test
example. See also

http://lists.gnu.org/archive/html/emacs-devel/2008-12/msg00559.html



In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2008-12-05 on regnitz
Windowing system distributor `The X.Org Foundation', version
 11.0.10502000

bug#1586: prefix arg when mouse clicking on header line

[Chong Yidong]

> If a command takes a mouse event and an (optional) prefix arg as its
> arguments, the interactive specifications are
>
>   (interactive "e\nP")
>
> or
>
>   (interactive (list last-input-event current-prefix-arg))
>
> This works fine inside the main part of a window. For a command
> that does the same thing in the header line, these interactive
> specifications do not work.

Thanks for the bug report.  I've committed a fix.

bug#1586: prefix arg when mouse clicking on header line

[Stefan Monnier]

>> If a command takes a mouse event and an (optional) prefix arg as its
>> arguments, the interactive specifications are
>> (interactive "e\nP")
>> or
>> (interactive (list last-input-event current-prefix-arg))
>> 
>> This works fine inside the main part of a window. For a command
>> that does the same thing in the header line, these interactive
>> specifications do not work.

> Thanks for the bug report.  I've committed a fix.

Does this actually fix the problem?  If so, I don't understand why:
a down event that's not bound to anything should be dropped entirely by
read-key-sequence.

So my guess at the problem is that [header-line down-mouse-1] is not
left unbound but instead is bound to something
(e.g. `mouse-drag-header-line' or `ignore'), so your code won't be
executed at all in that case.

Now, I'm not sure if we should preserve the prefix arg even if the down
event is bound, or rather just change `mouse-drag-header-line' and/or
`ignore' to propagate the current-prefix-arg to the next event; but
unless I'm missing something your fix should have no effect.


        Stefan


>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:

> ------------------------------------------------------------
> revno: 104891
> committer: Chong Yidong <cyd@stupidchicken.com>
> branch nick: trunk
> timestamp: Sat 2011-07-02 19:40:04 -0400
> message:
>   Fix corner case in prefix-arg handling for mouse events (Bug#1586).
  
>   * src/keyboard.c (command_loop_1): If a down-mouse event is unbound,
>   leave any prefix arg for the up event.
> modified:
>   src/ChangeLog
>   src/keyboard.c

> === modified file 'src/ChangeLog'
> --- a/src/ChangeLog	2011-07-02 16:18:24 +0000
> +++ b/src/ChangeLog	2011-07-02 23:40:04 +0000
> @@ -1,3 +1,8 @@
> +2011-07-02  Chong Yidong  <cyd@stupidchicken.com>
> +
> +	* keyboard.c (command_loop_1): If a down-mouse event is unbound,
> +	leave any prefix arg for the up event (Bug#1586).
> +
>  2011-07-02  Lars Magne Ingebrigtsen  <larsi@gnus.org>
 
>  	* lread.c (syms_of_lread): Mention single symbols defined by

> === modified file 'src/keyboard.c'
> --- a/src/keyboard.c	2011-07-02 04:27:41 +0000
> +++ b/src/keyboard.c	2011-07-02 23:40:04 +0000
> @@ -1539,7 +1539,18 @@
>  	  message_with_string ("%s is undefined", keys, 0);
>  	  KVAR (current_kboard, defining_kbd_macro) = Qnil;
>  	  update_mode_lines = 1;
> -	  KVAR (current_kboard, Vprefix_arg) = Qnil;
> +	  /* If this is a down-mouse event, don't reset prefix-arg;
> +	     pass it to the command run by the up event.  */
> +	  if (EVENT_HAS_PARAMETERS (last_command_event))
> +	    {
> +	      Lisp_Object breakdown
> +		= parse_modifiers (EVENT_HEAD (last_command_event));
> +	      int modifiers = XINT (XCAR (XCDR (breakdown)));
> +	      if (!(modifiers & down_modifier))
> +		KVAR (current_kboard, Vprefix_arg) = Qnil;
> +	    }
> +	  else
> +	    KVAR (current_kboard, Vprefix_arg) = Qnil;
>  	}
>        else
>  	{


> _______________________________________________
> Emacs-diffs mailing list
> Emacs-diffs@gnu.org
> https://lists.gnu.org/mailman/listinfo/emacs-diffs

bug#1586: prefix arg when mouse clicking on header line

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Does this actually fix the problem?  If so, I don't understand why:
> a down event that's not bound to anything should be dropped entirely by
> read-key-sequence.
>
> So my guess at the problem is that [header-line down-mouse-1] is not
> left unbound but instead is bound to something
> (e.g. `mouse-drag-header-line' or `ignore'), so your code won't be
> executed at all in that case.
>
> Now, I'm not sure if we should preserve the prefix arg even if the down
> event is bound, or rather just change `mouse-drag-header-line' and/or
> `ignore' to propagate the current-prefix-arg to the next event; but
> unless I'm missing something your fix should have no effect.

The patch does fix the test case:

(defun test-bug ()
  (interactive)
  (global-set-key [header-line mouse-1] 'foo)
  (setq header-line-format "a"))

(defun foo (event &optional arg)
  (interactive "e\nP")
  (setq foo (cons arg event))
  (message "%s" foo))

C-u mouse-1 on the header line with and without the patch, and you'll
see the prefix arg being passed through, and being dropped.