[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

mouse-1 click on widget button

From: Katsumi Yamaoka
Subject: mouse-1 click on widget button
Date: Mon, 21 Jan 2008 20:12:21 +0900
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux)


I use this:

(setq mouse-1-click-follows-link nil
      mouse-1-click-in-non-selected-windows nil)

Even so, mouse-1 click on a url string in the Gnus article buffer
raises the web browser.  It is because Gnus puts a widget button
on a text which looks like a url[1], and the button is sensitive
to mouse-1 as well as mouse-2 because of the default value of
`widget-keymap'[2] defined in wid-edit.el as follows:

(defvar widget-keymap
    (define-key map [down-mouse-2] 'widget-button-click)
    (define-key map [down-mouse-1] 'widget-button-click)

The changelog relevant to this is:

2006-02-14  Chong Yidong  <address@hidden>

        * wid-edit.el (widget-keymap): Bind down-mouse-1 to

        * cus-edit.el (custom-mode-map): Remove mouse-1 binding.
        (custom-mode): Update docstring.

        * cus-theme.el (custom-new-theme-mode-map): Remove mouse-1

It annoyed me since I usually click mouse-1 on an Emacs frame in
order to move the point, to select the frame, to copy text, etc.
When I click a url string accidentally, the web browser launches
regardless of my will.  I was often vexed by this and now I have:

(eval-after-load "wid-edit"
  '(define-key widget-keymap [down-mouse-1] nil))

Because of the default value of `mouse-1-click-follows-link',
mouse-1 click behaves like moude-2 now even if there is no
mouse-1 binding in `widget-keymap'.  Why don't we remove it from


[1] `gnus-article-add-buttons' adds a widget button if
`gnus-treat-buttonize' is non-nil (the default).

[2] `gnus-article-mode-map' is set so that its parent is

reply via email to

[Prev in Thread] Current Thread [Next in Thread]