follow-link in grep buffer

follow-link in grep buffer

[Nick Roberts]

I realise that applications like web browsers use mouse-1 to follow links, so
it is a good idea for Emacs to provide some consistency and it works well with
Info pages. However, I am not sure if it is always appropriate as Emacs users
understand that mouse-1 just generally moves the cursor, while mouse-2 might
jump to another buffer. The grep buffer is an example. If I try to place the
cursor anywhere on a line before the end of a match, the associated file
pops up in another buffer. However I might just want to select that window
to resize it. I could select the window by clicking on the modeline but if I
click on the wrong part I get a different buffer. All this functionality must
be daunting for the new user, so I suggest the following:

1) Mouse-1 is not used to follow links in the grep or compilation buffers.

2) If it has to be used for this purpose, then it only works where the match
   occurs (this must be easy to implement as it already has a different face)
   and the match is also underlined so that it looks like a link.


Nick

Re: follow-link in grep buffer

[Stefan Monnier]

> I realise that applications like web browsers use mouse-1 to follow links, so
> it is a good idea for Emacs to provide some consistency and it works well with
> Info pages. However, I am not sure if it is always appropriate as Emacs users
> understand that mouse-1 just generally moves the cursor, while mouse-2 might
> jump to another buffer. The grep buffer is an example. If I try to place the
> cursor anywhere on a line before the end of a match, the associated file
> pops up in another buffer. However I might just want to select that window
> to resize it. I could select the window by clicking on the modeline but if I
> click on the wrong part I get a different buffer. All this functionality must
> be daunting for the new user, so I suggest the following:

> 1) Mouse-1 is not used to follow links in the grep or compilation buffers.

> 2) If it has to be used for this purpose, then it only works where the match
>    occurs (this must be easy to implement as it already has a different face)
>    and the match is also underlined so that it looks like a link.

Based on your example, I'd say another option might be:
- if the click is used to give focus, then don't follow the link.


        Stefan "who uses focus-follows-mouse and thus doesn't suffer from
                this problem (or suffers from it all the time and thus
                doesn't expect such things not to happen)"

Re: follow-link in grep buffer

[Nick Roberts]

 > Based on your example, I'd say another option might be:
 > - if the click is used to give focus, then don't follow the link.

Given that if you press the button longer it also doesn't follow the link, the
tooltip tells you that it does, even without focus, and doesn't mention that
mouse-2 does the job too (it's masked by mouse-1), I think it would only
create further confusion.


Nick

RE: follow-link in grep buffer

[Drew Adams]

     > Based on your example, I'd say another option might be:
     > - if the click is used to give focus, then don't follow the link.

    Given that if you press the button longer it also doesn't
    follow the link, the
    tooltip tells you that it does, even without focus, and doesn't
    mention that
    mouse-2 does the job too (it's masked by mouse-1), I think it would only
    create further confusion.

I made the same suggestion as Stefan, and I don't think it would lead to
further confusion. As I mentioned, that is pretty much the behavior that
Windows users experience every day (the first click establishes focus). And
I can testify that it has saved my derriere more than once, when I
accidentally clicked something (e.g. button) in a window that didn't have
the focus. Of course, mouse-follows-focus would no doubt overrule this
behavior, so it wouldn't help in that case.

Re: follow-link in grep buffer

[Kim F. Storm]

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

>      > Based on your example, I'd say another option might be:
>      > - if the click is used to give focus, then don't follow the link.

> I made the same suggestion as Stefan, and I don't think it would lead to
> further confusion. As I mentioned, that is pretty much the behavior that
> Windows users experience every day (the first click establishes focus). And

This makes sense!

I just installed a change so that a mouse-1 click only follows a link
if the window is already selected.

The tooltip will now say to use mouse-2 to follow a link in a
non-selected window and to use mouse-1 in a selected window.

BTW, I hate double-clicks...

> Of course, mouse-follows-focus would no doubt overrule this
> behavior, 

It does.

>           so it wouldn't help in that case.

With mouse-autoselect-window / mouse-follows-focus you don't need
to click in the first place, so I don't see a "need to help" here.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[Stefan Monnier]

>> I made the same suggestion as Stefan, and I don't think it would lead to
>> further confusion. As I mentioned, that is pretty much the behavior that
>> Windows users experience every day (the first click establishes focus). And

> This makes sense!

> I just installed a change so that a mouse-1 click only follows a link
> if the window is already selected.

I can't test it right now, so just so we're clear:

What happens in the following scenario:

- I'm working in Emacs's frame Foo, window Foo, showing buffer Foo.
  It's actually the only buffer/window/frame of this Emacs.
- I switch to an xterm by clicking on its window.
- I switch back to Emacs by mouse-1 clicking inside its window.

Is that going to correctly "ignore" this last mouse-1 click other than make
it change focus) because, from Emacs's point of view, the window Foo has
always been and still is the selected window?


        Stefan

Re: follow-link in grep buffer

[Kim F. Storm]

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

>>> I made the same suggestion as Stefan, and I don't think it would lead to
>>> further confusion. As I mentioned, that is pretty much the behavior that
>>> Windows users experience every day (the first click establishes focus). And
>
>> This makes sense!
>
>> I just installed a change so that a mouse-1 click only follows a link
>> if the window is already selected.
>
> I can't test it right now, so just so we're clear:
>
> What happens in the following scenario:
>
> - I'm working in Emacs's frame Foo, window Foo, showing buffer Foo.
>   It's actually the only buffer/window/frame of this Emacs.
> - I switch to an xterm by clicking on its window.
> - I switch back to Emacs by mouse-1 clicking inside its window.
>
> Is that going to correctly "ignore" this last mouse-1 click other than make
> it change focus) because, from Emacs's point of view, the window Foo has
> always been and still is the selected window?

It depends on whether you have set x-mouse-click-focus-ignore-position
(on systems which support it).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[Kim F. Storm]

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

> Is that going to correctly "ignore" this last mouse-1 click other than make
> it change focus) because, from Emacs's point of view, the window Foo has
> always been and still is the selected window?

In any case, you can always use a "long click" or drag the mouse
to avoid following the link...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

RE: follow-link in grep buffer

[Drew Adams]

    I just installed a change so that a mouse-1 click only follows a link
    if the window is already selected.

    The tooltip will now say to use mouse-2 to follow a link in a
    non-selected window and to use mouse-1 in a selected window.

I don't think it's a good idea to put the info about mouse-2 in the tooltip
here; I would leave it out, to simplify the explanation.

Using mouse-2 to select a link in a non-selected window is not necessary,
anyway - users can just click mouse-1 to select the window first. Keeping
this extra info in the tooltip will only confuse novices (and others). Users
quickly get used to the Windows behavior without any explanation that their
first click in a non-selected window does not follow a clicked link.

Re: follow-link in grep buffer

[Jason Rumney]

Nick Roberts <nickrob@snap.net.nz> writes:

> Given that if you press the button longer it also doesn't follow the
> link, the tooltip tells you that it does, even without focus, and
> doesn't mention that mouse-2 does the job too (it's masked by
> mouse-1), I think it would only create further confusion.

Relying on tooltips to tell the user important information like this
is what causes confusion. I've never noticed this, probably I don't
leave the mouse over the clickable link long enough for a tooltip to
pop-up, because I am not expecting to need to know more information.

RE: follow-link in grep buffer

[Drew Adams]

    I realise that applications like web browsers use mouse-1 to
    follow links, so
    it is a good idea for Emacs to provide some consistency and it
    works well with
    Info pages. However, I am not sure if it is always appropriate
    as Emacs users
    understand that mouse-1 just generally moves the cursor, while
    mouse-2 might
    jump to another buffer. The grep buffer is an example. If I try
    to place the
    cursor anywhere on a line before the end of a match, the associated file
    pops up in another buffer. However I might just want to select
    that window
    to resize it. I could select the window by clicking on the
    modeline but if I
    click on the wrong part I get a different buffer. All this
    functionality must
    be daunting for the new user, so I suggest the following:

    1) Mouse-1 is not used to follow links in the grep or
    compilation buffers.

    2) If it has to be used for this purpose, then it only works
    where the match
       occurs (this must be easy to implement as it already has a
    different face)
       and the match is also underlined so that it looks like a link.

Y'know, I knew this would come up sooner or later.

I believe that the idea was to have the mouse-1 follow-links (and activate
buttons) behavior be a user option. (I'm not sure what I prefer in this
regard, as a user.) It's good for Emacs to act like other apps in this
regard, as long as that doesn't impact functionality or cause other pbs. But
you are absolutely correct that mouse-1 following links (and activating
action buttons) will make it difficult to just select a buffer with the
mouse, whenever that buffer is link-dense (or button-dense).

One possibility that occurs to me now is to have a mouse-1 click in a window
other than the selected-window act as mouse-1 does now: just set point. That
is, the first mouse-1 click just sets point and selects the window; only
thereafter would mouse-1 follow links.

That is similar to the behavior I see in Windows, where clicking mouse-1 on
a (WM) window that doesn't have the focus just shifts the focus: If you
click a button (for example) in a window that doesn't have the focus, the
window is selected, but the button is not activated (you must click it
again, after the window has the focus, for it to take effect).

This would not completely solve the problem you raise: You could not use
mouse-1 to move point to a different part of the same, focused window. But
the time-delay approach that was proposed a few months ago (by Kim?) would
presumably address that pb. I think the idea there is that if you want to
set point with mouse-1, then you just hold mouse-1 pressed longer than some
(user-settable?) time limit, before releasing it.

Re: follow-link in grep buffer

[Luc Teirlinck]

Drew Adams wrote:

   I believe that the idea was to have the mouse-1 follow-links (and activate
   buttons) behavior be a user option.

You mean `mouse-1-click-follows-link'?  It _is_ a user option.  I
personally have it set to nil.  But the default value uses the new
behavior.

Sincerely,

Luc.

Re: follow-link in grep buffer

[Nick Roberts]

 >    I believe that the idea was to have the mouse-1 follow-links (and activate
 >    buttons) behavior be a user option.
 > 
 > You mean `mouse-1-click-follows-link'?  It _is_ a user option.  I
 > personally have it set to nil.  But the default value uses the new
 > behavior.

But I like it in Info. I'm just suggesting that it should be used more
conservatively.


Nick

Re: follow-link in grep buffer

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Drew Adams wrote:
>
>    I believe that the idea was to have the mouse-1 follow-links (and activate
>    buttons) behavior be a user option.
>
> You mean `mouse-1-click-follows-link'?  It _is_ a user option.  I
> personally have it set to nil.  But the default value uses the new
> behavior.

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?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link in grep buffer

[Luc Teirlinck]

David Kastrup wrote:

   I forgot: when we discussed the possible desirable behaviors, was
   follow-link-on-double-click among it?

I believe that setting the option to nil does that.

Sincerely,

Luc.

Re: follow-link in grep buffer

[Luc Teirlinck]

   I forgot: when we discussed the possible desirable behaviors, was
   follow-link-on-double-click among it?

Sorry, in my previous reply I misread `double-click' for mouse-2.  But
yes there is such a value.  You have to set it to 'double.

