[drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Richard Stallman]

[I sent this message a few weeks ago but did not get a response.]

Would someone please DTRT and ack?

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
Date: Sun, 18 Jun 2006 13:21:54 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Customize value menu doesn't recognize mouse-2
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

emacs -Q

M-x customize-variable ad-default-compilation-action

Click mouse-2 on button Value Menu. The menu opens. Try to click
mouse-2 on a menu item - the action is unrecognized.

Mouse-2 can be used to click any links and buttons. However, if you
use it to open the Value Menu, then you cannot also use it to choose
an item in the menu. Mouse-2 should be usable for all actions,
including choosing a menu item. 

More precisely, if a mouse button opens a menu, then it should also
choose from it. If you don't want mouse-2 to choose from the menu,
then it should not be able to open the menu either. I would prefer
that mouse-2 be able to do both, but if it can do neither, then that
is acceptable.


In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2006-03-20 on W2ONE
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Custom

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  line-number-mode: t

Recent input:
s s SPC s ? h e SPC c a n SPC c u s t o m i z e SPC 
s o m e t h i n g . M-q C-c C-c y e s <return> <down-mouse-1> 
<mouse-1> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> M-x c u s t o m i z e - a p 
r o o <backspace> <tab> <tab> <tab> - o p <tab> <return> 
. <return> <help-echo> <help-echo> <down-mouse-1> <mouse-1> 
q C-x 0 C-v <down-mouse-2> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <re
port-emacs-bug>

Recent messages:
Creating customization items ...96%
Loading whitespace...done
Creating customization items ...98% [9 times]
Loading winner...done
Creating customization items ...99% [6 times]
Loading xt-mouse...done
Creating customization items ...done
Resetting customization items...done
Creating customization setup...done
To install your edits, invoke [State] and choose the Set operation



_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Chong Yidong]

> From: "Drew Adams" <drew.adams@oracle.com>
> Subject: Customize value menu doesn't recognize mouse-2
>
> emacs -Q
>
> M-x customize-variable ad-default-compilation-action
>
> Click mouse-2 on button Value Menu. The menu opens. Try to click
> mouse-2 on a menu item - the action is unrecognized.

On GNU/Linux, with either GTK or no X toolkit, the value menu goes
away when I release the mouse button; selection is done by holding the
mouse button and moving the cursor over the menu item.  It works with
both mouse-1 and mouse-2.

Maybe this is Windows-specific behavior.

Re: [drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 24 Jul 2006 15:19:20 -0400
> Cc: emacs-devel@gnu.org
> 
> > From: "Drew Adams" <drew.adams@oracle.com>
> > Subject: Customize value menu doesn't recognize mouse-2
> >
> > emacs -Q
> >
> > M-x customize-variable ad-default-compilation-action
> >
> > Click mouse-2 on button Value Menu. The menu opens. Try to click
> > mouse-2 on a menu item - the action is unrecognized.
> 
> On GNU/Linux, with either GTK or no X toolkit, the value menu goes
> away when I release the mouse button; selection is done by holding the
> mouse button and moving the cursor over the menu item.  It works with
> both mouse-1 and mouse-2.
> 
> Maybe this is Windows-specific behavior.

Yes, it is, and it's deliberate: as long as the menu is active, the
Windows version ignores the middle and the right mouse clicks; you
must use the left button only to select menu items.

This behavior was introduced by this change:

    2006-03-11  Eli Zaretskii  <eliz@gnu.org>

	    * w32fns.c (w32_wnd_proc): Ignore middle and extra button events
	    if a menu is already active (the menubar_active flag is on).

The reason was a much more annoying problem reported by Drew in this
thread:

  http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-03/msg00024.html

Drew, I don't see any particular problem in asking Windows users to
click the left button, even if they are in a menu dropped by the right
button.  Do you?  (FWIW, I never select with the right button, even in
other GUI applications.)

RE: [drew.adams@oracle.com: Customize value menu doesn't recognizemouse-2]

[Drew Adams]

    > > emacs -Q
    > >
    > > M-x customize-variable ad-default-compilation-action
    > >
    > > Click mouse-2 on button Value Menu. The menu opens. Try to click
    > > mouse-2 on a menu item - the action is unrecognized.
    >
    > On GNU/Linux, with either GTK or no X toolkit, the value menu goes
    > away when I release the mouse button; selection is done by holding the
    > mouse button and moving the cursor over the menu item.  It works with
    > both mouse-1 and mouse-2.
    >
    > Maybe this is Windows-specific behavior.

    Yes, it is, and it's deliberate: as long as the menu is active, the
    Windows version ignores the middle and the right mouse clicks; you
    must use the left button only to select menu items.

    This behavior was introduced by this change:

        2006-03-11  Eli Zaretskii  <eliz@gnu.org>

    	    * w32fns.c (w32_wnd_proc): Ignore middle and extra button events
    	    if a menu is already active (the menubar_active flag is on).

    The reason was a much more annoying problem reported by Drew in this
    thread:


http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-03/msg00024.html

    Drew, I don't see any particular problem in asking Windows users to
    click the left button, even if they are in a menu dropped by the right
    button.  Do you?  (FWIW, I never select with the right button, even in
    other GUI applications.)

1. It would be good if the behavior were the same on Windows as other
platforms, if that were possible.

2. It would be good if either a) you could neither open the menu nor choose
a menu item using mouse-2 or b) you could both open the menu and choose a
menu item using mouse-2. It is the combination of being able to open the
menu using mouse-2 but not being able to choose a menu item using mouse-2
that seems wrong.

