[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-li
From: |
Drew Adams |
Subject: |
bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link] |
Date: |
Sun, 30 Oct 2011 07:46:29 -0700 |
> I can't reproduce this. With emacs -Q, and doing M-x customize,
> dragging `mouse-1' across (say) the "Undo edits" buffer selects that
> text, without enabling the button.
I see that too for emacs -Q. So what?
1. _Clicking_, not dragging, mouse-1 on `Undo edits' or `INS' or `State' _does_
activate the button. No matter how long you hold mouse-1 depressed.
`mouse-1-click-follows-links' is supposed to affect mouse-1 clicks, and a nil
value is supposed to return you to the same (sane) behavior Emacs had before Dev
started making mouse-1 follow links at all.
> Similarly for links.
No again. In emacs -Q, with nil `mouse-1-click-follows-link', press mouse-1 on
`Hide' and hold it there as long or as short a time as you like (without
dragging). The `Hide' "link" is still followed (or the "button" is activated)
when you release the button. Mouse-1 click is following links, in spite of the
option value.
2. To reproduce the problem as I reported it in doc strings, with emacs -Q:
(setq mouse-1-click-follows-link nil)
(defcustom foo-fns ()
"Some possibilities:
`foobar', `toto'"
:type '(repeat symbol) :group 'edit)
(defun foobar ()
"Foobar's doc string"
42)
M-x customize-option foo-fns
In the doc string, `foobar' is highlighted when you mouseover it. It is a link.
Click mouse-1 on it (you might sometimes have to click twice, but not a
double-click). Help opens. QED.