GNU bug report logs - #13560
24.2.92; tabulated-list header buttons are broken

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13560 in the body.
You can then email your comments to 13560 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2.92; tabulated-list header buttons are broken
Date: Sat, 26 Jan 2013 19:31:27 +0100

Starting with 24.2.92 clicking on a column button created by a
Tabulated-List mode derived mode does not sort correctly anymore.

When clicking the first time the order should not be reversed, but it
is.  Clicking some more does not change the order, it stays reversed.  I
looked into why this is so and noticed that the command the mouse event
is bound to is actually called twice.

Thinking that for some reason clicking on the button on the header-line
generates two events I modified tabulated-list-sort-button-map to only
contain a binding for [header-line mouse-1].  Then I clicked again with
the mouse button 1 and got the following warning in the echo area:

,----
| <header-line> <mouse-2> is undefined
`----

It mentions mouse-2 even though I pressed mouse-1.  Also the message did
not appear in *Messages* and I could not get a backtrace after turning
on debug-on-error.

To check whether this is specific to Tabulated-List mode I tried the
following:

,----
| (setq header-line-format
|       (propertize "button"
|                   'keymap (let ((map (make-sparse-keymap)))
|                             (define-key map [header-line mouse-1]
|                               (lambda (e)
|                                 (interactive "e")
|                                 (message "%s" e)))
|                             map)))
`----

Here everything works as expected: I don't get a warning about mouse-2
not being undefined, the command is only called once and it reports that
mouse-1 was pressed.

  Jonas

Message #8 received at 13560 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 13560 <at> debbugs.gnu.org
Subject: Re: bug#13560: 24.2.92; tabulated-list header buttons are broken
Date: Sat, 26 Jan 2013 21:52:22 -0500

Jonas Bernoulli wrote:

> Starting with 24.2.92 clicking on a column button created by a
> Tabulated-List mode derived mode does not sort correctly anymore.

Thanks for the report. Eg visible in buffer-menu, where mouse-1 does not
sort.

I don't know what's going on here, but it seems to have some relation to
mouse-1-click-follows-link. If you set it to nil, or leave it alone but
make a long mouse-1 click, then it works. Otherwise it calls the sort
function twice as you say.

This seems like something that should be fixed for 24.3.

> When clicking the first time the order should not be reversed, but it
> is.  Clicking some more does not change the order, it stays reversed.  I
> looked into why this is so and noticed that the command the mouse event
> is bound to is actually called twice.

Message #11 received at 13560 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 13560 <at> debbugs.gnu.org
Subject: Re: bug#13560: 24.2.92; tabulated-list header buttons are broken
Date: Sun, 27 Jan 2013 20:36:45 -0500

Bisection suggests this stopped working with:

    On revision 110949 (cyd <at> gnu.org-20121124081500-x95lz4fz0j0t052c):
    Fix follow-mouse clicks on undraggable mode/header lines.

    * mouse.el (mouse-drag-line): Even if the line is not draggable,
    keep reading until we get the up-event anyway, in order to process
    the up-event for mouse-1-click-follows-link.

Message #14 received at 13560 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 13560 <at> debbugs.gnu.org
Subject: Re: bug#13560: 24.2.92; tabulated-list header buttons are broken
Date: Mon, 28 Jan 2013 12:11:04 -0500

Jonas Bernoulli wrote:

> Thinking that for some reason clicking on the button on the header-line
> generates two events I modified tabulated-list-sort-button-map to only
> contain a binding for [header-line mouse-1].  Then I clicked again with
> the mouse button 1 and got the following warning in the echo area:
>
> ,----
> | <header-line> <mouse-2> is undefined
> `----

I guess this is due to the mouse-1-click-follows-link issue. Because the
link you click has mouse-face, clicking mouse-1 tries to run the mouse-2
binding.

I tried only binding mouse-2 in tabulated-list-sort-button-map, but that
did not help. Not sure why it binds mouse-1 explicitly, yet uses
follow-link as well.

> To check whether this is specific to Tabulated-List mode I tried the
> following:
>
> ,----
> | (setq header-line-format
> |       (propertize "button"
> |                   'keymap (let ((map (make-sparse-keymap)))
> |                             (define-key map [header-line mouse-1]
> |                               (lambda (e)
> |                                 (interactive "e")
> |                                 (message "%s" e)))
> |                             map)))
> `----
>
> Here everything works as expected: I don't get a warning about mouse-2
> not being undefined, the command is only called once and it reports that
> mouse-1 was pressed.

A test that uses follow-link would be more informative, but at the
moment this seems like a general mouse.el issue rather than anything
specific to tabulated-list. Are there any other modes that use
follow-link in the header line?

Message #17 received at 13560 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 13560 <at> debbugs.gnu.org
Subject: Re: bug#13560: 24.2.92; tabulated-list header buttons are broken
Date: Mon, 28 Jan 2013 22:11:52 -0500

Glenn Morris wrote:

> A test that uses follow-link would be more informative, but at the
> moment this seems like a general mouse.el issue rather than anything
> specific to tabulated-list. Are there any other modes that use
> follow-link in the header line?

Yes; info.el, and this is busted in the same way.

Clicking mouse-1 in the Next/Prev breadcrumbs in the header-line of an
Info page moves by two nodes rather than one. Clicking mouse-2 moves
one.

Message #20 received at 13560 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 13560 <at> debbugs.gnu.org
Cc: martin rudalics <rudalics <at> gmx.at>, Jonas Bernoulli <jonas <at> bernoul.li>,
	Chong Yidong <cyd <at> gnu.org>
Subject: Re: bug#13560: 24.2.92; tabulated-list header buttons are broken
Date: Tue, 29 Jan 2013 20:27:13 -0500

Ok, I think the issue here is mouse-drag-line pushing the same event
onto unread-command-events twice in some cases.

The recent history is a bit convoluted:

2012-07-08 changes to fix bug#374, and simplify mouse-drag-line loop.

This caused bug#12006, fixed 2012-07-26. These changes reverted some of
the loop simplifications, for reasons I don't understand.

These changes in turn caused bug#12971 (no mouse-1 events in header),
fixed 2012-11-24. It seems the fix actually gave us two sets of mouse-1
events in headers though (this bug).

And then we have 2012-10-26 changes for bug#12731, introduced at some
point along the way.


What seems to work for me is going back to the 2012-07-26 changes, and
reverting some of reversion. Basically, just check for switch-frame and
select-window events and ignore them. Then I found I needed one more
tweak to preserve the bug#12731 fix.

The following change seems to not break any of bug 374, 12006, 12971,
12731, and to fix this bug; but I won't be surprised to hear that it
breaks something else...



*** lisp/mouse.el	2013-01-01 09:11:05 +0000
--- lisp/mouse.el	2013-01-29 22:22:44 +0000
***************
*** 425,431 ****
  				   (frame-parameters frame)))
  			'right)))
  	 (draggable t)