Re: [drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 24 Jul 2006 13:52:39 -0700
> 
>     This behavior was introduced by this change:
> 
>         2006-03-11  Eli Zaretskii  <eliz@gnu.org>
> 
>     	    * w32fns.c (w32_wnd_proc): Ignore middle and extra button events
>     	    if a menu is already active (the menubar_active flag is on).
> 
>     The reason was a much more annoying problem reported by Drew in this
>     thread:
> 
> 
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-03/msg00024.html
> 
>     Drew, I don't see any particular problem in asking Windows users to
>     click the left button, even if they are in a menu dropped by the right
>     button.  Do you?  (FWIW, I never select with the right button, even in
>     other GUI applications.)
> 
> 1. It would be good if the behavior were the same on Windows as other
> platforms, if that were possible.

Sorry, I don't know how to do that without introducing worse
problems.  If someone else knows, please speak up.

> 2. It would be good if either a) you could neither open the menu nor choose
> a menu item using mouse-2 or b) you could both open the menu and choose a
> menu item using mouse-2.

Richard, should I go ahead and remove the mouse-2 binding for
widget-button-click?  I could do that either for MS-Windows or for all
platforms.

Btw, why do we bind both buttons to the same action here?

Re: [drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Luc Teirlinck]

Eli Zaretskii wrote:

   Richard, should I go ahead and remove the mouse-2 binding for
   widget-button-click?  I could do that either for MS-Windows or for all
   platforms.

There is no need to remove it on other platforms, because there is no
bug on other platforms.

   Btw, why do we bind both buttons to the same action here?

Because mouse-2 has this kind of functionality in other Emacs buffers
and because people who have mouse-1-click-follows-link set to nil are
used to use mouse-2 for this kind of functionality.

Sincerely,

Luc.

Re: [drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Richard Stallman]

    Richard, should I go ahead and remove the mouse-2 binding for
    widget-button-click?  I could do that either for MS-Windows or for all
    platforms.

What would be the purpose of this?  I did not follow the previous
discussion.