Sincerely,

Luc.

Re: follow-link in grep buffer

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

>    I forgot: when we discussed the possible desirable behaviors, was
>    follow-link-on-double-click among it?
>
> Sorry, in my previous reply I misread `double-click' for mouse-2.
> But yes there is such a value.  You have to set it to 'double.

Actually, I was not talking about _configurable_ behaviors (though it
is nice to know that it is configurable) but about the possibly best
default setting.  This "double click to launch" used to be a pretty
common idiom at one time, though browsers have watered it down in some
contexts.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: follow-link in grep buffer

[Drew Adams]

    This "double click to launch" used to be a pretty common idiom at one
time,
    though browsers have watered it down in some contexts.

FWIW - I'm not an expert on this, but I believe that in Windows the single-
vs double-click-follows/activates behavior is a user option. I would guess
(but don't know) that most Windows users now use the single-click behavior.
I don't know if following links and other actions (e.g. open) follow the
same principle (option value).

Perhaps someone else can speak to this more authoritatively.

Re: follow-link in grep buffer

[Luc Teirlinck]

   David Kastrup wrote:

      I forgot: when we discussed the possible desirable behaviors, was
      follow-link-on-double-click among it?

   I believe that setting the option to nil does that.

That was, as I already said, the result of misreading `double-click'
for mouse-2.  If you set it to nil, you have to use mouse-2 to follow
links.

Sincerely,

Luc.

Re: follow-link in grep buffer

[Jason Rumney]

David Kastrup <dak@gnu.org> 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.

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

Re: follow-link in grep buffer

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup <dak@gnu.org> 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

RE: follow-link in grep buffer

[Drew Adams]

       I believe that the idea was to have the mouse-1 follow-links 
       (and activate buttons) behavior be a user option.
    
    You mean `mouse-1-click-follows-link'?  It _is_ a user option.  I
    personally have it set to nil.  But the default value uses the new
    behavior.

Yes, that's what I meant. 

Re: follow-link in grep buffer

[Lennart Borgman]

----- Original Message ----- 
From: "Nick Roberts" <nickrob@snap.net.nz>

> I realise that applications like web browsers use mouse-1 to follow links,
so
...
> be daunting for the new user, so I suggest the following:
>
> 1) Mouse-1 is not used to follow links in the grep or compilation buffers.
>
> 2) If it has to be used for this purpose, then it only works where the
match
>    occurs (this must be easy to implement as it already has a different
face)
>    and the match is also underlined so that it looks like a link.

Alternative 2 seems more consistent (and therefore less confusing) to me.

Re: follow-link in grep buffer

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

> I realise that applications like web browsers use mouse-1 to follow
> links, so it is a good idea for Emacs to provide some consistency
> and it works well with Info pages. However, I am not sure if it is
> always appropriate as Emacs users understand that mouse-1 just
> generally moves the cursor, while mouse-2 might jump to another
> buffer. The grep buffer is an example. If I try to place the cursor
> anywhere on a line before the end of a match, the associated file
> pops up in another buffer.

Press the button for longer.  That avoids following the link.  How to
teach this best is a different question.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link in grep buffer

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Press the button for longer.  That avoids following the link.  How to
> teach this best is a different question.

View at it like this:  

	Press the mouse button "harder" (i.e. longer)
	to make it stick where you click.


Here's the relevant doc string:

mouse-1-click-follows-link's value is 300

Non-nil means that clicking Mouse-1 on a link follows the link.

With the default setting, an ordinary Mouse-1 click on a link
performs the same action as Mouse-2 on that link, while a longer
Mouse-1 click (hold down the Mouse-1 button for more than 350
milliseconds) performs the original Mouse-1 binding (which
typically sets point where you click the mouse).

If value is an integer, the time elapsed between pressing and
releasing the mouse button determines whether to follow the link
or perform the normal Mouse-1 action (typically set point).
The absolute numeric value specifices the maximum duration of a
"short click" in milliseconds.  A positive value means that a
short click follows the link, and a longer click performs the
normal action.  A negative value gives the opposite behaviour.

If value is `double', a double click follows the link.

Otherwise, a single Mouse-1 click unconditionally follows the link.

Note that dragging the mouse never follows the link.

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.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[Luc Teirlinck]

   If value is an integer,...

   If value is `double', a double click follows the link.

   Otherwise, a single Mouse-1 click unconditionally follows the link.

Would "For any other non-nil value," not be clearer than "Otherwise,"
which seems to include _all_ other possibilities, including nil.

Sincerely,

Luc.

Re: follow-link in grep buffer

[Richard Stallman]

    The grep buffer is an example. If I try to place the
    cursor anywhere on a line before the end of a match, the associated file
    pops up in another buffer. However I might just want to select that window
    to resize it.

When you found this not to your taste, were you aware about the aspect
that Mouse-1 does not follow links if you move the mouse at all?
Is that method of avoiding the problem adequate?

Stefan wrote:

    Based on your example, I'd say another option might be:
    - if the click is used to give focus, then don't follow the link.

I would not object to that, if the other developers find it
convenient, and assuming that "move the mouse" is not an adequate
solution for your problem.

Re: follow-link in grep buffer

[Nick Roberts]

 >     The grep buffer is an example. If I try to place the cursor anywhere on
 >     a line before the end of a match, the associated file pops up in
 >     another buffer. However I might just want to select that window to
 >     resize it.
 > 
 > When you found this not to your taste, were you aware about the aspect
 > that Mouse-1 does not follow links if you move the mouse at all?

No. I wasn't aware of that. With the default setting, the user would have to
move the mouse and release it within 350 milliseconds for it to have any
effect. I  think must be quite hard to do.

 > Is that method of avoiding the problem adequate?

My preferences remained unchanged but I also think it must be confusing for
a novice user. Before I was aware of the time limit, I didn't understand why
clicking mouse-1 sometimes popped to a new buffer and other times didn't.


Nick

Re: follow-link in grep buffer

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  >     The grep buffer is an example. If I try to place the cursor anywhere on
>  >     a line before the end of a match, the associated file pops up in
>  >     another buffer. However I might just want to select that window to
>  >     resize it.
>  > 
>  > When you found this not to your taste, were you aware about the aspect
>  > that Mouse-1 does not follow links if you move the mouse at all?
>
> No. I wasn't aware of that. With the default setting, the user would have to
> move the mouse and release it within 350 milliseconds for it to have any
> effect. I  think must be quite hard to do.
>
>  > Is that method of avoiding the problem adequate?
>
> My preferences remained unchanged but I also think it must be
> confusing for a novice user. Before I was aware of the time limit, I
> didn't understand why clicking mouse-1 sometimes popped to a new
> buffer and other times didn't.

I am afraid that the same is the case here.  I have
focus-follows-mouse set here by default in the window manager, so I
don't expect clicks that don't do anything.  The current behavior
(where a window change does not follow links at all) is more confusing
than the previous one.

Kim, I am aware that you hate double clicks.  However, for the
I-hate-something proponents there is always the possibility of using
customize to change the default.

In order not to confuse people too much, I really would want to
suggest strongly that we remap double-click to mouse-2 unconditionally
by default (where a "stronger" mouse-2 binding exists), and also map
mouse-1 to the same when the special "link" property is present.  This
property would only be present in clearly "clickable" situations such
as buttons or Info references, but not where there is basically normal
text with clickable properties (like in a grep buffer or in the
headers of gnus buffers).

A double click can never be confused with a "click just to shift
point/focus".  It is conveniently available on even single-key mouses
and its behavior does not need 5 sentences to explain.  The confusion
potential is just with mark-word, and that is tolerable in clickable
situations.

The current scheme also steals the potential to double-click, anyway,
since the first short click already follows the link, and a
double-click by click and hold long, then leave the button very short
and click again, this time short...  that's not something you manage
if you are not a piano player, anyway.

It's nice if everything else we have tried out is available as a
customizable option, but by default, I think we should remap only the
double click when not asked for, and the normal single click (of _any_
duration) when asked for.

Secret timing differences and stuff like that are much too subtle
_unless_ the user configured them himself, in which case he'd know
about them.

That is the default behavior of most applications, and I don't see
that the alternatives we have tried so far would be so much better as
to warrant getting people used to them instead.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link in grep buffer

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>> My preferences remained unchanged but I also think it must be
>> confusing for a novice user. Before I was aware of the time limit, I
>> didn't understand why clicking mouse-1 sometimes popped to a new
>> buffer and other times didn't.
>
> I am afraid that the same is the case here.  I have
> focus-follows-mouse set here by default in the window manager, so I
> don't expect clicks that don't do anything.  The current behavior
> (where a window change does not follow links at all) is more confusing
> than the previous one.

This really hasn't anything to do with focus-follows-mouse.

What if you set mouse-autoselect-window ?


In any case, I agree that last modification isn't perfect, and
I'll think about what to do.



>
> Kim, I am aware that you hate double clicks.  However, for the
> I-hate-something proponents there is always the possibility of using
> customize to change the default.
>
> In order not to confuse people too much, I really would want to
> suggest strongly that we remap double-click to mouse-2 unconditionally
> by default (where a "stronger" mouse-2 binding exists), and also map
> mouse-1 to the same when the special "link" property is present.  This
> property would only be present in clearly "clickable" situations such
> as buttons or Info references, but not where there is basically normal
> text with clickable properties (like in a grep buffer or in the
> headers of gnus buffers).

IMO, this has nothing to do with the default of
mouse-1-click-follows-link.  It is a problem of those modes which
basically make large parts of a buffer mouse-2 click-able and then
uses a too primitive form of the `follow-link' functionality.

So grep and gnus should not just say that mouse-1 blindly maps to
mouse-2.

> The current scheme also steals the potential to double-click, anyway,
> since the first short click already follows the link, and a
> double-click by click and hold long, then leave the button very short
> and click again, this time short...  that's not something you manage
> if you are not a piano player, anyway.

If so, it is a bug.

The code specifically tests to see if there is a second click within
double-click-time and generates a double click rather than two
separate clicks.

>
> It's nice if everything else we have tried out is available as a
> customizable option, but by default, I think we should remap only the
> double click when not asked for, and the normal single click (of _any_
> duration) when asked for.

So change grep and gnus...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[Stefan Monnier]

I vote to change mouse-1-click-follows-link to `double'.


        Stefan

Re: follow-link in grep buffer

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>

> I vote to change mouse-1-click-follows-link to `double'.

