bug#52: FW: [mouse-1 in Customize should respectmouse-1-click-follows-link]

["Drew Adams" <drew.adams@oracle.com>]

> 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.