RE: address@hidden: Customize value menudoesn'trecognizemouse-2]

[Drew Adams]

    >     > From: "Drew Adams" <address@hidden>
    >     >     > From: Richard Stallman <address@hidden>
    >     >     >
    >     >     > On GNU/Linux, probably with Lucid menus, I can select from
    >     >     > the menu using any of the three mouse buttons.
    >     >     >
    >     >     >      (The latter part happens only on MS-Windows.)
    >     >     >
    >     >     > It sounds like a bug in the way menus work in
    >     >     > Emacs on Windows.
    >     >
    >     > What Richard described for the other platforms is exactly the
    >     > behavior I requested when I filed this bug.

    I'm confused: what are you saying here about how the problem at hand
    should be fixed?

I have nothing to say about how the problem should be fixed. I reported what
the problem was, and I have an opinion about what the correct behavior could
be, but I have no opinion on how to implement a fix.

    From my perspective, mouse-2 in menus now performs on Windows as it
    does in other Windows GUI programs and as it works with some toolkits
    on X.  mouse-2 on a button in Customize, which drops the value menu
    does _not_ behave as on X.

    Given these facts and the fact that mouse-2 behavior on Windows in
    both these types of menu msut be the same, what would you want that
    uniform behavior to be?

I thought I made that clear from the start, but let me try to be clearer.

As I said in this bug report, I would prefer that mouse-2 be able to open
the value menu if and only if mouse-2 can also select from that menu. The
same should be true of any mouse button: it should open a menu if and only
if it can also use the menu (select from it).

I feel the same about other menus, but this report was only about the
Customize value menu. If all kinds of menus cannot be fixed this way, then
let's at least fix as many as we can. It doesn't make sense for a user to
discover that s?he can open a menu with a mouse button but cannot select
from that menu with the same button. That seems obvious, to me.

I also feel that this general principle should apply to all platforms, if
possible. If there are trade-offs that must be made, however - for example,
accept inconsistency across platforms vs accept inconsistency within a
platform, then we can discuss those in context.

Speaking generally, my personal preference, though it is not a strong one,
is that it is usually more important to have consistency within Emacs on a
given platform than it is to have consistency across platforms - provided
that within-platform consistency is a move toward better interaction and not
a downgrade to a consistent but poorer UI.

That proviso points to another general principle that I support: Avoid
reducing quality in the name only of consistency, whether it be consistency
within a platform or across platforms. IOW, a lowest-common-denominator that
is based solely on the rationale of consistency is not the ideal, for me. We
should try to move up toward consistency, not down to it.

The reason I think that within-platform consistency is generally more
important is that a user spends more time within Emacs on one platform:
cross-platform use of Emacs is generally less than within-platform use. So,
inconsistency across platforms will tend to perturb users less than
inconsistency within a platform. Note: "generally", "tend to" - this is only
a general heuristic; YMMV.

If the choice were, say, to fix this completely in Windows, making mouse use
consistent across mouse buttons, but such consistency were not possible now
in some other platform for some reason, then I would still prefer that fix
to the "fix" of bringing all platforms to the same state of inconsistency in
the mouse behavior, in the name of cross-platform consistency. Ratchet
consistency upward, only.

As I said, however: 1) if trade-offs are needed, then let's discuss them,
and 2) my general preference for intra-platform consistency is a) not strong
and b) general, not absolute across all cases.