RE: New start up splash screen annoyance...

[Drew Adams]

> > The doc everywhere uses `mouse-1' etc.,
>
> That is indeed a problem! It should be consistent across the board.

And the problem is? "Everywhere uses" means that it _is_ consistent. Emacs
has internal consistency in this regard. Internal consistency is much more
important for a UI than is being consistent with things outside it.

However, if other things were equal, then we would also want consistency
with the larger world.

> > and that nomenclature is clear. There is absolutely nothing to be
> > gained by changing to `left' etc.
>
> No, it is not clear. A typical user has two mouse buttons.

Really? Ask a computer store or manufacturer how many 2-button mice they
sell.

I don't know. I tried to google a bit, but this is all I came up with (it's
for Mac ;-)):
http://www.macosxhints.com/polls/index.php?qid=mousebutton&aid=-1. This is
what it shows for Mac users (and AFAIK, Apple still ships with a one-button
mouse, unless you request otherwise):

 What type of mouse do you use with your Mac?

 No mouse, just the built-in trackpad (laptops)  448 (15.35%)
 Some other non-mouse device (ShuttlePro, tablet...)  128 (4.39%)
 Apple's one-button mouse  423 (14.50%)
 Apple's Bluetooth mouse  192 (6.58%)
 Non-Apple one-button mouse  5 (0.17%)
 Two-button mouse  366 (12.54%)
 Three-button mouse  632 (21.66%)
 Four-button mouse  123 (4.22%)
 Five-button mouse  333 (11.41%)
 Six-button mouse  52 (1.78%)
 Seven-button mouse  85 (2.91%)
 'Too many buttons to count' mouse  131 (4.49%)
 2,918 votes

This is probably not a representative sample, but it's all I found. I guess
the bluetooth mouse has one button? If so, this sample shows 620 for 1
button, 366 for 2 buttons, 632 for 3 buttons, and 434 for over 3 buttons.

> It is absolutely not obvious that the right mouse button is
> mapped to mouse-3.

AFAIK, the right button (whatever and wherever it might be) is not
necessarily mapped to `mouse-3'; one of the mouse buttons is mapped to
`mouse-3' - perhaps typically by default the one that is on the right.

The name `mouse-3' does not imply a spatial relation such as "on the right",
and that is the beauty of it: it represents something logical; it does not
(directly) represent something physical.

Now, maybe we should have a short doc section saying what typical relations
there are between the `mouse-1' etc. logical buttons and physical buttons
for different systems etc. Where `mouse-2' is if you have only two buttons,
etc. (Perhaps we have that already?) But that's not a reason to rename to
`left' etc.

> > On the contrary: `mouse-1' is just an identifier; it signifies
> > nothing about physical button location. `Left' implies a spatial
> > relation that might not be correct.
>
> It will be correct unless the user has remapped it, in which case
> they'd know.

Maybe, maybe not. And even when it is accurate, it is not the right way to
refer to it in the doc. At least not a doc that also involves Emacs Lisp and
customization. It is OK to speak of `right' button informally in some parts
of the Emacs user doc, but it is more accurate to mention the defined
(Emacs-Lisp) name for this: `mouse-3'. And it would be wrong, IMO, to change
that Lisp name to `right'.

> Actually, I think "click" and "right click"/"secondary click" would
> be good, too, because mouse-1 is usually the default, no matter
> whether the user is a leftie. (Remember that on Macs, there is no
> right mouse button - control-click is used instead!)

Good for what - do you mean as substitutes for `mouse-1' and `mouse-3'? If
so, then I disagree. A button identifier should not imply any specific
action. You can do more with a mouse button than just click it.

It is true that the actions `right-click' and `click' (being understood as
`left-click') refer to physical button positions, which is not strictly
correct. But it is common usage. It might be clearer to always say "click
`mouse-3'" but casual use of `right-click' is OK now and then, IMO.

> If the user customizes this in Emacs, I presume we don't display
> `mouse-n', but the actual binding, right? Or is that tooltip hardcoded?

Dunno. I hope it depends on whether we are referring to the operation
associated with the particular mouse action or to the mouse button itself.
There is nothing wrong with "Click `mouse-2' to paste copied text".

> But while we are debating whether to call it mouse-1 and -3, I'd like
> to point out that a good UI will normally do what is most obvious and
> what the user expects.

Agreed. That is, what the user expects and should expect in the context of a
given application and its UI.

Expectations of Internet Explorer users are pertinent only to a limited
degree for an application such as Emacs. We should accomodate them only when
that doesn't interfere with the best UI possible for what users need to be
able to do in Emacs.

> That means that the right mouse button should
> bring up a context menu and not delete something

That doesn't follow.

> - this is the standard on most systems and platforms, I believe.

Oh, OK. Yes, it is common, at least.

I too favor more use of `mouse-3' context menus, but remember that the Emacs
UI is particular in many respects. Its mouse use is different (superior) in
several ways, and Emacs has the particularity that nearly every key and
button combination can be (and is) exploited in some way. Emacs need not be
drawn down systematically to the lowest-common-denominator of inferior UIs
in the name of consistency or the principle of least surprise for new users.
Trying to accomodate external convention and new users is one consideration,
but not the only one.

I am in favor of more mouse menus (`mouse-3'), but they should not interfere
with other, more important mouse uses. For example, in text editing,
`mouse-3' should not bring up a menu; it should continue to extend and kill
the region. For that reason, in Emacs, `mouse-3' context menus should in
many contexts involve a modifier key, e.g., `C-mouse-3' and not just
`mouse-3'.

> At least on the Mac and on Windows, the middle mouse-button is mapped
> centrally to something else. I have it mapped to a double-click.
>
> Applications interpret a left click to set the text cursor, mark text
> (dragging), activate/toggle buttons and follow links. The secondary
> mouse button always brings up a context menu - I can't think of a
> common application that doesn't do that (except Emacs).

I can't think of an application that does what Emacs does, in general. Its
UI is bound to differ. We must not slavishly copy what exists elsewhere, but
we can accomodate convention when it does not detract from useful Emacs
features and fits harmoniously with the rest of Emacs.

> Double-clicks open or start things, usually in a new frame or window.

Double- and triple-clicks also often select different text entities, in many
UIs, and that since mice have existed.

> I don't know what it means in the context of Emacs. One thing it
> translates to is showing *Messages* on double-click in the echo area,
> not on a simple mouse-1 (which can happen by chance occasionally).

I don't have a strong opinion about that. But I don't see the objection to a
single-click in an environment where a single-click is not otherwise useful.
What is gained by requiring a double-click? Your argument seems to be that
because "double-clicks open or start things" in general, a user should be
required to double-click to bring up *Messages* from the minibuffer. I don't
follow that.

IIRC, this feature was added because users often try to click in the
minibuffer to put the cursor there, as if they could activate it that way,
or, even more typically, they try to select text that is part of a message
in the echo area. For that, it is entirely appropriate to show them
*Messages* as soon as they have clicked (not double-clicked) there.

[FWIW, in my own code, a `mouse-2' click in an inactive minibuffer brings up
`M-x'. It is a shortcut to entering a command.]

> Doing something such as closing a window requires clicking on an
> explicit closer button. The idea to have that in the mode-line was,
> thus, a good one, even though it'll close the window above and not
> below (the button that is displayed can make that clear graphically).

Agreed, though I'm not convinced that a directional graphic is that
necessary. I have nothing against it, however, if it is clear. The advantage
of `X' is that it is commonly recognized to mean close or delete. (I liked
David's suggestion to turn the `X' upside down.)