GNU bug report logs -
#13560
24.2.92; tabulated-list header buttons are broken
Previous Next
Reported by: Jonas Bernoulli <jonas <at> bernoul.li>
Date: Sat, 26 Jan 2013 18:32:02 UTC
Severity: important
Tags: confirmed, help
Found in version 24.2.92
Fixed in version 24.2.93
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #14 received at 13560 <at> debbugs.gnu.org (full text, mbox):
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?
This bug report was last modified 12 years and 195 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.