GNU bug report logs - #52
FW: [mouse-1 in Customize should respect mouse-1-click-follows-link]

Previous Next

Full log

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <52 <at> debbugs.gnu.org>
Subject: FW: bug#52: FW: [mouse-1 in Customize should respect
	mouse-1-click-follows-link]
Date: Thu, 27 Oct 2011 14:13:40 -0700

> From: Chong Yidong Sent: Thursday, July 07, 2011 12:03 PM
>
> Since Emacs 23, links in the Customize buffer have obeyed
> mouse-1-click-follows-link, via custom-mode-link-map.

So it's a regression starting in Emacs 23. ;-)

Actually, the binding is made in `widget-keymap', which is the grandparent of
`custom-mode-link-map'.  But I thought anyway, from looking at the code, that
`custom-mode-link-map' would be the right one to adjust, to change behavior for
this.  But apparently I was wrong - see below.

> The other widget buttons used by Customize, like the Exit button, are
> always activated with mouse-1, regardless of 
> mouse-1-click-follows-link.  But this is the correct behavior,
> since those are not links.
>
> So this is a zombie bug report.  I'm closing it.

You don't give users the choice (easily).  They should be able to control this
via `mouse-1-click-follows-link'.  They should not have to also modify
`custom-mode-link-map' (or, in face, `widget-keymap') directly.

Help buffers have links on function names etc.  Mouse-1 on those links respects
`mouse-1-click-follows-link'.  My code adds links also to function names etc. in
Customize doc strings - same idea as Help.  Those too should respect the user
option.

It's not even clear to me how to control this.  I tried this at first:

(add-hook 'Custom-mode-hook
          (lambda ()
           (define-key custom-mode-link-map
            [mouse-1] 'mouse-set-point)
           (define-key custom-mode-link-map
            [down-mouse-1] 'mouse-drag-region)))

And it didn't work, but I'm not sure why (still).
Keymap `custom-mode-link-map' correctly had this:

<down-mouse-1>  mouse-drag-region
<mouse-1>       mouse-set-point

But clicking mouse-1 on link/button text had this effect:

As soon as mouse-1 was pressed (not released), the face changed to an inset
(depressed) face.  And as soon as mouse-1 was released, the link was followed
(and the face restored).

The inset face looks like `custom-button-pressed', the local value of
`widget-button-pressed-face', and `widget-button-click' was in fact called
(why?).  The debugger said that `widget-button-click' was called interactively
(but it is not bound to any key).

If I did `C-u C-x =' on a link, the help said that the keymap property was nil,
the follow-link property was `mouse-face', and the button property was
`documentation-link (widget)Top'.

And mouse-1 was still bound to `mouse-set-point', etc.!  And it didn't matter
whether the click was quick or I held mouse-1 depressed for a while (to wait out
some timeout).

Actually, if I did something in another app and then came back and clicked
mouse-1 on a link, the first click _sometimes_ did nothing but set point, but
thereafter the other behavior returned (depressed-button face, follow link
etc.).  

This behavior is still a mystery to me.

I eventually got it done by binding the mouse keys in `widget-keymap' instead of
`custom-mode-link-map' in the hook.  Why I would need to do that, I have no
idea.  Do you have an idea?

What's clear is that it is not very clear how a user can easily prevent mouse-1
from following such links in Customize.

And I still don't understand why you don't let the option
`mouse-1-click-follows-link' control this, just as it does in all other buffers.
Why should Customize be handled differently from *Help* etc.?

Previous Next

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