[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52: FW: bug#52: FW: [mouse-1 in Customize should respect mouse-1-cli
From: |
Drew Adams |
Subject: |
bug#52: 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.?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#52: FW: bug#52: FW: [mouse-1 in Customize should respect mouse-1-click-follows-link],
Drew Adams <=