>From a usability point I do not like double-clicks. If most links are single
click links (and they are in a web browser) I think we should as far as
possible use single-clicks for links.

I like Drews suggestion that the first click gives focus only. A problem
with this is however that (at least on w32) Emacs is not very consistent and
fast on showing an hourglass when working and that may be confusing.

Another problem if Drews suggestion is used is perhaps if the first click
should give focus only when the frame does not have focus or when the window
does not have focus.

Re: follow-link in grep buffer

[Kim F. Storm]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> ----- Original Message ----- 
> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
>
>> I vote to change mouse-1-click-follows-link to `double'.
>
>>From a usability point I do not like double-clicks. If most links are single
> click links (and they are in a web browser) I think we should as far as
> possible use single-clicks for links.
>
> I like Drews suggestion that the first click gives focus only. A problem
> with this is however that (at least on w32) Emacs is not very consistent and
> fast on showing an hourglass when working and that may be confusing.

In X, we have this:

x-mouse-click-focus-ignore-position's value is t

Non-nil means that a mouse click to focus a frame does not move point.
This variable is only used when the window manager requires that you
click on a frame to select it (give it focus).  In that case, a value
of nil, means that the selected window and cursor position changes to
reflect the mouse click position, while a non-nil value means that the
selected window or cursor position is preserved.

I suppose a similar thing could be implemented in other ports, but I'm
don't know how to do that.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[Andreas Schwab]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> ----- Original Message ----- 
> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
>
>> I vote to change mouse-1-click-follows-link to `double'.
>
>>From a usability point I do not like double-clicks. If most links are single
> click links (and they are in a web browser) I think we should as far as
> possible use single-clicks for links.

But Emacs is not a browser, but an editor, the the most common operation
in an editor for a single click is to set point, not to follow links.

> I like Drews suggestion that the first click gives focus only.

I never have to click to focus.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: follow-link in grep buffer

[Kim F. Storm]

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

> I vote to change mouse-1-click-follows-link to `double'.

The whole point of mouse-1-click-follows-link is to make emacs behave
like most other (modern) applications. 

Double click to follow a link is not modern!

If we have specific problems in certain modes, let's fix those
modes (e.g. in grep that you have to click on the file:line
part of a line to jump).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I vote to change mouse-1-click-follows-link to `double'.
>
> The whole point of mouse-1-click-follows-link is to make emacs behave
> like most other (modern) applications. 
>
> Double click to follow a link is not modern!

This is a misstatement of the goal.  The problem we are addressing in
the first place is that mouse-2 to follow anything is neither modern
nor oldfashioned elsewhere, but completely uncustomary.

Now the "modern" way is to follow links/buttons with a single click,
and I say that we should provide for this in the manner you did: with
an explicit link property enabling this redirection of the otherwise
mouse-2 behavior.

However, for following "easter eggs", namely causing an action where
an action is not usual, like in editing buffers, double clicks are
still quite common.  For those, I would recommend _not_ to set a link
property, but _still_ redirect a double-click to the mouse-2 behavior,
in a similar manner to what your first proposal was.

I would recommend not making any behavior by default dependent on the
single-click length, nor on the focus situation: both approaches are
completely obfuscate and confusing.

So the change to 21.4 behavior would be the following:

a) a double-click on a location that has no double-click binding, but
   a local mouse-2 binding, will execute the mouse-2 binding.  This
   will make double-clicks, where not overriden, follow links without
   further code changes compared to 21.4
b) setting an explicit link property will _additionally_ remap mouse-1
   to mouse-2.  I would not by default make this dependent on anything
   else.

It is obvious from this description that making a larger text area
have an explicit link property would be a mistake, as you would then
get into difficulties positioning the cursor.  As long as only short
buttons and links are concerned, it is tolerably easy and logical to
click before or after the button/link, and then move into it.  The
possibility of a small drag remains for the experienced user.

So grep should not set the link property in my opinion in this scheme,
and gnus should set it sparingly: on MIME buttons it generates itself,
but not on header lines or things looking like a link in the article
text.

> If we have specific problems in certain modes, let's fix those modes
> (e.g. in grep that you have to click on the file:line part of a line
> to jump).

That again requires cleverness.  I don't mind if we have customization
options for this sort of thing, but it is a mistake for the default.

I have a demonstration and workshop for Emacs coming up in the next
two weeks, where I want to tell people to use Emacs for their serious
editing needs.

Telling them "use mouse-2" has always been sort of embarrassing.
Telling them "use mouse-1, but don't press it longer than 200
milliseconds if you want to follow the link, and it won't work if you
have not the focus" will kill the "Emacs is usable for common human"
proposition dead.  Telling people "double click to follow some
possible cross connection" will make them feel at home.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link in grep buffer

[Reiner Steib]

On Fri, Feb 25 2005, David Kastrup wrote:

> I would recommend not making any behavior by default dependent on the
> single-click length, nor on the focus situation: both approaches are
> completely obfuscate and confusing.
>
> So the change to 21.4 behavior would be the following:
>
> a) a double-click on a location that has no double-click binding, but
>    a local mouse-2 binding, will execute the mouse-2 binding.  This
>    will make double-clicks, where not overriden, follow links without
>    further code changes compared to 21.4
> b) setting an explicit link property will _additionally_ remap mouse-1
>    to mouse-2.  I would not by default make this dependent on anything
>    else.

I agree with David's arguments and his suggestions.

I also find the current behavior confusing in some modes.  After
several week, I still sometimes follow the link when I intended to
select the window or set the point.

Some examples: In Gnus Group buffer, I often want to put the cursor on
a certain group and then I intend to do `C-u a' (post to group under
point), `10 RET' (show 10 article in that group), M-g (Check for new
news in the current topic.).  In PCL-CVS, I often want to put the
point on a file name and then do `=' (cvs-mode-diff), `l'
(cvs-mode-log) ...

Because I followed the discussions on emacs-devel, I remembered why
mouse-1 behaves like this, but I think for ordinary users it is really
surprising.

In modes like info, mouse-1 to follow a link is a good default.

> So grep should not set the link property in my opinion in this scheme,
> and gnus should set it sparingly: on MIME buttons it generates itself,
> but not on header lines or things looking like a link in the article
> text.

It should not be set (by default) in the group and summary buffer.  As
for the MIME buttons and other links in the article buffer: AFAICS,
these are the same kind of all "buttons", so it might require some
work.

[...]
> Telling them "use mouse-2" has always been sort of embarrassing.
> Telling them "use mouse-1, but don't press it longer than 200
> milliseconds if you want to follow the link, and it won't work if you
> have not the focus" will kill the "Emacs is usable for common human"
> proposition dead.

ACK.  In Gnus group buffer, I often found myself clicking too short so
that the key presses intended for the group buffer were executed in
the summary buffer and thus triggered completely different actions.

> Telling people "double click to follow some possible cross
> connection" will make them feel at home.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: follow-link in grep buffer

[Richard Stallman]

    a) a double-click on a location that has no double-click binding, but
       a local mouse-2 binding, will execute the mouse-2 binding.  This
       will make double-clicks, where not overriden, follow links without
       further code changes compared to 21.4

This means two different modes of operation
where at present we have just one.  A priori, that is undesirable.
It would have to be quite clear that users would like this better
and find it more natural.

By the way, I see that double-mouse-1 does not work on clickable
links.  The reason seems to be that a long click followed immediately
by a short one do not combine as a double click--regardless of the
text.  Is that correct behavior?

Re: follow-link in grep buffer

[Stefan Monnier]

> If we have specific problems in certain modes, let's fix those
> modes (e.g. in grep that you have to click on the file:line
> part of a line to jump).

AFAICT the specific problem at hand is that a mous-1 click used to get focus
should not follow a link.  No matter what kind of link, no matter the
major mode.

I think x-mouse-click-focus-ignore-position is pretty much the kind of thing
we want, although I'd have expected that the window-manager would take care
of those things (it should eat the "click-to-focus" and not pass it on to
the application).

But if such a thing is not possible a double-click sounds like the next
best thing.


        Stefan

Re: follow-link in grep buffer

[David Kastrup]

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

>> If we have specific problems in certain modes, let's fix those
>> modes (e.g. in grep that you have to click on the file:line
>> part of a line to jump).
>
> AFAICT the specific problem at hand is that a mous-1 click used to
> get focus should not follow a link.  No matter what kind of link, no
> matter the major mode.

That's not the only problem.  A mouse-1 click not used to get focus
should follow a link.  If it doesn't, that is surprising.  Now
click-to-focus is strictly a windowmanager and frame thingy.  While
one also uses the mouse for the purpose of changing the _window_
instead of the frame, one would be terribly surprised if this had not
the side effect of setting point, too.  Basically, one sets point into
a different window since that is the convenient way to change focus.

It is completely backwards if this side effect of a window change
leads to a link working or not working, namely if we _do_ set point,
but _don't_ follow the link.  With a true click-to-focus, we should
not even have the window-point change, merely the selected window.

All those semantics are far too clever.  It is an absolutely
horrifying thought to have to explain this to a bunch of beginners
with Emacs.  They'll just declare me crazy and be done.

> I think x-mouse-click-focus-ignore-position is pretty much the kind
> of thing we want, although I'd have expected that the window-manager
> would take care of those things (it should eat the "click-to-focus"
> and not pass it on to the application).

You are confusing frame and window.  Changing the selected window is
also necessary at times.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link in grep buffer

[Stefan Monnier]

>>> If we have specific problems in certain modes, let's fix those
>>> modes (e.g. in grep that you have to click on the file:line
>>> part of a line to jump).
>> 
>> AFAICT the specific problem at hand is that a mous-1 click used to
>> get focus should not follow a link.  No matter what kind of link, no
>> matter the major mode.

> That's not the only problem.  A mouse-1 click not used to get focus
> should follow a link.  If it doesn't, that is surprising.  Now
> click-to-focus is strictly a windowmanager and frame thingy.  While
> one also uses the mouse for the purpose of changing the _window_
> instead of the frame, one would be terribly surprised if this had not
> the side effect of setting point, too.  Basically, one sets point into
> a different window since that is the convenient way to change focus.

> It is completely backwards if this side effect of a window change
> leads to a link working or not working, namely if we _do_ set point,
> but _don't_ follow the link.  With a true click-to-focus, we should
> not even have the window-point change, merely the selected window.

AFAICT, the problem at hand is about frame-focus-changes, not about
window-focus-changes (Nick's message said "I might just want to select that
window to resize it" suggesting pretty clearly that he's talking about
frames rather than windows).

>> I think x-mouse-click-focus-ignore-position is pretty much the kind
>> of thing we want, although I'd have expected that the window-manager
>> would take care of those things (it should eat the "click-to-focus"
>> and not pass it on to the application).

