Re: follow-link in grep buffer

[David Kastrup]

Jason Rumney <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> I forgot: when we discussed the possible desirable behaviors, was
>> follow-link-on-double-click among it?  Isn't that sort of common
>> for launching something?  It would of course shadow marking a word
>> in a link, but I guess that is less tragic than losing the obvious
>> way of setting point?
>
> Except for links in info pages, which are clearly like HTML links,
> thus users probably expect them to be followed by a single click, I
> think making double click the default would be preferable, maybe
> with mouse-2 as an alternative for users used to the old way.
>
> I find the current default problematic in grep/compile buffers and
> Gnus Group and Summary windows, since I often use the mouse to
> switch windows, but clicking in those buffers (which are entirely
> made up of clickable text) does more than just position the cursor
> now.

With the current scheme IIRC, links had to be marked explicitly as
such to get the new behavior, to be on the safe side.  But I do think
that interpreting the mouse-double-click-event in the case that a
mouse-2 event is defined at a "more local" keymap could be reasonably
done unambigously.

One example I brought up was the images from preview-latex which are
also text editing entities you want to be able to move to with a
single click.  So it would not be a good idea to give them the link
property under the current scheme.  However, double-clicking on it, as
the equivalent of its current mouse-2 binding, would quite naturally
open and close the preview.  And a double click is by far more
accessible on many mouses or trackpads than a mouse-2 (which might
entail pressing a slippery wheel or chording two buttons).

I think it could be justified to do this remapping in general as long
as there is no explicit double-click binding.

> Equivalent windows to the compile window in other IDEs tend to use a
> double click.

This behavior basically would mean that we would remove the "link"
property from most packages where it has been introduced now, keeping
it just for really HTML-feeling links like in Info, and for explicit
buttons (like those in Customize): one does not expect to need to
double-click buttons.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum