bug#4124: 23.1; mwheel in --daemon mode

[John Prevost <prevost1@cert.org>]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> In emacs-23 uses of window-system to initialize variables are most of
> the time bugs because window-system is not a constant anymore.  Its
> value depends of the frame it is used in, and we can have TTY and GUI
> frames in the same emacs sessions, so...

That was my assumption, yup.

> w32 does not use the daemon mode, nor can it use TTY and w32 frames at
> the same time, so it should not matter.

Hmm.  Is it not possible to start emacs in --daemon mode and use
emacsclient to open a file in w32?  I thought I had tested this and that
it had worked.  I did note that it was impossible to create tty and w32
frames at the same time.

> What happens on ns if you take the `ns' out of the memq test above, does
> it make it work?  (I don't have a mouse with a wheel, nor ns ...)

No.  The essential problem is that in 'x', the mouse wheel events are
'mouse-4' and 'mouse-5', while in 'ns' and 'w32', the mouse wheel events
are 'wheel-up' and 'wheel-down'.  The defcustom sets the default for the
events it will expect for to 'mouse-4' and 'mouse-5' (i.e. X-style
bindings), unless the window-system is ns or w32, in which case it uses
'wheel-up' and 'wheel-down'.

In fact, ns does need 'wheel-up' and 'wheel-down', so removing it from
the memq would result it in never working at all (i.e. failing always,
rather than only failing when emacs is started with --daemon).

It is possible to set the value of the mouse-wheel-down-event and
mouse-wheel-up-event variables in the user startup file to work around
this problem.  The drawback here is that either the startup
file/customization is specialized to ns/w32 (and the same startup file
cannot be used on X), or the variable has to be set in the .emacs file
based on the operating system (which is a problem if the user has both X
and NS versions of emacs on Mac OS).

Hence my suggestion that a better long-term solution is to pick one or
the other representation of the mouse-wheel as "standard" (either
mouse-4 and mouse-5 as in X or wheel-up and wheel-down as in NS and W32)
and have the term init files set up the appropriate mapping from native
events to the standard events.



In any case, it's clear that this is a problem in mwheel, and I do have
a short-term workaround.

Thanks very much,

John.