> You are confusing frame and window.  Changing the selected window is
> also necessary at times.

No, I'm not confusing them, I was talking about frames (and never mentioned
the word "window"), tho I didn't make it explicit since I thought the
context was sufficiently clear.

BTW, in a click-to-focus environment (I'm still talking only about frames's
focus), I think it'd indeed also make sense (as Nick's message mentioned) to
ignore a click on a sensitive mode-line element if it was used to get focus.

Basically, any non-trivially-safe (point movement and window selection is
safe, most of the rest isn't) operation should not be triggered by
a click-to-focus.

Maybe the mouse-face should also be inactive on frames that don't
have focus.


        Stefan

Re: follow-link in grep buffer

[Lennart Borgman]

----- Original Message ----- 
From: "David Kastrup" <dak@gnu.org>

> > AFAICT the specific problem at hand is that a mous-1 click used to
> > get focus should not follow a link.  No matter what kind of link, no
> > matter the major mode.
>
> That's not the only problem.  A mouse-1 click not used to get focus
> should follow a link.  If it doesn't, that is surprising.  Now
> click-to-focus is strictly a windowmanager and frame thingy.  While
> one also uses the mouse for the purpose of changing the _window_
> instead of the frame, one would be terribly surprised if this had not
> the side effect of setting point, too.  Basically, one sets point into
> a different window since that is the convenient way to change focus.

I agree to this. If I sum up what I think about the current issue after
reading all messages it looks something like this:

1) Try to be consistent both within Emacs and with other apps.

2) Try to give visual clues.

3) All "links" should have a common look. There is a difference here between
Emacs and some other apps. An Emacs buffer is more like a web browser than
for example a list style dialog. Therefore I believe the "links" should
always look like the links in a web browser. (And double clicks should not
be used for links since this belongs to another visual style.)

4) Note that the look of the links are very important for keyboard users
too! (I happen to be one of those that seldom uses the mouse - even if I can
find it...)

5) This should apply also to "mouse over" faces.

6) Since "unfocused" windows with the behaviour suggested below does not
have directly clickable links the "mouse over" face should then perhaps be
different.

7) A single click sets focus and point if the window does not have focus.

8) A single click follows link otherwise (if the click is on a link...)

RE: follow-link in grep buffer

[Drew Adams]

    If we have specific problems in certain modes, let's fix those
    modes (e.g. in grep that you have to click on the file:line
    part of a line to jump).

Just to add one more permutation to our list of contortions ;-) -

I would like to see modes like Dired and Grep and Buffer List make the
entire line, which is in fact the entire entry, clickable and
mouse-highlightable, as I think I mentioned before. The reasons are:

 - It makes it much easier to "scan" with the mouse, seeing what lines up
with what. This is like using a ruler to scan entries in a large table or
phone book.

 - It makes it easier to click an entry - just click anywhere on the line.

I've used this behavior for decades in my own Emacs, and I find it useful.

Anyway, I mention this now because of Kim's suggestion, above, which moves a
bit in the opposite direction. IOW, I don't want to see the hot zone
_reduced_ or limited in buffers like grep, I instead want to see the entire
entry (which is the entire line) become the hot zone.

Assuming that I were able to convince others about this (;-)), what would
that mean wrt mouse bindings? In buffers like these (Dired, grep, Buffer
List), the main mouse action is not to set point, but setting point is still
an important action (e.g. in Dired). I don't have a brilliant suggestion,
but I wonder if it wouldn't be reasonable, in such buffers, to reverse one
approach mentioned already:

 - mouse-1 follows the link (which, to me, should be the whole line)

 - double-click mouse-1 sets point

I don't think this would be too bad. In such buffers we do need to set point
sometimes, and we sometimes want to create a region, but we don't usually
need to double-click to select a word. We could always drag to create a
region (I do that in my Dired buffers).

Of course, there is the argument that this won't be intuitive to users, but
I think we'll be up against such an argument no matter what we choose. After
all, being able to both a) follow a link and b) set point is not that
common.

Another argument against this might be that a too-slow double-click would
mess up the user, mistakenly following the link. I think users can deal with
this. In Windows, a simple GUI dialog lets you set the double-click interval
(speed), and this setting applies to all applications. (BTW, Do we pick up
this Windows setting in Emacs, to use as our double-click delay?)

Kim's time delay is also a good approach to the mouse-1/mouse-2 problem, and
it is also standard behavior in many apps (the argument that users will
never discover it is overstated, IMO). There would be no problem in adopting
both approaches simultaneously (to set point: either double-click or hold
mouse-1 pressed a little longer). That might sound paradoxical, but it's
perhaps the easiest behavior to explain (and discover): to follow a link,
use a single short click; anything else sets point.

Whatever we choose, we have these requirements:

 - It should be at least as easy to follow a link as to set point. In
buffers that are primarily "view" buffers, as opposed to "edit", it is
tolerable if setting point is not quite as easy as following a link.

 - It shouldn't be too hard to discover or perform either action.

 - There should not be any disastrous consequences of making a mistake.

WRT having the first mouse-click set the focus (a suggestion Stefan and I
each made): Yes, that would be done only if the window didn't already have
the focus. No, it wouldn't apply if you choose to have the focus
automatically follow the mouse. I think that first-click-focuses suggestion
makes sense, regardless of what other conventions we adopt - that is, it
should be adopted even if we also choose to use double-click (or whatever)
to set point.

Re: follow-link in grep buffer

[David Kastrup]

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

>     If we have specific problems in certain modes, let's fix those
>     modes (e.g. in grep that you have to click on the file:line part
>     of a line to jump).
>
> Just to add one more permutation to our list of contortions ;-) -
>
> I would like to see modes like Dired and Grep and Buffer List make
> the entire line, which is in fact the entire entry, clickable and
> mouse-highlightable, as I think I mentioned before.

For one thing, this is visually distracting.  Our highlight color is
pretty brutal.  For buttons, this is fine, for active lines, this is
too much.

Personally, I could imagine a two-fold system: decent highlighting for
non-mouse1-links (that need mouse-2 or a double click), brutal
highlighting for really active areas where mouse-1 already has an
effect.

> The reasons are:
>
>  - It makes it much easier to "scan" with the mouse, seeing what
> lines up with what. This is like using a ruler to scan entries in a
> large table or phone book.

The mouse highlighting we have makes the line pretty unreadable.  That
is ok for buttons: you usually are aware what they are for before you
move to their confined area.  But it is too heavy for whole lines.

>  - It makes it easier to click an entry - just click anywhere on the
>  line.

Good grief.  In a dired buffer, I most often need to to some directory
editing operation: renaming, moving, viewing with a special
application.  If there is no place in the whole buffer where a simple
mouse-1 will be able to place point, this is a terrible nuisance.  I
am not sure I'd want to have even just the file name
mouse-1-buttonized, let alone the whole line.

> Anyway, I mention this now because of Kim's suggestion, above, which
> moves a bit in the opposite direction. IOW, I don't want to see the
> hot zone _reduced_ or limited in buffers like grep, I instead want
> to see the entire entry (which is the entire line) become the hot
> zone.

That pretty much destroys the ability for simple editing without using
smartass tricks like long clicks or drags.

This is not an interface I want to have to explain to anybody.

> Assuming that I were able to convince others about this (;-)), what
> would that mean wrt mouse bindings? In buffers like these (Dired,
> grep, Buffer List), the main mouse action is not to set point, but
> setting point is still an important action (e.g. in Dired). I don't
> have a brilliant suggestion, but I wonder if it wouldn't be
> reasonable, in such buffers, to reverse one approach mentioned
> already:
>
>  - mouse-1 follows the link (which, to me, should be the whole line)
>
>  - double-click mouse-1 sets point

Terrible.  If I tell that to any new Emacs users, they'll shake their
heads and leave Emacs alone.  I don't mind if you configure your own
editor in such a backward way that makes the simple operations
difficult, but you won't see me applauding this choice even if you
managed to convinve a majority that this is not insane.

> I don't think this would be too bad.

I think it would be terrible.  I can't explain such behavior to _any_
newbie.  It is fine if you have the possibility to configure it this
way, and the possibility to tell people how convenient you find it and
they should try it as well, but I won't accept something so completely
backward from all customary defaults with no apparent advantage
without screaming all the while.

Please _don't_ think in the category "what would be most convenient
for me, even if by a hairline".  Rather try thinking "what would be
most convenient to _explain_ for me".

If people ask you "Why for heaven's sake does it do that?", you should
have a very convincing answer, or you are doing something wrong.
Putting the scrollbar to the left in an Emacs window has a convincing
answer.  Left is where the bulk of the text action is in a
left-to-right script.  That is one example where Emacs differs from
the rest of the world for a _good_ reason.  I can explain that.  And
it is something that I would be proud to explain, showing people how
Emacs developers use their brain.

In contrast, with a scheme like your, I'd be ashamed to explain, and I
would not have anything close to a convincing answer to "Why for
heaven's sake does it do that?".  And "That's just the way it does
it.  Take it or leave it." is not what I like to offer as an
explanation.

> In such buffers we do need to set point sometimes, and we sometimes
> want to create a region, but we don't usually need to double-click
> to select a word.

Which is why double clicking anywhere on the line is perfect for
following a link.

> Of course, there is the argument that this won't be intuitive to
> users, but I think we'll be up against such an argument no matter
> what we choose.

So let us choose the worst?

> Another argument against this might be that a too-slow double-click
> would mess up the user, mistakenly following the link. I think users
> can deal with this.

Sure.  They'll just switch to a different editor.

> In Windows, a simple GUI dialog lets you set the double-click
> interval (speed), and this setting applies to all
> applications. (BTW, Do we pick up this Windows setting in Emacs, to
> use as our double-click delay?)

If you read in the coding guidelines you'll find that a double-click
action should _add_ to a single click action so that the single click
action can be executed immediately, without delay or other
disturbances.

>  - It should be at least as easy to follow a link as to set
> point.

For a button-like link.  But not for whole lines.

> In buffers that are primarily "view" buffers, as opposed to "edit",
> it is tolerable if setting point is not quite as easy as following a
> link.

dired buffers are used for quite more than just selecting a file to
view.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: follow-link in grep buffer

[Drew Adams]

    > Just to add one more permutation to our list of contortions ;-) -
    >
    > I would like to see modes like Dired and Grep and Buffer List make
    > the entire line, which is in fact the entire entry, clickable and
    > mouse-highlightable, as I think I mentioned before.

    For one thing, this is visually distracting.  Our highlight color is
    pretty brutal.  For buttons, this is fine, for active lines, this is
    too much.

