Re: follow-link in grep buffer

[David Kastrup <dak@gnu.org>]

"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