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

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

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> These are links. They should be controlled by `mouse-1-click-follows-link'.

[...]

>> Click mouse-1 on a link in a Customize buffer that is a link to
>> another option name or similar. That is, on text between `' that is
>> highlighted with mouseover (`mouse-face').  The link is followed.
>> 
>> The link should not be followed by `mouse-1' if
>> `mouse-1-click-follows-link' is nil.  In that case, only clicking
>> `mouse-2' should follow the link.

That sounds logical.

The actual key binding in these buffers for the mouse is:

<down-mouse-1>	widget-button-click
<down-mouse-2>	widget-button-click

How is `mouse-1-click-follows-link' generally supposed to work?  Is
`widget-button-click' supposed to not do its thing if
`mouse-1-click-follows-link' is nil?  That seems rather yucky.  Or is
the mode not supposed to bind `down-mouse-1' to anything if it's nil?

That variable is unknown to me.  The documentation says:

------
This feature only works in modes that specifically identify
clickable text as links, so it may not work with some external
packages.  See `mouse-on-link-p' for details.
------

Customize can't be said to be an "external package".  :-)  

`mouse-on-link-p' says:

------
A clickable link is identified by one of the following methods:

- If the character at POS has a non-nil `follow-link' text or
overlay property, the value of that property determines what to do.

- If there is a local key-binding or a keybinding at position POS
for the `follow-link' event, the binding of that event determines
what to do.
------

And the widget stuff does put `follow-link' on stuff.  So how is this
supposed to tie together?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Drew Adams]

Thanks for looking at this, Lars.

I'm no expert on how this works or is supposed to work.

A (blind) guess would be that the problem is that these are perhaps not
considered to be "links" by the Customize code.  Dunno.

Emacs can be fussy about what it considers to be a link.  Some of the things
called "buttons" in the code are in fact links from a user viewpoint.  (But some
of them are not - they are truly action buttons.)

Someone more knowledgable than I will need to help here, I'm afraid.

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

[Stefan Monnier]

>>> Click mouse-1 on a link in a Customize buffer that is a link to
>>> another option name or similar. That is, on text between `' that is
>>> highlighted with mouseover (`mouse-face').  The link is followed.

Yes, Custom has always used mouse-1 clicks for that purpose, AFAIK.

> The actual key binding in these buffers for the mouse is:

> <down-mouse-1>	widget-button-click
> <down-mouse-2>	widget-button-click

> How is `mouse-1-click-follows-link' generally supposed to work?  Is

This is supposed to let mouse-1 clicks follow links otherwise only
accessible via mouse-2 clicks (i.e. when there's no binding for mouse-1
on this button/link).

It relies on the `follow-link' text-property and/or key binding to
specifies when this fallback is applicable.

That was introduced in reaction to people complaining about the
non-standard Emacs convention of using mouse-2 to follow links.
But actually some part of Emacs already used mouse-1 to follow links,
such as Customize, so these aren't affected by
mouse-1-click-follows-link.

I think in this present case, Custom should better follow Emacs
conventions and hence only bind mouse-2 and then rely on the follow-link
feature to make mouse-1 also work for those users who like it.


        Stefan

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think in this present case, Custom should better follow Emacs
> conventions and hence only bind mouse-2 and then rely on the follow-link
> feature to make mouse-1 also work for those users who like it.

That sounds like a good idea.  I've had a go at doing this, but I'm
afraid I wasn't able to make it work.  Somebody who knows more about
`follow-link' and customize should have a look at it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Chong Yidong]

The original report concerned only Emacs 22:

>> Click mouse-1 on a link in a Customize buffer that is a link to
>> another option name or similar. That is, on text between `' that is
>> highlighted with mouseover (`mouse-face').  The link is followed.
>>
>> In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
>>  of 2007-06-02 on RELEASE

Since Emacs 23, links in the Customize buffer have obeyed
mouse-1-click-follows-link, via custom-mode-link-map.

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.

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

[Drew Adams]

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

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

[Drew Adams]

Well, it turns out that that is no solution anyway.  If I do that then even the
real buttons (the rectangular, raised ones) in Customize do not react to
mouse-1.

Sigh.

Why are links treated the same as buttons in Customize?  Maybe that's the
question.  Dunno.

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

[Drew Adams]

> Well, it turns out that that is no solution anyway.  If I do 
> that then even the real buttons (the rectangular, raised ones)
> in Customize do not react to mouse-1.
> 
> Sigh.
> 
> Why are links treated the same as buttons in Customize?  
> Maybe that's the question.  Dunno.

I want, as before, links to work only with mouse-2, but buttons and menu items
to work with mouse-1.  It seems that's no longer possible (?).

Using the hook I showed, I can use mouse-2 (only) for links (buttons too,
unfortunately), but it seems that mouse-1 (only) is hard-coded for menu items.
So I can use mouse-2 on the State button to open its menu, but then must switch
to mouse-1 to choose a menu item.

I want to be able to select text normally using mouse-1 and mouse-3 etc.,
including text that is linked.  I want to be able to click mouse-2 (only) to
follow links. I want to be able to use mouse-1 for both buttons and menu items.

This is nuts.  Why is it so messy?

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

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> I want to be able to select text normally using mouse-1 and mouse-3
> etc., including text that is linked.

Nothing prevents you from doing this.

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

[Drew Adams]

> > I want to be able to select text normally using mouse-1 and mouse-3
> > etc., including text that is linked.
> 
> Nothing prevents you from doing this.

Yeah, how?  See what I wrote.  `mouse-1', held down for no matter how long,
follows links and buttons in Customize.  It does not do this anywhere outside of
Customize.

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

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>>
>> Nothing prevents you from doing this.
>
> Yeah, how?  See what I wrote.  `mouse-1', held down for no matter how
> long, follows links and buttons in Customize.  It does not do this
> anywhere outside of Customize.

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.  Similarly for links.

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

[Drew Adams]

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

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

[Drew Adams]

ping