Re: follow-link in grep buffer

[David Kastrup <dak@gnu.org>]

"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