For that reason, I use underline for mouse-face highlighting in such
buffers.

    > The reasons are:
    >
    >  - It makes it much easier to "scan" with the mouse, seeing what
    > lines up with what. This is like using a ruler to scan entries in a
    > large table or phone book.

    The mouse highlighting we have makes the line pretty unreadable.  That
    is ok for buttons: you usually are aware what they are for before you
    move to their confined area.  But it is too heavy for whole lines.

Agreed - see above. The proper highlighting to use is our choice (and then
it's the user's choice). I agree that mouseover highlighting of entire-line
entries should be subtle, not overwhelming. I use underline.

Ideally, I would love to be able to use underlining _without removing any
font-lock highlighting_; that is, simply underline the text when you point
to it, without changing any of its other properties. That's the behavior in
most Web browsers. I'm not sure if that's easy to do, or even feasible, in
Emacs, however.

    >  - It makes it easier to click an entry - just click anywhere on the
    >  line.

    Good grief.  In a dired buffer, I most often need to to some directory
    editing operation: renaming, moving, viewing with a special
    application.  If there is no place in the whole buffer where a simple
    mouse-1 will be able to place point, this is a terrible nuisance.  I
    am not sure I'd want to have even just the file name
    mouse-1-buttonized, let alone the whole line.

1. Currently I do not have mouse-1 follow links, so I have no pb in this
regard. I agree that if one cannot easily set point, that is a major
problem.

2. I specifically said that in such buffers it is very important to be able
to easily set point with the mouse. I said, about such buffers: "the main
mouse action is not to set point, but setting point is still an important
action (e.g. in Dired)."

3. Describing behavior like this doesn't communicate it well. You really
need to try it (or have a good imagination). Also, it's hard to think
outside of one's habitual box - that is, our habits can often convince us
that any change is undesirable.

    > Anyway, I mention this now because of Kim's suggestion, above, which
    > moves a bit in the opposite direction. IOW, I don't want to see the
    > hot zone _reduced_ or limited in buffers like grep, I instead want
    > to see the entire entry (which is the entire line) become the hot
    > zone.

    That pretty much destroys the ability for simple editing without using
    smartass tricks like long clicks or drags.

See above. I use mouse-1 to set point currently, as usual (no
double-clicking). If we changed mouse-1 to follow links, then I would
double-click to set point - or I would forego mouse-1-follows-links. "Simple
editing" would not be affected detrimentally by what I or Kim described, and
such buffers are not for non-simple editing.

    This is not an interface I want to have to explain to anybody.

We want an interface that does _not_ need explaining - especially wrt basic
mouse operations such as following links and setting point. I think this
behavior would be fairly intuitive and easy to discover - no special
explanation would be needed.

Keep in mind, too, that Emacs novices already need to learn much trickier
mouse manipulations (double-click and triple-click to select, mouse-1 plus
mouse-3 to select, etc.). How did you learn all that? You probably read it
in Info. Well, what I'm talking about is a lot less to explain than all
that. And, more importantly, it probably would be discovered and not need
explaining at all (unlike mouse-1 plus mouse-3 to select etc.).

    > Assuming that I were able to convince others about this (;-)), what
    > would that mean wrt mouse bindings? In buffers like these (Dired,
    > grep, Buffer List), the main mouse action is not to set point, but
    > setting point is still an important action (e.g. in Dired). I don't
    > have a brilliant suggestion, but I wonder if it wouldn't be
    > reasonable, in such buffers, to reverse one approach mentioned
    > already:
    >
    >  - mouse-1 follows the link (which, to me, should be the whole line)
    >
    >  - double-click mouse-1 sets point

    Terrible.  If I tell that to any new Emacs users, they'll shake their
    heads and leave Emacs alone.

And when you tell them about mouse-1 plus mouse-3 and all the rest?

    I don't mind if you configure your own editor in such a backward
    way that makes the simple operations difficult,

I appreciate that you don't mind.

    but you won't see me applauding this choice even if you
    managed to convinve a majority that this is not insane.

Please - du calme - it's just food for thought. I doubt I'll convince
anyone, but that doesn't imply that I'm wrong. I've been wrong before, and
I've been right before and unable to convince others - that's life. This is
just a discussion; no one is shooting your grandmother.

Personally, I find the full-line highlighting so useful that if forced to
choose, I'll probably choose not to have mouse-1 follow links in such
buffers. _I_ might not mind double-clicking to set point in such buffers,
but if you barf at the thought, well, we might have different taste.

    > I don't think this would be too bad.

    I think it would be terrible.  I can't explain such behavior to _any_
    newbie.

If we need to have you explain such things to newbies, then, yes, we're in
deep doo-doo. The basics of our UI should be straightforward, discoverable,
and self explanatory - so you will be able to retire from the lecture
circuit ;-). ("Lesson 17: Introduction to the Emacs Mouse, Part III" -
sheesh!)

    It is fine if you have the possibility to configure it this
    way, and the possibility to tell people how convenient you find it and
    they should try it as well, but I won't accept something so completely
    backward from all customary defaults with no apparent advantage
    without screaming all the while.

Uh, have you had your coffee this morning, David?

To make one thing clear, again: I find full-line links in buffers like Dired
convenient, yes. I invite others to try it, yes. No, it doesn't require any
explaining.

I have not used full-line links at the same time as using mouse-1 to follow
links, so I have not experienced any problems in that regard.

Once we introduce mouse-1 linking, any of the compromises we have been
discussing might require some explaining. I don't see double-click vs any of
the other means of setting point being less intuitive or requiring more
explanation. I threw out double-click-to-set-point this morning as another
possibility to think about. I don't think any of the "solutions" mentioned
so far are wonderful, or I wouldn't have tossed this one into the ring for
consideration.

    Please _don't_ think in the category "what would be most convenient
    for me, even if by a hairline".  Rather try thinking "what would be
    most convenient to _explain_ for me".

Ease of explanation is important. Ease of use (convenience) and discovery is
even more important.

    If people ask you "Why for heaven's sake does it do that?", you should
    have a very convincing answer, or you are doing something wrong.

Agreed.

    In contrast, with a scheme like your, I'd be ashamed to explain, and I
    would not have anything close to a convincing answer to "Why for
    heaven's sake does it do that?".  And "That's just the way it does
    it.  Take it or leave it." is not what I like to offer as an
    explanation.

I wouldn't want you to feel ashamed on my behalf. And far be it from me to
say "take it or leave it." Let me say, instead, "please take it and think
about it" - that's all. You've obviously thought about it, and you reject
it; that's OK by me.

    > In such buffers we do need to set point sometimes, and we sometimes
    > want to create a region, but we don't usually need to double-click
    > to select a word.

    Which is why double clicking anywhere on the line is perfect for
    following a link.

Or setting point ;-).

Again, honestly I don't know how inconvenient double-clicking to set point
or follow a link would be - I'd have to try it. I do know that I prefer the
full-line mouseover in buffers with full-line entries, and I'll keep that
behavior in my own Emacs, whatever I decide to choose for following links vs
setting point.

    > Of course, there is the argument that this won't be intuitive to
    > users, but I think we'll be up against such an argument no matter
    > what we choose.

    So let us choose the worst?

No, let us find the best, whatever that may be.

Let us find the easiest to use, easiest to discover, easiest to explain,
most flexible approach that differs least from a) behavior elsewhere in
Emacs and b) behavior in other apps. Amen.

    > Another argument against this might be that a too-slow double-click
    > would mess up the user, mistakenly following the link. I think users
    > can deal with this.

    Sure.  They'll just switch to a different editor.

Heavens! Lecturing about vi or TextPad is no fun at all!

    > In Windows, a simple GUI dialog lets you set the double-click
    > interval (speed), and this setting applies to all
    > applications. (BTW, Do we pick up this Windows setting in Emacs, to
    > use as our double-click delay?)

    If you read in the coding guidelines you'll find that a double-click
    action should _add_ to a single click action so that the single click
    action can be executed immediately, without delay or other
    disturbances.

Uh, what's the connection with what I wrote?

    >  - It should be at least as easy to follow a link as to set
    > point.

    For a button-like link.  But not for whole lines.

For any link, it should be at least as easy to follow a link as to set
point - especially in 'buffers that are primarily "view" buffers, as opposed
to "edit".' Regardless of the shape and size of the hot zone.

    > In buffers that are primarily "view" buffers, as opposed to "edit",
    > it is tolerable if setting point is not quite as easy as following a
    > link.

    dired buffers are used for quite more than just selecting a file to
    view.

Yes, they are.

Re: follow-link in grep buffer

[Stefan Monnier]

>     Terrible.  If I tell that to any new Emacs users, they'll shake their
>     heads and leave Emacs alone.

> And when you tell them about mouse-1 plus mouse-3 and all the rest?

The difference is that you don't need to tell Emacs novices about
mouse-1+mouse-3 (which I never ever use in Emacs, BTW, I always use
drag-mouse-1 instead).  OTOH you do have to explain to them why they can't
just "click to place point" and how to work around it.


        Stefan

Re: follow-link in grep buffer

[David Kastrup]

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

>>     Terrible.  If I tell that to any new Emacs users, they'll shake
>>     their heads and leave Emacs alone.
>
>> And when you tell them about mouse-1 plus mouse-3 and all the rest?
>
> The difference is that you don't need to tell Emacs novices about
> mouse-1+mouse-3 (which I never ever use in Emacs, BTW, I always use
> drag-mouse-1 instead).

Oh, but clicking mouse-3 twice for deletion is so convenient that it
warrants teaching.  Also using mouse-3 for _extending_ a region can't
be replaced by dragging.

But you are right in that one does not _need_ to teach it to people,
and they are not worse off than with any other editor.

It is ok if people discover the joys of Emacs not all at once.  But we
should try to avoid hitting them with unpleasant surprises right away.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: follow-link in grep buffer

[Drew Adams]

    >     Terrible.  If I tell that to any new Emacs users, they'll
    >     shake their heads and leave Emacs alone.

    > And when you tell them about mouse-1 plus mouse-3 and all the rest?

    The difference is that you don't need to tell Emacs novices about
    mouse-1+mouse-3 (which I never ever use in Emacs, BTW, I always use
    drag-mouse-1 instead).  OTOH you do have to explain to them why
    they can't just "click to place point" and how to work around it.

Well, I don't want to belabor this point, but mouse-1+mouse-3 behavior does
need introducing, _if_ someone is to use it - people are not likely to
_discover_ that behavior. Double-click behavior is something that many
people will discover without explanation, IMO. Others may disagree...

BTW, I'm a bit surprised that you always drag to select. Do you also not use
two mouse-3 clicks to delete the region? That's another handy operation
(though not basic or essential) that requires some introduction. Unlike
mouse-1+mouse-3, people _are_ likely to discover that on their own, but it
might take them a while to understand just what they've done.

