> 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?
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
