Re: [multi-tty] xt-mouse.el does not work in emacsclient frames

[Dan Nicolaescu <dann@ics.uci.edu>]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

  >     <csant@csant.info> wrote
  > 
  >     emacs -Q -nw
  >     M-x server-start RET
  >     M-x xterm-mouse-mode RET
  >     emacsclient -t
  > 
  > Both when I start (with many arguments) a multi-tty Emacs in an RXVT
  > shell with -nw and when I start it in X (also with many arguments,
  > mostly the same), if I then run emacsclient -t in another RXVT shell,
  > and then turn on xterm-mouse-mode, the mouse works fine in both the
  > original instance and in the client.
  > 
  > (Not using the vcursor patch.)
  > 
  > When I start the multi-tty Emacs instance in an RXVT, the order in
  > which I start xterm-mouse-mode and emacsclient -t does not matter.
  > 
  > But when I start the multi-tty Emacs instance in X, the order does
  > matter.  When I start xterm-mouse-mode in the original in X before
  > starting emacsclient -t, then mouse mode fails in the client, although
  > when I invoke xterm-mouse-mode in the client, I receive the message
  > about disabling the mouse mode.  If I then invoke it again in the
  > client, mouse mode succeeds.

This behavior is not expected. 

Here is what xterm-mouse-mode does in order to do its job: 
- send an escape sequence to the terminal to tell it to send events
for mouse activity
- set up a function that processes the mouse events

In the multi-tty world when turning on xterm-mouse-mode the above
needs to be done for all the existing tty frames, and it would need to
be done when a new tty frame is created (maybe by adding something to
term-init-hook?).

Anyway this should not be too hard to do, so if somebody wants to do
it, it would be great. Given that the behavior is still correct in the
single tty case, it's not a priority...