Using the mouse to follow a link and set point are basic operations that
should not require any how-to explanation. Today, we do need to "tell"
novices about mouse-2 and links. Tomorrow, we may unfortunately need to
"tell" them about other ways to use the mouse to do simple things. We should
try to come up with a scheme that leaves the three most basic mouse
operations - setting point, defining the region, and following links -
without need of an explanation. It doesn't sound like we're quite there yet.

Your point is valid, of course, that novices might not need mouse-1+mouse-3.

Re: follow-link in grep buffer

[David Kastrup]

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

> See above. I use mouse-1 to set point currently, as usual (no
> double-clicking). If we changed mouse-1 to follow links, then I
> would double-click to set point - or I would forego
> mouse-1-follows-links. "Simple editing" would not be affected
> detrimentally by what I or Kim described, and such buffers are not
> for non-simple editing.

Look, you are arguing for an interface you are not even using
yourself.  Whenever I explain why a particular default is horrible,
you say "Oh, I have configured something different myself currently".
This leads nowhere.

>     This is not an interface I want to have to explain to anybody.
>
> We want an interface that does _not_ need explaining - especially
> wrt basic mouse operations such as following links and setting
> point. I think this behavior would be fairly intuitive and easy to
> discover - no special explanation would be needed.

I disagree.

> Keep in mind, too, that Emacs novices already need to learn much
> trickier mouse manipulations (double-click and triple-click to
> select,

One does not need to learn that.  One gets along fine without it.

> mouse-1 plus mouse-3 to select,

Again, dragging mouse-1 just works.  The default behavior will get you
rolling without surprises, even though you miss out on features.

> etc.). How did you learn all that?  You probably read it in
> Info. Well, what I'm talking about is a lot less to explain than all
> that. And, more importantly, it probably would be discovered and not
> need explaining at all (unlike mouse-1 plus mouse-3 to select etc.).
>
>     > Assuming that I were able to convince others about this (;-)), what
>     > would that mean wrt mouse bindings? In buffers like these (Dired,
>     > grep, Buffer List), the main mouse action is not to set point, but
>     > setting point is still an important action (e.g. in Dired). I don't
>     > have a brilliant suggestion, but I wonder if it wouldn't be
>     > reasonable, in such buffers, to reverse one approach mentioned
>     > already:
>     >
>     >  - mouse-1 follows the link (which, to me, should be the whole line)
>     >
>     >  - double-click mouse-1 sets point
>
>     Terrible.  If I tell that to any new Emacs users, they'll shake their
>     heads and leave Emacs alone.
>
> And when you tell them about mouse-1 plus mouse-3 and all the rest?

I can tell them the _advantages_ of the separate mouse-3 thing (which
is much more friendly on the sinews than dragging), and in particular
mouse-3 deletion.  If they can't remember it, they still will be able
to everything necessary, only more cumbersome.

I have no problems with pointing out available additional convenience.
I have a problem with pointing out unexpected complications.

> Personally, I find the full-line highlighting so useful that if
> forced to choose, I'll probably choose not to have mouse-1 follow
> links in such buffers. _I_ might not mind double-clicking to set
> point in such buffers, but if you barf at the thought, well, we
> might have different taste.

I seem to be a complete failure at communicating my opinion.  Taste is
not a question here.  One of the great things of Emacs is that it can
be configured to accommodate almost any taste and need.  We are
talking about a default setting here: and that does not need to be
tasteful, but obvious and generally useful and consistent.  And "I
find it nice that if I reconfigure the highlighting face that as a
side effect I get in dired an orientation line" has nothing to do
whatsoever with consistency.  We don't want the behavior in dired to
be surprisingly different from the rest by default, and we don't want
to have some moderately convenient choice for dired (and I disagree
with your assessment even just in dired) to make all the rest less
logical and convenient.

It is ok to add options to dired to make it able to achieve such
effects for a user with particular desires.  But the defaults should
be consistent and predictable even for newcomers if there are not very
strong reasons against that.

>     It is fine if you have the possibility to configure it this way,
>     and the possibility to tell people how convenient you find it
>     and they should try it as well, but I won't accept something so
>     completely backward from all customary defaults with no apparent
>     advantage without screaming all the while.
>
> Uh, have you had your coffee this morning, David?
>
> To make one thing clear, again: I find full-line links in buffers
> like Dired convenient, yes. I invite others to try it, yes. No, it
> doesn't require any explaining.

No?  It does not require explaining that you can't do anything useful
with the mouse in dired in an obvious way without the buffer
disappearing?  Because every possible location is a link?

> I have not used full-line links at the same time as using mouse-1 to
> follow links, so I have not experienced any problems in that regard.

Sigh.  The current point of discussion is double-click versus single
click in connection with buttons and linkable areas.  We won't get far
by "I have not experienced any problems with the setup I am proposing
because I have not used it yet" kind of arguments.

> Once we introduce mouse-1 linking, any of the compromises we have
> been discussing might require some explaining.

We _have_ introduced mouse-1 linking.  That is what is in CVS.  That
is what we are talking about.

>     > In Windows, a simple GUI dialog lets you set the double-click
>     > interval (speed), and this setting applies to all
>     > applications. (BTW, Do we pick up this Windows setting in
>     > Emacs, to use as our double-click delay?)
>
>     If you read in the coding guidelines you'll find that a
>     double-click action should _add_ to a single click action so
>     that the single click action can be executed immediately,
>     without delay or other disturbances.
>
> Uh, what's the connection with what I wrote?

If the single click follows a link, and a double click sets point, you
can't obey the single click before waiting for the double click to
expire since undoing the link following is not expedient.  In
contrast, you can immediately set point on a single click even before
knowing whether this click will actually turn into a double click.

The Emacs Lisp manual says the following in
(info "(elisp) Repeat Events")

[...]

       When the user performs a double click, Emacs generates first an
    ordinary click event, and then a double-click event.  Therefore, you
    must design the command binding of the double click event to assume
    that the single-click command has already run.  It must produce the
    desired results of a double click, starting from the results of a
    single click.

       This is convenient, if the meaning of a double click somehow "builds
    on" the meaning of a single click--which is recommended user interface
    design practice for double clicks.

So it is rather obvious that even if there were not "prior art" for
having a double click invoke an object-related action, and a single
click just set point inside of an addressable area, the choice between
those assignments is not arbitrary.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link in grep buffer

[Robert J. Chassell]

    ... intuitive

`Intuitive' is the wrong word.  When I started with a windowing
system, my mnemonic was `m means menue'.  That is because the middle
mouse button on that system evoked a menu.  

In this window, `m means mouse-yank-at-click'.  This is different.

As for `set point', `set mark', `paste': that seems good to me as
left mouse, right mouse, middle mouse, even though I use my left hand
with my mouse, which some people say should mean that I reverse the
button bindings.

What you are saying is that many people have learned first to use
other applications than Emacs and have learned their mouse bindings.
And not being an old, integrated environment, a virtual Lisp machine
with a built-in editor (as well as nowadays, at least two Web
browsers), they learned to press the number one mouse button (be it on
the left or the right) to follow a link of some sort rather than to
set point.

I do not see anything wrong with that, so long as the links are small
enough that I can, if need be, copy or delete the region when editing
it; but please do not use the word `intuitive' for what is learned
process.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: follow-link in grep buffer

[Drew Adams]

    > I use mouse-1 to set point currently, as usual (no
    > double-clicking). If we changed mouse-1 to follow links, then I
    > would double-click to set point - or I would forego
    > mouse-1-follows-links. "Simple editing" would not be affected
    > detrimentally by what I or Kim described, and such buffers are not
    > for non-simple editing.

    Look, you are arguing for an interface you are not even using
    yourself.

I argued for full-line mouseover highlighting in buffers like grep. I've
been using it for decades. Try it; you'll like it.

I also threw out, as a _separate_ idea, the possibility that if we have
mouse-1 follow links, then double-click mouse-1 might set point (instead of
mouse-1 setting point and double-click following links). I provided a little
rationale for such an approach, but I also explained that I was _not_ going
to the barricades for that idea. If you find that idea crazy, I won't fight
for it.

I have not used mouse-1 to follow links in Emacs. mea culpa.

    Whenever I explain why a particular default is horrible,
    you say "Oh, I have configured something different myself currently".
    This leads nowhere.

Bad generalization. A better generalization is "Whenever David discusses
something, he screams like Howard Dean in Iowa." But neither generalization
is very good.

    >     This is not an interface I want to have to explain to anybody.
    >
    > We want an interface that does _not_ need explaining - especially
    > wrt basic mouse operations such as following links and setting
    > point. I think this behavior would be fairly intuitive and easy to
    > discover - no special explanation would be needed.

    I disagree.

    > Personally, I find the full-line highlighting so useful that if
    > forced to choose, I'll probably choose not to have mouse-1 follow
    > links in such buffers. _I_ might not mind double-clicking to set
    > point in such buffers, but if you barf at the thought, well, we
    > might have different taste.

    I seem to be a complete failure at communicating my opinion.

No, on that score you do well.

    Taste is
    not a question here.  One of the great things of Emacs is that it can
    be configured to accommodate almost any taste and need.  We are
    talking about a default setting here: and that does not need to be
    tasteful, but obvious and generally useful and consistent.

"we might have different taste" in this matter: We might have different
opinions of what the default setting should be. Sorry if that wasn't clear.

The personal choice I was referring to was this: I will keep full-line
mouseover and forego mouse-1-follows-links, in my own Emacs. The former is
that important to me. I would _like_ standard Emacs to follow my taste in
this, but I don't expect to be able to convince others on this. Not this
time around, anyway ;-).

That personal choice is separate (different) from the question of
double-click mouse-1 to set point vs to follow links. The latter is a
discussion about what the default Emacs behavior should be. We might have
different taste in that choice. I say "might" because I am not arguing
forceably for one or the other; I don't even know what I would prefer in
that regard. I just threw out an additional possibility for consideration.
As I said in my reply to Stefan, "It doesn't sound like we're quite there
yet." I was just trying to contribute to finding a solution.

FWIW, my reason for bringing up the full-line mouseover in this discussion
was Kim's remark that we might consider _reducing_ the size of the mouseover
fields in grep. He made his suggestion (of a possibility) because of the
perceived problem with setting point in such buffers if mouse-1 follows
links. There remains a problem with setting point vs following links, IMO.
Reducing the hot zones won't solve the problem (though it would restrict
it), and such a hot-zone reduction works against what I think we should be
doing wrt mouseover in such buffers. So 1) I spoke my mind wrt full-line
mouseover zones and 2) I threw out yet another set-point-vs-follow-link
possibility, for discussion.

    And "I
    find it nice that if I reconfigure the highlighting face that as a
    side effect I get in dired an orientation line" has nothing to do
    whatsoever with consistency.

    We don't want the behavior in dired to
    be surprisingly different from the rest by default, and we don't want
    to have some moderately convenient choice for dired (and I disagree
    with your assessment even just in dired) to make all the rest less
    logical and convenient.

