RE: follow-link in grep buffer

["Drew Adams" <drew.adams@oracle.com>]

    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.