! 	 finished event position growth dragged)
      (cond
       ((eq line 'header)
        ;; Check whether header-line can be dragged at all.
--- 425,431 ----
  				   (frame-parameters frame)))
  			'right)))
  	 (draggable t)
! 	 event position growth dragged)
      (cond
       ((eq line 'header)
        ;; Check whether header-line can be dragged at all.
***************
*** 456,494 ****
  
      ;; Start tracking.
      (track-mouse
!       ;; Loop reading events and sampling the position of the mouse.
!       (while (not finished)
! 	(setq event (read-event))
  	(setq position (mouse-position))
  	;; Do nothing if
  	;;   - there is a switch-frame event.
  	;;   - the mouse isn't in the frame that we started in
  	;;   - the mouse isn't in any Emacs frame
- 	;; Drag if
- 	;;   - there is a mouse-movement event
- 	;;   - there is a scroll-bar-movement event (Why? -- cyd)
- 	;;     (same as mouse movement for our purposes)
- 	;; Quit if
- 	;;   - there is a keyboard event or some other unknown event.
  	(cond
- 	 ((not (consp event))
- 	  (setq finished t))
  	 ((memq (car event) '(switch-frame select-window))
  	  nil)
! 	 ((not (memq (car event) '(mouse-movement scroll-bar-movement)))
! 	  (when (consp event)
! 	    ;; Do not unread a drag-mouse-1 event to avoid selecting
! 	    ;; some other window.  For vertical line dragging do not
! 	    ;; unread mouse-1 events either (but only if we dragged at
! 	    ;; least once to allow mouse-1 clicks get through).
! 	    (unless (and dragged
! 			 (if (eq line 'vertical)
! 			     (memq (car event) '(drag-mouse-1 mouse-1))
! 			   (eq (car event) 'drag-mouse-1)))
! 	      (push event unread-command-events)))
! 	  (setq finished t))
! 	 ((not (and (eq (car position) frame)
! 		    (cadr position)))
  	  nil)
  	 ((eq line 'vertical)
  	  ;; Drag vertical divider.
--- 456,480 ----
  
      ;; Start tracking.
      (track-mouse
!       ;; Loop reading events and sampling the position of the mouse,
!       ;; until there is a non-mouse-movement event.  Also,
!       ;; scroll-bar-movement events are the same as mouse movement for
!       ;; our purposes.  (Why? -- cyd)
!       (while (progn
! 	       (setq event (read-event))
! 	       (memq (car-safe event)
!                      '(mouse-movement scroll-bar-movement
!                                       switch-frame select-window)))
  	(setq position (mouse-position))
  	;; Do nothing if
  	;;   - there is a switch-frame event.
  	;;   - the mouse isn't in the frame that we started in
  	;;   - the mouse isn't in any Emacs frame
  	(cond
  	 ((memq (car event) '(switch-frame select-window))
  	  nil)
!  	 ((not (and (eq (car position) frame)
!  		    (cadr position)))
  	  nil)
  	 ((eq line 'vertical)
  	  ;; Drag vertical divider.
***************
*** 512,523 ****
  						  growth
  						(- growth)))))))
      ;; Process the terminating event.
!     (when (and (mouse-event-p event) on-link (not dragged)
! 	       (mouse--remap-link-click-p start-event event))
!       ;; If mouse-2 has never been done by the user, it doesn't have
!       ;; the necessary property to be interpreted correctly.
!       (put 'mouse-2 'event-kind 'mouse-click)
!       (setcar event 'mouse-2)
        (push event unread-command-events))))
  
  (defun mouse-drag-mode-line (start-event)
--- 498,510 ----
  						  growth
  						(- growth)))))))
      ;; Process the terminating event.
!     (unless dragged
!       (when (and (mouse-event-p event) on-link
!                  (mouse--remap-link-click-p start-event event))
!         ;; If mouse-2 has never been done by the user, it doesn't have
!         ;; the necessary property to be interpreted correctly.
!         (put 'mouse-2 'event-kind 'mouse-click)
!         (setcar event 'mouse-2))
        (push event unread-command-events))))
  
  (defun mouse-drag-mode-line (start-event)

Message #23 received at 13560 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>, 13560 <at> debbugs.gnu.org,
	Chong Yidong <cyd <at> gnu.org>
Subject: Re: bug#13560: 24.2.92; tabulated-list header buttons are broken
Date: Wed, 30 Jan 2013 17:05:27 +0100

> The following change seems to not break any of bug 374, 12006, 12971,
> 12731, and to fix this bug; but I won't be surprised to hear that it
> breaks something else...

So far it works here.  I'd suggest to install and port to the trunk
immediately so it gets more coverage.

Thanks, martin

Message #26 received at 13560 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>, 13560 <at> debbugs.gnu.org,
	Chong Yidong <cyd <at> gnu.org>
Subject: Re: bug#13560: 24.2.92; tabulated-list header buttons are broken
Date: Wed, 30 Jan 2013 12:18:08 -0500

martin rudalics wrote:

> So far it works here.  I'd suggest to install and port to the trunk
> immediately so it gets more coverage.

Done.

Message #31 received at 13560 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>, 13560 <at> debbugs.gnu.org,
	Chong Yidong <cyd <at> gnu.org>
Subject: Re: bug#13560: 24.2.92; tabulated-list header buttons are broken
Date: Wed, 30 Jan 2013 14:28:11 -0500

> The following change seems to not break any of bug 374, 12006, 12971,
> 12731, and to fix this bug; but I won't be surprised to hear that it
> breaks something else...

Sounds better than what we have now.


        Stefan "who hates unread-command-events"

Message #34 received at 13560 <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: "Glenn Morris" <rgm <at> gnu.org>
Cc: 13560 <at> debbugs.gnu.org
Subject: Re: bug#13560: 24.2.92; tabulated-list header buttons are broken
Date: Thu, 31 Jan 2013 17:04:10 +0100

Glenn Morris <rgm <at> gnu.org> writes:

> martin rudalics wrote:
>
>> So far it works here.  I'd suggest to install and port to the trunk
>> immediately so it gets more coverage.
>
> Done.

Thanks a lot!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.