Re: [drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Mon, 31 Jul 2006 00:38:54 -0400
> 
>     Richard, should I go ahead and remove the mouse-2 binding for
>     widget-button-click?  I could do that either for MS-Windows or for all
>     platforms.
> 
> What would be the purpose of this?  I did not follow the previous
> discussion.

Right now, you can pop the value menu by clicking mouse-2, but you
cannot select items from that menu with mouse-2, you need to use
mouse-1 for that.  (The latter part happens only on MS-Windows.)

Re: [drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Richard Stallman]

    Right now, you can pop the value menu by clicking mouse-2, but you
    cannot select items from that menu with mouse-2, you need to use
    mouse-1 for that.

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.

To make Mouse-2 stop working on buttons in Emacs would be an
incompatible change that would affect all buttons, not just those
that lead to menus.  It would be a step for the worse.
Please leave things alone.

Re: [drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Mon, 31 Jul 2006 18:17:32 -0400
> 
> It sounds like a bug in the way menus work in Emacs on Windows.

Actually, the code in w32menu.c is written to explicitly ignore clicks
on any button but mouse-1 as long as a menu is open.  This was done to
solve a much more annoying bug on Windows, whereby, if you click
mouse-2 while browsing a menu, Emacs would yank killed text after the
menu pops down.

> Please leave things alone.

Done.

RE: [drew.adams@oracle.com: Customize value menu doesn't recognizemouse-2]

[Drew Adams]

    > From: Richard Stallman <rms@gnu.org>
    >
    > 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.

    Actually, the code in w32menu.c is written to explicitly ignore clicks
    on any button but mouse-1 as long as a menu is open.  This was done to
    solve a much more annoying bug on Windows, whereby, if you click
    mouse-2 while browsing a menu, Emacs would yank killed text after the
    menu pops down.

    > Please leave things alone.

    Done.

What Richard described for the other platforms is exactly the behavior I
requested when I filed this bug. It sounds to me like the fix for the more
annoying bug (which I also reported, I believe) was not the right fix.
Wouldn't the right fix have been to make mouse-2 select a menu item, just
like on GNU/Linux? That would take care of both bugs, and bring Windows into
line with the other platforms.

IOW, "Please leave things alone" ... "Done" sounds like a quick cop-out, to
me.

I can't speak to hard it might be to fix this properly, so that Windows will
DTRT, like GNU/Linux, but I can speak to what TRT would be for the user:
exactly what Richard described.

Re: [drew.adams@oracle.com: Customize value menu doesn't recognizemouse-2]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 31 Jul 2006 20:33:41 -0700
> 
>     > From: Richard Stallman <rms@gnu.org>
>     >
>     > 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 not sure you interpret what Richard wrote correctly: I think he
was talking about the value menu dropped when one presses on a button
inside a Customize buffer, whereas you seem to interpret that as a
more general statement about menus in general.  See below about the
latter.

> It sounds to me like the fix for the more
> annoying bug (which I also reported, I believe) was not the right fix.
> Wouldn't the right fix have been to make mouse-2 select a menu item, just
> like on GNU/Linux? That would take care of both bugs, and bring Windows into
> line with the other platforms.

Actually, what happens when you click mouse-2 in a menu on X depends
on the toolkit, AFAICS.  Xt and GTK indeed behave like you say, but
Motif behaves like MS-Windows: mouse-2 is ignored in menus, and you
need to use mouse-1.  I looked in a couple of other GUI applications
on Windows, and it looks like they ignore mouse-2 in menus.

With buttons in Customize, it's different: there all toolkits I could
try behave as Richard described, probably because Emacs itself handles
the click.

So, at least for menus in general, this doesn't sound like a behavior
aspect that is consistent across platforms.

> IOW, "Please leave things alone" ... "Done" sounds like a quick cop-out, to
> me.

Richard asked to do nothing, so I complied.

> I can't speak to hard it might be to fix this properly, so that Windows will
> DTRT, like GNU/Linux, but I can speak to what TRT would be for the user:
> exactly what Richard described.

Even though other GUI programs behave on Windows like we do now?

RE: [drew.adams@oracle.com: Customize value menu doesn'trecognizemouse-2]

[Drew Adams]

    > From: "Drew Adams" <drew.adams@oracle.com>
    >     > From: Richard Stallman <rms@gnu.org>
    >     >
    >     > 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 not sure you interpret what Richard wrote correctly: I think he
    was talking about the value menu dropped when one presses on a button
    inside a Customize buffer, whereas you seem to interpret that as a
    more general statement about menus in general.

I filed the bug about the value menu in Customize - see the Subject line.

If all menus behaved the same everywhere in Emacs, and on all platforms,
that would be even better, but that was not what I reported or requested.

The other bug I reported, whose fix apparently caused this bug, was about
the menu-bar menu, IIRC.

Re: [drew.adams@oracle.com: Customize value menu doesn'trecognizemouse-2]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 1 Aug 2006 06:43:08 -0700
> 
>     > From: "Drew Adams" <drew.adams@oracle.com>
>     >     > From: Richard Stallman <rms@gnu.org>
>     >     >
>     >     > 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 not sure you interpret what Richard wrote correctly: I think he
>     was talking about the value menu dropped when one presses on a button
>     inside a Customize buffer, whereas you seem to interpret that as a
>     more general statement about menus in general.
> 
> I filed the bug about the value menu in Customize - see the Subject line.

I know that.  I was talking about interpretation of what Richard said,
and your reaction to it.

> If all menus behaved the same everywhere in Emacs, and on all platforms,
> that would be even better, but that was not what I reported or requested.
> 
> The other bug I reported, whose fix apparently caused this bug, was about
> the menu-bar menu, IIRC.

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

>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?

RE: [drew.adams@oracle.com: Customize value menudoesn'trecognizemouse-2]

[Drew Adams]

    >     > From: "Drew Adams" <drew.adams@oracle.com>
    >     >     > From: Richard Stallman <rms@gnu.org>
    >     >     >
    >     >     > 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.

Re: [drew.adams@oracle.com: Customize value menudoesn'trecognizemouse-2]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 1 Aug 2006 08:19:44 -0700
> 
>     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).

My preference is to unbind mouse-2 on buttons, at least for
MS-Windows.  This will make behavior on all platforms consistent, as
you would like.  But Richard asked not to make such a change, so my
hands are tied.

> 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.

Other menus already behave consistently, at least on Windows: you
cannot drop a menu with mouse-2, and you cannot select a menu item
with mouse-2.

RE: [drew.adams@oracle.com: Customize valuemenudoesn'trecognizemouse-2]

[Drew Adams]

    > 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).

    My preference is to unbind mouse-2 on buttons, at least for
    MS-Windows.  This will make behavior on all platforms consistent, as
    you would like.  But Richard asked not to make such a change, so my
    hands are tied.

IIUC, Richard didn't say that you couldn't let mouse-2 select menu items in
the value menu, in addition to opening the menu. My "if and only if", stated
from the beginning, allows for this. The subject line complains, in fact,
that mouse-2 does not let you select a menu item.

My only complaint here is the inconsistency between letting you open the
menu but not letting you select from it - with the same mouse button.

    > 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.

    Other menus already behave consistently, at least on Windows: you
    cannot drop a menu with mouse-2, and you cannot select a menu item
    with mouse-2.

As I said, one thing at a time.

It's more important to have local consistency (consistency for mouse
buttons, within the same general action - in this case, using the value
menu) than it is to have global consistency (in this case, consistency for
mouse buttons across all menus).

The idea seems simple to me: if someone uses mouse-2 on the value menu, so
the menu opens, then s?he will expect to also be able to select a menu item
with the same mouse button. Opening a menu and selecting an item in the menu
are thought of as part of the same overall act. Don't you agree? We usually
open menus to use them. No one thinks of switching mouse buttons mid-stream.

To me, it's OK to not let mouse-2 do either: open or choose. And it's OK to
let mouse-2 do both: open and choose. To me, it's not OK to do one but not
the other.

And, apparently, for Richard it's not OK to not let mouse-2 open. So,...

Re: [drew.adams@oracle.com: Customize valuemenudoesn'trecognizemouse-2]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 1 Aug 2006 09:16:01 -0700
> 
>     My preference is to unbind mouse-2 on buttons, at least for
>     MS-Windows.  This will make behavior on all platforms consistent, as
>     you would like.  But Richard asked not to make such a change, so my
>     hands are tied.
> 
> IIUC, Richard didn't say that you couldn't let mouse-2 select menu items in
> the value menu, in addition to opening the menu.

If we allow that, we will get inconsistent behavior with other menus,
such as the one that's dropped from the menu bar, because where mouse
events are handled, we don't know what flavor of menu is being
processed.

Allowing mouse-2 on the menu bar is not a good idea, IMO, hence my
preference above.

> To me, it's OK to not let mouse-2 do either: open or choose. And it's OK to
> let mouse-2 do both: open and choose. To me, it's not OK to do one but not
> the other.
> 
> And, apparently, for Richard it's not OK to not let mouse-2 open. So,...

And to me, it's not OK to let mouse-2 drop menu-bar menus.  So,...

RE: [drew.adams@oracle.com: Customizevaluemenudoesn'trecognizemouse-2]

[Drew Adams]

    > IIUC, Richard didn't say that you couldn't let mouse-2 select
    > menu items in the value menu, in addition to opening the menu.

    If we allow that, we will get inconsistent behavior with other menus,
    such as the one that's dropped from the menu bar, because where mouse
    events are handled, we don't know what flavor of menu is being
    processed.

    Allowing mouse-2 on the menu bar is not a good idea, IMO, hence my
    preference above.

So, you seem to be saying that we can't fix the value-menu bug without also
letting mouse-2 do the same thing for the menu-bar. That would be fine - as
I said, it would be good to fix both bugs in such a way that the behavior
was the same. IOW, allowing mouse-2 to both open and choose from a menu-bar
menu would be good, not bad, especially if that was also the behavior for
the value menu.

    > To me, it's OK to not let mouse-2 do either: open or choose.
    > And it's OK to let mouse-2 do both: open and choose. To me,
    > it's not OK to do one but not the other.
    >
    > And, apparently, for Richard it's not OK to not let mouse-2
    > open. So,...

    And to me, it's not OK to let mouse-2 drop menu-bar menus.  So,...

By "drop", do you mean open? If so, what is your reason?

Please don't just state that the only possibility for that would be to
return to the other bug I filed: mouse-2 mistakenly pasting when you tried
to use it to choose a menu item. Is there a good reason that mouse-2
shouldn't both open and choose from a menu-bar menu?

Re: [drew.adams@oracle.com: Customizevaluemenudoesn'trecognizemouse-2]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 1 Aug 2006 09:58:28 -0700
> 
> So, you seem to be saying that we can't fix the value-menu bug without also
> letting mouse-2 do the same thing for the menu-bar.

Yes.

>     And to me, it's not OK to let mouse-2 drop menu-bar menus.  So,...
> 
> By "drop", do you mean open?

Yes.

> If so, what is your reason?

That GUI applications don't do that.  So, unless we let mouse-2 drop
menus from the menu bar on other platforms as well (personally, I
think we shouldn't, certainly not at this time), I'd object to do that
only on Windows.

Re: [drew.adams@oracle.com: Customizevaluemenudoesn'trecognizemouse-2]

[rms]

    That GUI applications don't do that.  So, unless we let mouse-2 drop
    menus from the menu bar on other platforms as well (personally, I
    think we shouldn't, certainly not at this time), I'd object to do that
    only on Windows.

On my platform, all three mouse buttons work to activate a menu bar menu
in Emacs.

Re: [drew.adams@oracle.com: Customizevaluemenudoesn'trecognizemouse-2]

[Eli Zaretskii]

> From:  <rms@gnu.org>
> CC: drew.adams@oracle.com, emacs-devel@gnu.org
> Date: Tue, 01 Aug 2006 23:38:17 -0400
> 
>     That GUI applications don't do that.  So, unless we let mouse-2 drop
>     menus from the menu bar on other platforms as well (personally, I
>     think we shouldn't, certainly not at this time), I'd object to do that
>     only on Windows.
> 
> On my platform, all three mouse buttons work to activate a menu bar menu
> in Emacs.

This depends on the toolkit, as I already wrote in this thread.  (For
example, Motif doesn't let mouse-2 or mouse-3 activate the menu-bar
menu, AFAICS.)  It probably also depends on mouse bindings in the
window manager configuration files.  I don't think Emacs does anything
to bind mouse buttons on the menu bar.

On MS-Windows, the window manager invokes menu-bar actions only for
mouse-1.  So letting only that button activate the value menu in a
Customize buffer seems consistent to me.

Re: [drew.adams@oracle.com: Customizevaluemenudoesn'trecognizemouse-2]

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> This depends on the toolkit, as I already wrote in this thread.  (For
> example, Motif doesn't let mouse-2 or mouse-3 activate the menu-bar
> menu, AFAICS.)  It probably also depends on mouse bindings in the
> window manager configuration files.  I don't think Emacs does anything
> to bind mouse buttons on the menu bar.
>
> On MS-Windows, the window manager invokes menu-bar actions only for
> mouse-1.  So letting only that button activate the value menu in a
> Customize buffer seems consistent to me.

Are you talking about the value menu in the buffer (accessible by
button) or the one in the menu bar?  I could agree with the latter,
but not with the former.  Buttons have in all released versions of
Emacs so far required mouse-2 presses on buttons (only customize
buttons already had special code permitting mouse-1), so we should not
disable this behavior in a single version leap.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [drew.adams@oracle.com: Customizevaluemenudoesn'trecognizemouse-2]

[Eli Zaretskii]

> Cc: rms@gnu.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 02 Aug 2006 08:17:52 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This depends on the toolkit, as I already wrote in this thread.  (For
> > example, Motif doesn't let mouse-2 or mouse-3 activate the menu-bar
> > menu, AFAICS.)  It probably also depends on mouse bindings in the
> > window manager configuration files.  I don't think Emacs does anything
> > to bind mouse buttons on the menu bar.
> >
> > On MS-Windows, the window manager invokes menu-bar actions only for
> > mouse-1.  So letting only that button activate the value menu in a
> > Customize buffer seems consistent to me.
> 
> Are you talking about the value menu in the buffer (accessible by
> button) or the one in the menu bar?

I'm talking about both, but the value menu part is only about the buttons
in the Customize buffers.

RE: [drew.adams@oracle.com:Customizevaluemenudoesn'trecognizemouse-2]

[Drew Adams]

    > On my platform, all three mouse buttons work to activate a
    > menu bar menu in Emacs.

    This depends on the toolkit, as I already wrote in this thread.

Let's not level toward the lowest common denominator, at least in this case.
Let's get as many platforms (and toolkits) as we can to work reasonably and
consistently.

Re: [drew.adams@oracle.com: Customize valuemenudoesn'trecognizemouse-2]

[rms]

    > IIUC, Richard didn't say that you couldn't let mouse-2 select menu items in
    > the value menu, in addition to opening the menu.

    If we allow that, we will get inconsistent behavior with other menus,

Why do you think so?

    such as the one that's dropped from the menu bar, because where mouse
    events are handled, we don't know what flavor of menu is being
    processed.

    Allowing mouse-2 on the menu bar is not a good idea,

Why do you think so?

							 IMO, hence my
    preference above.

Re: [drew.adams@oracle.com: Customize valuemenudoesn'trecognizemouse-2]

[Eli Zaretskii]

> From:  <rms@gnu.org>
> CC: drew.adams@oracle.com, emacs-devel@gnu.org
> Date: Tue, 01 Aug 2006 23:38:15 -0400
> 
>     > IIUC, Richard didn't say that you couldn't let mouse-2 select menu items in
>     > the value menu, in addition to opening the menu.
> 
>     If we allow that, we will get inconsistent behavior with other menus,
> 
> Why do you think so?

Because on the menu bar, mouse-2 doesn't activate the menu on
MS-Windows (and with some X toolkits, such as Motif).

>     such as the one that's dropped from the menu bar, because where mouse
>     events are handled, we don't know what flavor of menu is being
>     processed.
> 
>     Allowing mouse-2 on the menu bar is not a good idea,
> 
> Why do you think so?

Because many users don't expect that, I think, at least not on
platforms whose window manager doesn't do that by default, or ever.

RE: [drew.adams@oracle.com: Customizevaluemenudoesn'trecognizemouse-2]

[Drew Adams]

    Because on the menu bar, mouse-2 doesn't activate the menu on
    MS-Windows (and with some X toolkits, such as Motif).

So, let the inconsistency appear there, where it won't hurt: If mouse-2
cannot open the menu-bar menu, then there is no harm in letting mouse-2
choose an item from the menu (if opened by mouse-1).

In that case, the inconsistency 1) allows more functionality, not less, and
2) will not arise, in practice, because the inability occurs in the
initiating action, _opening_ the menu, not in the followup action, choosing
from it.

IOW, it is better to 1) have mouse-2 be unable to open the (menu-bar) menu
(even if it lets you select from it, once opened) than to 2) let mouse-2
open the (Customize value) menu but then not let you select from it. Users
will fall into a trap with #2, but not with #1.

Re: [drew.adams@oracle.com: Customize valuemenudoesn'trecognizemouse-2]

[Richard Stallman]

    >     If we allow that, we will get inconsistent behavior with other menus,
    > 
    > Why do you think so?

    Because on the menu bar, mouse-2 doesn't activate the menu on
    MS-Windows (and with some X toolkits, such as Motif).

No wonder you have confused me.  Here you're saying "menus", but
really you're talking about the behavior of the buttons in the menu
bar.  Those are comparable to the buttons in the buffer, in that both
pop up another menu.

Mouse-2 is the only way to click on a button in the buffer in Emacs
21.  I do not want to change to making it not work at all.  it will
continue to activate these buttons.

    >     Allowing mouse-2 on the menu bar is not a good idea,
    > 
    > Why do you think so?

    Because many users don't expect that, I think, at least not on
    platforms whose window manager doesn't do that by default, or ever.

Does Mouse-2 on the menu bar in those platforms do anything useful?
I would think not.

If not, then there is no reason not to make it activate menu bar menus
(if that is possible; it may be impossible).  For greatest
consistency, we would want to make more mouse buttons do that, on
whatever platforms we can.

    Even though, if a user clicks mouse-2 on a button to open the value
    menu, she will then need to use only mouse-1 to select items from that
    menu?  That doesn't seem a good UI to me.

I agree, it would be better to make _all_ menus allow mouse-2 as well,
if we can.

If that is impossible, users who use mouse-2 to click on the button will
get this quirky result, just as they do in Emacs 21.


It's better than the inconsistency you want.
And it happens

Re: [drew.adams@oracle.com: Customize value menudoesn'trecognizemouse-2]

[rms]

    My preference is to unbind mouse-2 on buttons, at least for
    MS-Windows.  This will make behavior on all platforms consistent, as
    you would like.  But Richard asked not to make such a change, so my
    hands are tied.

Mouse-2 is the standard way to activate anything in the buffer in Emacs.
Mouse-1 also works but with some complications.
I don't think we should make anything that fails to activate with Mouse-2.

Re: [drew.adams@oracle.com: Customize value menudoesn'trecognizemouse-2]

[Eli Zaretskii]

> From:  <rms@gnu.org>
> CC: drew.adams@oracle.com, emacs-devel@gnu.org
> Date: Tue, 01 Aug 2006 23:38:13 -0400
> 
>     My preference is to unbind mouse-2 on buttons, at least for
>     MS-Windows.  This will make behavior on all platforms consistent, as
>     you would like.  But Richard asked not to make such a change, so my
>     hands are tied.
> 
> Mouse-2 is the standard way to activate anything in the buffer in Emacs.
> Mouse-1 also works but with some complications.
> I don't think we should make anything that fails to activate with Mouse-2.

Even though, if a user clicks mouse-2 on a button to open the value
menu, she will then need to use only mouse-1 to select items from that
menu?  That doesn't seem a good UI to me.

RE: [drew.adams@oracle.com: Customize valuemenudoesn'trecognizemouse-2]

[Drew Adams]

    > Mouse-2 is the standard way to activate anything in the
    > buffer in Emacs. Mouse-1 also works but with some complications.
    > I don't think we should make anything that fails to activate
    > with Mouse-2.

    Even though, if a user clicks mouse-2 on a button to open the value
    menu, she will then need to use only mouse-1 to select items from that
    menu?  That doesn't seem a good UI to me.

My bug report was precisely to eliminate that inconsistency and annoyance.
But, as I stated, I would prefer that consistency be achieved by upgrading,
not downgrading: mouse-2 should both open the value menu and let you choose
an item from it.

Re: [drew.adams@oracle.com: Customize valuemenudoesn'trecognizemouse-2]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Wed, 2 Aug 2006 09:16:29 -0700
> 
>     > Mouse-2 is the standard way to activate anything in the
>     > buffer in Emacs. Mouse-1 also works but with some complications.
>     > I don't think we should make anything that fails to activate
>     > with Mouse-2.
> 
>     Even though, if a user clicks mouse-2 on a button to open the value
>     menu, she will then need to use only mouse-1 to select items from that
>     menu?  That doesn't seem a good UI to me.
> 
> My bug report was precisely to eliminate that inconsistency and annoyance.
> But, as I stated, I would prefer that consistency be achieved by upgrading,
> not downgrading: mouse-2 should both open the value menu and let you choose
> an item from it.

Drew, you've told this about umpteen times already, and I'm sure we
all understood you the first time.  Please try to refrain from
repeating the same text again and again, this thread is long as it is
already.

TIA

Re: [drew.adams@oracle.com: Customize value menu doesn'trecognizemouse-2]

[rms]

Is it really true that different menus inside Emacs handle mouse
clicks differently on Windows?  That is surprising -- isn't it the
same code handling all of them?

Re: [drew.adams@oracle.com: Customize value menu doesn'trecognizemouse-2]

[Eli Zaretskii]

> From: <rms@gnu.org>
> Date: Tue, 01 Aug 2006 23:38:08 -0400
> Cc: emacs-devel@gnu.org
> 
> Is it really true that different menus inside Emacs handle mouse
> clicks differently on Windows?

No, the menus behave the same.  The problem is _not_ with the menu,
it's with how one _activates_ the menu.  In the menu bar, we don't
bind mouse buttons to actions; rather, the window manager returns us
events that cause us to activate the menu; the MS-Windows window
manager does that only for mouse-1 clicks.  By contrast, in a
Customize buffer _we_ bind mouse-1 and mouse-2 on the "Value Menu"
button to drop down a menu, so mouse-2 also works there.

> That is surprising -- isn't it the same code handling all of them?

Once the menu is activated, it is the same code, yes.

[drew.adams@oracle.com: Customize value menu doesn't recognize mouse-2]

[Richard Stallman]

Would someone please DTRT and ack?

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
Date: Sun, 18 Jun 2006 13:21:54 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Customize value menu doesn't recognize mouse-2
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

emacs -Q

M-x customize-variable ad-default-compilation-action

Click mouse-2 on button Value Menu. The menu opens. Try to click
mouse-2 on a menu item - the action is unrecognized.

Mouse-2 can be used to click any links and buttons. However, if you
use it to open the Value Menu, then you cannot also use it to choose
an item in the menu. Mouse-2 should be usable for all actions,
including choosing a menu item. 

More precisely, if a mouse button opens a menu, then it should also
choose from it. If you don't want mouse-2 to choose from the menu,
then it should not be able to open the menu either. I would prefer
that mouse-2 be able to do both, but if it can do neither, then that
is acceptable.


In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2006-03-20 on W2ONE
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Custom

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  line-number-mode: t

Recent input:
s s SPC s ? h e SPC c a n SPC c u s t o m i z e SPC 
s o m e t h i n g . M-q C-c C-c y e s <return> <down-mouse-1> 
<mouse-1> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> M-x c u s t o m i z e - a p 
r o o <backspace> <tab> <tab> <tab> - o p <tab> <return> 
. <return> <help-echo> <help-echo> <down-mouse-1> <mouse-1> 
q C-x 0 C-v <down-mouse-2> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <re
port-emacs-bug>

Recent messages:
Creating customization items ...96%
Loading whitespace...done
Creating customization items ...98% [9 times]
Loading winner...done
Creating customization items ...99% [6 times]
Loading xt-mouse...done
Creating customization items ...done
Resetting customization items...done
Creating customization setup...done
To install your edits, invoke [State] and choose the Set operation



_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------