I guess you are saying that mouse-face highlighting should always be the
same, for consistency.

Consistency is a valid argument, in general. I agree that consistency is
important, but everything is relative. This particular inconsistency is not
a biggee to me (mouseover highlighting is always clear to users, regardless
of the color etc.), but "we might have different taste" in weighing the
relative advantage here.

I made the argument that buffers such as Dired, Buffer List and Compile (and
Info and perhaps Customize) have certain properties in common. They are more
like view (or browser) modes than edit modes, even though they are not
strictly view-only.

For such buffers to be treated _consistently_ in a slightly different way
from others wrt mouse-face might not be such a bad thing, IMO. There are
many ways in which such buffers are already inconsistent wrt normal edit
buffers (e.g. self-insert keys vs single-key commands). The idea would be to
keep them fairly consistent among themselves, treating them the same in this
regard.

On the other hand, part of the perceived inconsistency here comes from the
fact that some other "links" in Emacs are not really links, but are in fact
action buttons (or even pulldown menus). Perhaps all true links everywhere
should have a subtle mouse-face such as underline.

But what about links that are hard to find? Does having a bright, garish
mouse-face help you find them? Not really. In buffers where there are few
links, mouse-over won't help you find them. Having links show up only on
mouseover makes sense only in link-dense buffers where the link locations
are predictable. In other buffers, (including Info and perhaps Customize),
it might make sense to show the link (e.g. by underlining) even without
mouseover. We might come up with consistent guidelines for different classes
of buffers, or we might leave it up to individual users somehow.

Think about links on the Web: in some contexts it does makes sense to show
links only on mouseover; in the text of most Web pages, however, it makes
sense to show links all the time (e.g. by underlining). Different contexts
call for different treatment, but there should be a set of guidelines
underlying the different treatments, and, _other things being equal_,
consistency should be the aim.

IOW, I too feel strongly about consistency. I think you heard me argue
previously, for instance, that all links in Customize should look the same
(and should look like links), and all buttons should look the same (and
should look like buttons), and all pulldown menus should look the same (and
should look like pulldown menus).

    > To make one thing clear, again: I find full-line links in buffers
    > like Dired convenient, yes. I invite others to try it, yes. No, it
    > doesn't require any explaining.

    No?  It does not require explaining that you can't do anything useful
    with the mouse in dired in an obvious way without the buffer
    disappearing?  Because every possible location is a link?

No, that does not require any explaining. That behavior is immediately
obvious (and is consistent with the rest of Emacs): mouse-2 clicking a link
follows the link, as always. That the links are longer or shorter might be
better or worse, depending on your taste, but the behavior of clicking a
link requires no explanation - it is 100% standard fare.

We are not talking about any new mouse behavior here (e.g. mouse-1 follows
links); that paragraph was about full-line mouse-face on its own.

    > I have not used full-line links at the same time as using mouse-1 to
    > follow links, so I have not experienced any problems in that regard.

    Sigh.  The current point of discussion is double-click versus single
    click in connection with buttons and linkable areas.  We won't get far
    by "I have not experienced any problems with the setup I am proposing
    because I have not used it yet" kind of arguments.

Have any of the ideas discussed in this context (e.g. double-click to follow
link) been used yet in Emacs? I don't think so. Is it not OK to discuss
hypothetical changes when looking for a solution?

    > Once we introduce mouse-1 linking, any of the compromises we have
    > been discussing might require some explaining.

    We _have_ introduced mouse-1 linking.  That is what is in CVS.  That
    is what we are talking about.

"We are talking about" not only mouse-1 linking (which has not yet been
released, AFAIK) but, in particular, how to make it play well with other
things. The ideas under discussion are hypothetical. That is, it is the
combination of mouse-1 linking with the other ideas that is hypothetical. In
your words, the context is "double-click versus single click in connection
with buttons and linkable areas." We are discussing possible solutions.

    >     > In Windows, a simple GUI dialog lets you set the double-click
    >     > interval (speed), and this setting applies to all
    >     > applications. (BTW, Do we pick up this Windows setting in
    >     > Emacs, to use as our double-click delay?)
    >
    >     If you read in the coding guidelines you'll find that a
    >     double-click action should _add_ to a single click action so
    >     that the single click action can be executed immediately,
    >     without delay or other disturbances.
    >
    > Uh, what's the connection with what I wrote?

    If the single click follows a link, and a double click sets point, you
    can't obey the single click before waiting for the double click to
    expire since undoing the link following is not expedient.  In
    contrast, you can immediately set point on a single click even before
    knowing whether this click will actually turn into a double click.

Good point. Yes, I guess double-click-to-set-point would violate the coding
guideline (which I reread recently, but somehow forgot). I withdraw that
idea. Uncle! It was a terrible idea. I never should have brought it up for
your consideration. Good, one less solution to worry about. So, where were
we?...

Your guideline point, however, has nothing (that I can see) to do with what
I wrote about setting the double-click delay. And I would still like to know
if Emacs picks up the user's Windows setting for double-click delay. Anyone
know?

Re: follow-link in grep buffer

[David Kastrup]

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

>     > I use mouse-1 to set point currently, as usual (no
>     > double-clicking). If we changed mouse-1 to follow links, then I
>     > would double-click to set point - or I would forego
>     > mouse-1-follows-links. "Simple editing" would not be affected
>     > detrimentally by what I or Kim described, and such buffers are not
>     > for non-simple editing.
>
>     Look, you are arguing for an interface you are not even using
>     yourself.
>
> I argued for full-line mouseover highlighting in buffers like
> grep. I've been using it for decades. Try it; you'll like it.

I don't.  I don't need to particularly try it since it is the current
default.

To make this visually acceptable, we will need two different
highlighting faces: a decent one on the whole line (such as
underlining), and possibly a more striking one on selected "hot
spots", like just the filename in a grep or dired buffer.  The whole
actionable area can always be invoked by mouse-2, and I think we have
agreement that having selected hot spots (like Customize buttons)
react to mouse-1 is a good idea.

We have not much talked about larger actionable areas not specifically
marked as buttons by the application programmer: the initial plans
were more or less based on making them behave equal to hot spots or
buttons, which has the disadvantage that they often cover areas where
one would want to set point with mouse-1. There is some agreement that
offering more than mouse-2 on them for triggering the action would be
a good idea.  My proposal was to use a double mouse-1 click here, so
that a single click can still set point.  Opinions here vary wildly,
with quite a few proposals trying to make a single mouse-1 click also
work for triggering an action, but with a mixture of special rules
like "how long the click?" "click into non-selected window?" "click
into non-focused frame" to pick stuff apart.  Rules that partly
violate some policies for click event set forth in the Elisp manuals,
and rules that partly can't be cast into event types described by our
hypertext help system.

It is clear that tastes for one's own personal use vary wildly, and it
certainly would be nice if many tastes could be accommodated with
customization possibilities.

> Bad generalization. A better generalization is "Whenever David
> discusses something, he screams like Howard Dean in Iowa." But
> neither generalization is very good.

Whatever.  Enough people have pointed out by now that they see little
merit or sense or consistency or logic in my proposals.  So I'll just
stop screaming and let others decide.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: follow-link in grep buffer

[Drew Adams]

    > Bad generalization. A better generalization is "Whenever David
    > discusses something, he screams like Howard Dean in Iowa." But
    > neither generalization is very good.

    Whatever.  Enough people have pointed out by now that they see little
    merit or sense or consistency or logic in my proposals.  So I'll just
    stop screaming and let others decide.

Chalk that one up to my bad sense of humor - I apologize. None of us need ad
hominem arguments; I was trying to say that, sarcastically, by making such
an argument myself.

FWIW, I don't find your double-click-to-follow+single-click-to-set-pt
suggestion worse than my opposite idea. In fact, your reference to the
coding guideline about click-1 and click-2 convinced me that my suggestion
was not a good one. Thanks for that reminder.

I doubt too that people in general see "little sense" in your proposals in
general or in this proposal, in particular. Quite the contrary.

I personally think it's worth kicking this particular design problem around
a little more, to see if the discussion doesn't come up with something
elegant. There have been several proposals so far that I find acceptable,
but I don't think we've yet reached that "Eureka!" moment that brings a
really contented consensus. It's not as if this problem is critical or
urgent. We can do something not-too-unreasonable for the current release and
think about it some more for later.

Re: follow-link in grep buffer

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

>> I am afraid that the same is the case here.  I have
>> focus-follows-mouse set here by default in the window manager, so I
>> don't expect clicks that don't do anything.  The current behavior
>> (where a window change does not follow links at all) is more confusing
>> than the previous one.
>
> This really hasn't anything to do with focus-follows-mouse.
>
> What if you set mouse-autoselect-window ?
>
>
> In any case, I agree that last modification isn't perfect, and
> I'll think about what to do.
>

I have added a new option mouse-1-click-in-non-selected-windows
that controls whether mouse-1 click in non-selected windows
will follow links.  Default is t.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[Stefan Monnier]

> I have added a new option mouse-1-click-in-non-selected-windows
> that controls whether mouse-1 click in non-selected windows
> will follow links.  Default is t.

I think it should be purely and simply removed.
It addresses the "click to focus window" problem but nobody ever complained
about it (contrary to the problem of "click to focus frame" which is still
open).


        Stefan

Re: follow-link in grep buffer

[David Kastrup]

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

>> I have added a new option mouse-1-click-in-non-selected-windows
>> that controls whether mouse-1 click in non-selected windows
>> will follow links.  Default is t.
>
> I think it should be purely and simply removed.
> It addresses the "click to focus window" problem but nobody ever complained
> about it (contrary to the problem of "click to focus frame" which is still
> open).

But that's what the x-mouse-click-focus-ignore-position variable is
for.  And we also have focus-follows-mouse to have Emacs be able to do
what it takes to give a frame focus.

Anyway, I am complete against automatisms that get things right 70% of
all the time immediately, with the user being unable to predict the
behavior 90% of the time, so that he needs to check every time he uses
the feature what actually happened.  If there is a braindead
consistent rule that gets things right even only 40% of the time, but
does not require switching on the brain or crosschecking for
correcting the thing efficiently about 60% of the time, this is
preferable in my book.

If I am talking to a person, I don't save time if he tries completing
my sentences for me.  And similar rules hold with computers, unless we
are talking about seriously disabled users for which any correcting
action takes lots of time.  Only in that setting make complicated
second-guessing rules any sense.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link in grep buffer

[Stefan Monnier]

>>> I have added a new option mouse-1-click-in-non-selected-windows
>>> that controls whether mouse-1 click in non-selected windows
>>> will follow links.  Default is t.
>> 
>> I think it should be purely and simply removed.
>> It addresses the "click to focus window" problem but nobody ever complained
>> about it (contrary to the problem of "click to focus frame" which is still
>> open).

> But that's what the x-mouse-click-focus-ignore-position variable is
> for.  And we also have focus-follows-mouse to have Emacs be able to do
> what it takes to give a frame focus.

Then let's use that.

> Anyway, I am complete against automatisms that get things right 70% of
> all the time immediately, with the user being unable to predict the
> behavior 90% of the time, so that he needs to check every time he uses
> the feature what actually happened.  If there is a braindead
> consistent rule that gets things right even only 40% of the time, but
> does not require switching on the brain or crosschecking for
> correcting the thing efficiently about 60% of the time, this is
> preferable in my book.

Agreed, which is why x-mouse-click-focus-ignore-position seems like the
right solution: it's very deterministic (doesn't depend on precisely where
you click, for instance) and safe and unsurprising since when it doesn't do
what the user intended, it just did a bit less than what she intended and
she can trivially get what she wants by clicking one more time.


        Stefan

Re: follow-link in grep buffer

[Kim F. Storm]

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

>> I have added a new option mouse-1-click-in-non-selected-windows
>> that controls whether mouse-1 click in non-selected windows
>> will follow links.  Default is t.
>
> I think it should be purely and simply removed.
> It addresses the "click to focus window" problem but nobody ever complained
> about it (contrary to the problem of "click to focus frame" which is still
> open).


IIRC, you were the one to propose _not_ following a link in a
non-selected window, and I initially said it made sense (so I
implemented it unconditionally).

Personally, I got irritated by that, and others said it would
be confusing to novices too -- so I changed it to an option.

Of course, I can remove it all-together if nobody finds it
useful.


But maybe it would make more sense to have an option would could make
a mouse click in a non-selected window _only_ select that window
rather than also setting point (or following links or whatever).

That would be analogue to the x-mouse-click-focus-ignore-position for
frame focus.


WDOT?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[Stefan Monnier]

> IIRC, you were the one to propose _not_ following a link in a
> non-selected window, and I initially said it made sense (so I
> implemented it unconditionally).

I meant "frame", sorry.


        Stefan

Re: follow-link in grep buffer

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>

> > IIRC, you were the one to propose _not_ following a link in a
> > non-selected window, and I initially said it made sense (so I
> > implemented it unconditionally).
>
> I meant "frame", sorry.

Am I seriously misunderstanding something? Is not the Emacs window focus
what a user is interested in mostly here? For frame focus the window manager
probably have good support that the user is using regardless of the app.

Re: follow-link in grep buffer

[Stefan Monnier]

>> > IIRC, you were the one to propose _not_ following a link in a
>> > non-selected window, and I initially said it made sense (so I
>> > implemented it unconditionally).
>> 
>> I meant "frame", sorry.

> Am I seriously misunderstanding something? Is not the Emacs window focus
> what a user is interested in mostly here? For frame focus the window manager
> probably have good support that the user is using regardless of the app.

The original message said:

   However I might just want to select that window to resize it

so AFAICT this whole thread has been about a confusion between "click
mouse-1 to follow link" and "click mouse-1 to give focus to a *frame*".

Of course maybe he really meant "window", but that seems rather unlikely
to me.  This said, I agree that I'd have expected the window-manager to take
care of such things (basically the window-manager shouldn't pass on
a mouse-1 click to the application if it was used to change focus).


        Stefan

Re: follow-link in grep buffer

[Kim F. Storm]

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

> Of course maybe he really meant "window", but that seems rather unlikely
> to me.  This said, I agree that I'd have expected the window-manager to take
> care of such things (basically the window-manager shouldn't pass on
> a mouse-1 click to the application if it was used to change focus).

At least the version of KDE that I'm using does pass it on.

That's why I implemented x-mouse-click-focus-ignore-position.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[Nick Roberts]

 > The original message said:
 > 
 >    However I might just want to select that window to resize it
 > 
 > so AFAICT this whole thread has been about a confusion between "click
 > mouse-1 to follow link" and "click mouse-1 to give focus to a *frame*".
 > 
 > Of course maybe he really meant "window", but that seems rather unlikely
 > to me.  This said, I agree that I'd have expected the window-manager to take
 > care of such things (basically the window-manager shouldn't pass on
 > a mouse-1 click to the application if it was used to change focus).

I could have said:

However I might just want to select that window to scroll down it 

(I don't use scrollbars). This would require window focus while the above
might only require frame focus. I didn't give thought to the type of focus,
just that there were times where I got caught out following a link that I
didn't want to follow.


Nick

Re: follow-link in grep buffer

[Richard Stallman]

    In order not to confuse people too much, I really would want to
    suggest strongly that we remap double-click to mouse-2 unconditionally
    by default (where a "stronger" mouse-2 binding exists), and also map
    mouse-1 to the same when the special "link" property is present.

I do not see any sense in this proposal.  That idea for double-click
seems completely inconsistent with the overall scheme that we have
adopted.

Re: follow-link in grep buffer

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     In order not to confuse people too much, I really would want to
>     suggest strongly that we remap double-click to mouse-2 unconditionally
>     by default (where a "stronger" mouse-2 binding exists), and also map
>     mouse-1 to the same when the special "link" property is present.
>
> I do not see any sense in this proposal.  That idea for double-click
> seems completely inconsistent with the overall scheme that we have
> adopted.

The "overall scheme" that we have adopted historically is that any
hyperlink or action is done with mouse-2.  That is perfectly
consistent and nobody has argued that it should be removed, The
problem that we are trying to address here is that

a) it is also completely unexpected to new users,
b) mouse-2 is inconvenient on a _lot_ of touch pads and mice and
often has to be done by chording.

Outside of the world of Emacs, triggering actions has traditionally
been done by double-clicking mouse-1.  Remapping this double click
will give new users _one_ sort of behavior they are accustomed to from
both MacIntosh and Windows applications, as well as a lot of X11
dialogs (where double clicking usually means select and take a choice
directly, like in a file dialog). It will also give experienced users
with a two-button device a more convenient way to trigger an action.

One common action triggered nowadays is following links.  In browsers
and increasingly also on desktop objects, the trend has been going to
do this action with a single mouse-1 click.  Since mouse-1 is rather
commonly used for setting point in Emacs, having large areas behave
like that in Emacs does not seem appropriate, even while Customize
buttons and similarly sharply confined objects are likely to be
recognized as something where one would not want to place point.
Using a special link property on them could achieve the remapping of
mouse-1 only on those areas.  Something that looks like a button is a
candidate for single click, and so is a hyperlink marked as a cross
reference.

That's two simple additional rules: a mouse-triggerable action can be
additionally to the old mouse-2 binding also be triggered with a
double-click on mouse-1, and on specially marked links, the same
action can be done with even a single mouse-1 click.

That is all.

If you take a look at the complexity of the other approaches that have
been suggested, like making a single click follow links, and a double
click set point (in strict violation to the Emacs Lisp guidelines for
double clicks), and with half a dozen exceptions like "don't follow
link if pressed for longer than this" and "don't follow link if we
have the first click in a frame" and "don't follow link if we have the
first click in the window", the recipe I propose does

a) need no special treatment of the first click into a window: if one
explicitly aims at a small button, the guess "follow link" is
reasonable.  If one aims at a larger actionable area, the default
action of "set point" does no harm.

b) is consistent with the double-click action policy set out in the
Elisp manual: the double-click action must work sensibly even if the
single-click action has already been triggered.

c) does not need special treatment of a double-click into a window: if
the double-click is passed by the window-manager, then it is
reasonable to take the action even when the frame or window did not
have selection and/or focus previously.

The additional possibilities for triggering actions on areas with
doubleclicking mouse-1, and actions on specially marked, narrowly
confined buttons/linked with singleclicking mouse-1, are just two
additional possibilities/rules in addition to the old "mouse-2 for
triggering anything" rule that is already violated, say, in Customize.

My proposal is consistent with the double-click guidelines, it
consists of just two rules that are easily accessible to a novice, it
requires no special hold-longer times (for which we have no suitable
descriptive keyboard events anyway, so you could not use C-h k or C-h
w to find out about them), it requires no special treatment of
first-click-to-frame/windoe and it provides functionality in a manner
way more common in the world outside of Emacs than our current
consistent but unusual and often inconvenient mouse-2.

That you can't see _any_ sense in this proposal, in contrast to the
complex, timing-dependent, rule-intensive, trick-requiring (like
drag-if-you-don't-want-to-trigger-action) policy-violating,
delayed-action-requiring other schemes that have both been proposed as
well as implemented, I find somewhat surprising.

I was of the opinion that at least _some_ sense might have been
detectable in my proposal.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link in grep buffer

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     In order not to confuse people too much, I really would want to
>>     suggest strongly that we remap double-click to mouse-2 unconditionally
>>     by default (where a "stronger" mouse-2 binding exists), and also map
>>     mouse-1 to the same when the special "link" property is present.
>>
>> I do not see any sense in this proposal.  That idea for double-click
>> seems completely inconsistent with the overall scheme that we have
>> adopted.
>
> The "overall scheme" that we have adopted historically is that any
> hyperlink or action is done with mouse-2.  That is perfectly
> consistent and nobody has argued that it should be removed, The
> problem that we are trying to address here is that

I looked at grep and gnus group buffers which have been presented
as examples of the problems with the follow-link property.

In both cases, the follow-link property is set to "mouse-face"
meaning that only areas which have the mouse-face property in
those buffers will map mouse-1 to mouse-2.  

In gnus group buffer, the mouse-face is put on the group name only, so
it is easy to set point on a group line without entering that group.

In grep buffers, it seems that (almost) full lines are highlighted
with the mouse-face -- so practically the whole buffer is "mouse-1"
aware.  As I suggested earlier, one simple solution would be to
only put mouse-face on the file:line: part, but this was rejected
by some of you  (who wants to have his cake and eat it too :-)


To me it would be hard to explain to novice users why following a
mouse-face highlighted link in an info or help buffer is "opened" with
a single click, but a similarly highlighted group name in a gnus
buffer need a double click...


>                                              Since mouse-1 is rather
> commonly used for setting point in Emacs, having large areas behave
> like that in Emacs does not seem appropriate, 

If those large areas have mouse-face, it seems appropriate to me.

At least it could be a different mouse-face if they require a double
click.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow-link in grep buffer

[Richard Stallman]

    No. I wasn't aware of that. With the default setting, the user would have to
    move the mouse and release it within 350 milliseconds for it to have any
    effect. I  think must be quite hard to do.

I don't think that is what it does--is there perhaps a misunderstanding?