[multi-tty] Odd regression in vcursor mode in terminal

[multi-tty] Odd regression in vcursor mode in terminal

[csant]

Taking the freedom to report bugs specific to the multi-tty branch  
directly to the emacs-devel list  -  I noticed an odd regression with  
vcursor in the multi-tty branch .  I have managed to boil it down to this  
snippet from my ~/.emacs :

	(setq vcursor-key-bindings 't)
	(load "vcursor")
	(xterm-mouse-mode 1)

When loading this in ~/.emacs on a startup with
	$ ./src/emacs -nw
of a fresh compile of a checkout of the multi-tty branch, C-S-up produces  
the character `A' instead of vcursor-previous-line . However, when starting
	$ ./src/emacs -Q -nw
and then finding that file and doing a `M-x eval-last-sexp' on each of the  
three items above, everything works as expected .  Also running in X gives  
no problems .

In a fresh checkout on the trunk this works just fine .
/c

Re: [multi-tty] Odd regression in vcursor mode in terminal

[David Kastrup]

csant <csant@csant.info> writes:

> Taking the freedom to report bugs specific to the multi-tty branch
> directly to the emacs-devel list

At the current point of time, I find this appropriate.  multi-tty is
sort of being evaluated for its course into the trunk, and problems
and their fixes are quite well suited for gaining insights into what
makes it tick and what not.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [multi-tty] Odd regression in vcursor mode in terminal

[Dan Nicolaescu]

csant <csant@csant.info> writes:

  > Taking the freedom to report bugs specific to the multi-tty branch
  > directly to the emacs-devel list  -  I noticed an odd regression with
  > vcursor in the multi-tty branch .  I have managed to boil it down to
  > this  snippet from my ~/.emacs :
  > 
  > 	(setq vcursor-key-bindings 't)
  > 	(load "vcursor")
  > 	(xterm-mouse-mode 1)
  > 
  > When loading this in ~/.emacs on a startup with
  > 	$ ./src/emacs -nw
  > of a fresh compile of a checkout of the multi-tty branch, C-S-up
  > produces  the character `A' instead of vcursor-previous-line
  > . However, when starting
  > 	$ ./src/emacs -Q -nw
  > and then finding that file and doing a `M-x eval-last-sexp' on each of
  > the  three items above, everything works as expected .  Also running
  > in X gives  no problems .

Thank you for your bug report. 

If you replace function-key-map with local-function-key-map in this line in xt-mouse.el: 
(define-key function-key-map "\e[M" 'xterm-mouse-translate)

and then recompile the file and restart emacs things should work. 

But I am not convinced that this is an absolutely correct fix, so I
did not check it in. 

Re: [multi-tty] Odd regression in vcursor mode in terminal

[csant]

> If you replace function-key-map with local-function-key-map in this line  
> in xt-mouse.el:
> (define-key function-key-map "\e[M" 'xterm-mouse-translate)

Thanks, that seems to be fixing it (I should have tried it first,  
following the suggestion in xt-mouse.el...)
/c

[multi-tty] xt-mouse.el does not work in emacsclient frames (was Re: Odd regression in vcursor mode in terminal)

[csant]

> If you replace function-key-map with local-function-key-map in this line  
> in xt-mouse.el:
> (define-key function-key-map "\e[M" 'xterm-mouse-translate)
>
> and then recompile the file and restart emacs things should work.

Sorry for bothering again - but xt-mouse.el doesn't actually seem to work  
at all, in emacsclient -t multi-tty frames (above patch makes it at least  
not interfere with vcursor).  Works fine in the server emacs -nw .
/c

Re: [multi-tty] xt-mouse.el does not work in emacsclient frames (was Re: Odd regression in vcursor mode in terminal)

[Dan Nicolaescu]

csant <csant@csant.info> writes:

y  > > If you replace function-key-map with local-function-key-map in this
  > > line  in xt-mouse.el:
  > > (define-key function-key-map "\e[M" 'xterm-mouse-translate)
  > >
  > > and then recompile the file and restart emacs things should work.
  > 
  > Sorry for bothering again - but xt-mouse.el doesn't actually seem to
  > work  at all, in emacsclient -t multi-tty frames (above patch makes it
  > at least  not interfere with vcursor).  Works fine in the server emacs
  > -nw .

It seems to works fine for me, but I don't have the fix I suggested
for your issue with vcursor.el.
Can you describe your problem? 

I would not be surprised if the "fix" is actually causing the problem,
I have not had time yet to think of a real fix. 

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

[csant]

> It seems to works fine for me, but I don't have the fix I suggested
> for your issue with vcursor.el.
> Can you describe your problem?

The emacsclient's frame behaves as if it didn't load xt-mouse.

> I would not be surprised if the "fix" is actually causing the problem,
> I have not had time yet to think of a real fix.

No, same issue with or without your "fix".  Is there some more information  
that would be interesting to provide in order to work out what the  
relevant differences between our environments is?

/c

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

[Dan Nicolaescu]

csant <csant@csant.info> writes:

  > > I would not be surprised if the "fix" is actually causing the problem,
  > > I have not had time yet to think of a real fix.
  > 
  > No, same issue with or without your "fix".  Is there some more
  > information  that would be interesting to provide in order to work out
  > what the  relevant differences between our environments is?

You could describe what you are doing step by step, but start from
something that I can also reproduce: 
emacs -Q 
M-x server-start RET
etc 

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

[csant]

> You could describe what you are doing step by step

emacs -Q -nw
M-x server-start RET
M-x xterm-mouse-mode RET
emacsclient -t

and then click somewhere into the terminal - xt-mouse is actually now  
loaded, and produces some garbage on each click, instead of positioning  
the point to where you just clicked.  Clicking in the server frame will on  
the other hand correctly position the point on each click.  The same  
happens if you start emacs -Q in X (without -nw) - I just wanted to show  
that xt-mouse works fine in terminal (i.e. there is something broken only  
in the emacsclient's frame).

/c

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

[Dan Nicolaescu]

csant <csant@csant.info> writes:

  > > You could describe what you are doing step by step
  > 
  > emacs -Q -nw
  > M-x server-start RET
  > M-x xterm-mouse-mode RET

This will turn on xterm-mouse-mode for the "emacs -Q -nw" frame

  > emacsclient -t

it won't turn it on for this one. 

No surprise here, xterm-mouse-mode needs to be changed in order to be
able to properly take advantage of multi-tty... It continues to work
fine in the single tty case until that is done. 

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

[csant]

>   > emacs -Q -nw
>   > M-x server-start RET
>   > M-x xterm-mouse-mode RET
>
> This will turn on xterm-mouse-mode for the "emacs -Q -nw" frame
>
>   > emacsclient -t
>
> it won't turn it on for this one.

Not sure that's right: the mouse will pass some events to the client -  
they just get translated wrongly. Running M-x xterm-mouse-mode RET in the  
client *disables* xterm-mouse-mode, so I'd definetly say it is running.

/c

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

[Dan Nicolaescu]

csant <csant@csant.info> writes:

  > >   > emacs -Q -nw
  > >   > M-x server-start RET
  > >   > M-x xterm-mouse-mode RET
  > >
  > > This will turn on xterm-mouse-mode for the "emacs -Q -nw" frame
  > >
  > >   > emacsclient -t
  > >
  > > it won't turn it on for this one.
  > 
  > Not sure that's right: 

It is. emacs needs to send an escape sequence to xterm so that xterm
can start sending mouse tracking events. Nothing is doing it for the
"emacsclient -t" frame. Please check the code.


 > the mouse will pass some events to the client -  
  > they just get translated wrongly. Running M-x xterm-mouse-mode RET in
  > the  client *disables* xterm-mouse-mode, so I'd definetly say it is
  > running.

That's normal, you've turned it on (ie. the xterm-mouse-mode is set to
t) then you previously run M-x xterm-mouse-mode RET in the "emacs -Q
-nw" frame. 

Since you have an interest in this, do you want to take a stab at
getting this working correctly for multi-tty? 

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

[csant]

On Fri, 18 May 2007 23:41:50 +0200, csant <csant@csant.info> wrote:

> Not sure that's right: the mouse will pass some events to the client

Actually, my bad - sorry.

If I run without your patch, and only load xterm-mouse-mode it works fine  
in both the server and the client;  but loading also vcursor will break  
both vcursor (which will print garbage instead of moving the point, both  
in the server and the client) and xterm-mouse-mode (which will not do  
anything anymore in the client, but work fine in the server).  With your  
patch, vcursor works just fine, but xterm-mouse-mode produces garbage in  
the client (but not in the server).

/c

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

[Robert J. Chassell]

    <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 is with 

this morning's multi-tyy GNU Emacs CVS snapshot, Fri, 2007 May 18  10:03 UTC
GNU Emacs 23.0.51.11 (i686-pc-linux-gnu, GTK+ Version 2.8.20, multi-tty)
in Debian testing, kernel 2.4.25, Enlightenment window manager

started in an RXVT shell with

/usr/local/src/emacs-multi-tty/src/emacs -nw  -q -l ~bob/.emacs-21-load-path-for-multi -l ~bob/.emacs-21 --eval='(tool-bar-mode 0)' --eval='(server-start)' -bg DodgerBlue4 -fg white -f w3m file:///home/u/net/quick.html -fn '-Misc-Fixed-Medium-R-Normal--18-120-100-100-C-90-ISO8859-1' -geometry 80x36+170+25 -name 'Multi TTY Emacs' --visit ~bob/how-to-emacs-multi-tty --visit /usr/local/src/discovery-global-warming --visit ~bob/.enlightenment/user_apps.menu --visit ~bob/how-to-emacs --visit ~bob/how-to-mail-on-berkshire.net --visit ~bob/.emacs-21 --visit /usr/local/src/emacs-multi-tty/lib-src/ --visit /usr/local/src/emacs-multi-tty/lisp/

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

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

[Dan Nicolaescu]

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

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

[Dan Nicolaescu]

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

  > "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. 
                        ^^^^^^^^^^
                        unexpected

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

[Stefan Monnier]

> 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

An important detail of this second point is that it sets it up on
function-key-map, which in the multi-tty branch is now made
terminal-local, IIUC.

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

Actually, I don't think that would be right either: when calling
xterm-mouse-mode, the user implicitly tells Emacs "trust me, this is
a terminal that understands the xterm-mouse protocol".  If you turn it into
a global (i.e. all terminal) mode, then it can break if some of the
terminals don't understand the xterm-mouse protocol.  I think
xterm-mouse-mode should not be global any more but terminal-local, so the
user would need to set it up for each and every terminal where she wants to
use it.
E.g., it should be possible to use xterm-mouse-mode and t-mouse-mode at
the same time.


        Stefan

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

[csant]

Stefan Monnier wrote:

> I think xterm-mouse-mode should not be global any more but
> terminal-local, so the user would need to set it up for each
> and every terminal where she wants to use it.

Meaning that when setting it in ~/.emacs you'll only enable it
for the main emacs instance?  Or should the emacsclient read
~/.emacs as well?

/c

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

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Actually, I don't think that would be right either: when calling
> xterm-mouse-mode, the user implicitly tells Emacs "trust me, this is
> a terminal that understands the xterm-mouse protocol".

Hm.  Could we have something that says "try this with every (including
as to yet unopened) terminal that you know/can test to understand the
protocol"?

It would likely be more understandable to the user but I don't know if
it is feasible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Stefan Monnier]

>> Actually, I don't think that would be right either: when calling
>> xterm-mouse-mode, the user implicitly tells Emacs "trust me, this is
>> a terminal that understands the xterm-mouse protocol".

> Hm.  Could we have something that says "try this with every (including
> as to yet unopened) terminal that you know/can test to understand the
> protocol"?

We can probably try to have a "global-xterm-mouse-mode" which automatically
sets up xterm-mouse-mode on every terminal whose TERM names matches
a particular regexp.

Same thing for t-mouse-mode. 

And/or maybe we could check the TTY name itself (after all a /dev/ttyN is
known not to be an xterm).


        Stefan

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

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Actually, I don't think that would be right either: when calling
>>> xterm-mouse-mode, the user implicitly tells Emacs "trust me, this is
>>> a terminal that understands the xterm-mouse protocol".
>
>> Hm.  Could we have something that says "try this with every (including
>> as to yet unopened) terminal that you know/can test to understand the
>> protocol"?
>
> We can probably try to have a "global-xterm-mouse-mode" which automatically
> sets up xterm-mouse-mode on every terminal whose TERM names matches
> a particular regexp.
>
> Same thing for t-mouse-mode. 
>
> And/or maybe we could check the TTY name itself (after all a /dev/ttyN is
> known not to be an xterm).

I am again at a loss concerning the client/session/terminal-local
distinction: implementing clients as having their own terminal-local
variable set seemed like a reasonable option (well, at least it is
feasible that when several clients are running in the same text tty
that their minibuffers/prefix keys reasonably can be considered
independent since only one of those clients at any time will not be
suspended).

But enabling something like xterm-mouse-mode is very likely intended
to work across a given tty.  On the other hand, if one connects from
multiple different ttys, there might be ttys that don't work using it.

Again, I think it would be best if such a mode, if global, would upon
opening any tty have the opportunity to check whether it wants to
impose on that tty (figuring out in some manner whether this tty can
actually support it), then record its state in a terminal-local
variable.

However, this implies several things:
a) Lisp code can declare terminal-local variables
b) Lisp code can fire upon terminal changes or iterate through terminals

Concretely, this would mean something like
(add-hook 'terminal-hook 'xxx)

And whenever the terminal is changed, all functions in the hook get
called unless they are also registered in a terminal-local
terminal-hook-fired variable.

In that manner, xterm-mouse-mode would work more or less globally.  If
we can't invent an automated procedure for checking whether a terminal
supports xterm-mouse-mode, then xterm-mouse-mode would only be allowed
to register terminal-locally.

Either strategy would appear to require terminal-local behavior.  This
requires either a way for Lisp code to declare terminal-local
variables, or access to the current terminal so that association lists
between terminal and variable values can be built.

I don't like either exposure of terminal-locality to Lisp, but I think
I'd prefer among the two the possibility for the Lisp declaration of
terminal-local variables, since that exposes less of the
implementation.

-- 
David Kastrup

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

[Stefan Monnier]

> But enabling something like xterm-mouse-mode is very likely intended
> to work across a given tty.  On the other hand, if one connects from
> multiple different ttys, there might be ttys that don't work using it.

> Again, I think it would be best if such a mode, if global, would upon
> opening any tty have the opportunity to check whether it wants to
> impose on that tty (figuring out in some manner whether this tty can
> actually support it), then record its state in a terminal-local
> variable.

Instead of having global-xterm-mouse-mode and xterm-mouse-mode, we may
prefer to name them respectively xterm-mouse-mode and
internal-xterm-mouse-mode (or terminal-xterm-mouse-mode).  I don't care
either way.  But we need both if we want the code to be clean.

> However, this implies several things:
> a) Lisp code can declare terminal-local variables

I'd rather have terminal objects that come with plists, just as we have for
processes, symbols, overlays, frames, ...
So instead of using hacks like terminal-local variables, we use clean
accessor functions that look at
(plisp-get <symbol> (terminal-plist (frame-terminal (selected-frame)))).

> b) Lisp code can fire upon terminal changes or iterate through terminals

I think this "or" is wrong.  Just iterating is not enough: a hook
is necessary.  W.r.t. the hook, maybe term-setup-hook is all we need.
But I also think we need to be able to iterate through the terminals.
I currently occasionally need to do that already with the X11 displays and
I hack it up by looping through all frames collecting the different
`display' properties.


        Stefan

Re: [multi-tty] Odd regression in vcursor mode in terminal

[Karoly Lorentey]

csant wrote:
> Taking the freedom to report bugs specific to the multi-tty branch
> directly to the emacs-devel list  -  I noticed an odd regression with
> vcursor in the multi-tty branch .  I have managed to boil it down to
> this snippet from my ~/.emacs :
> 
>     (setq vcursor-key-bindings 't)
>     (load "vcursor")
>     (xterm-mouse-mode 1)
> 
> When loading this in ~/.emacs on a startup with
>     $ ./src/emacs -nw
> of a fresh compile of a checkout of the multi-tty branch, C-S-up
> produces the character `A' instead of vcursor-previous-line . However,
> when starting
>     $ ./src/emacs -Q -nw
> and then finding that file and doing a `M-x eval-last-sexp' on each of
> the three items above, everything works as expected .  Also running in X
> gives no problems .

This doesn't seem related to vcursor at all.  The simplest way to reproduce this
that I could find is just having the following in .emacs:

	(load-library "xt-mouse")

The bug is caused by some problem related to `local-function-key-map' during
terminal initialization.  .emacs is loaded *before* term/xterm.el sets up the
local-function-key-map on the terminal, and apparently changing
`function-key-map' before that breaks function keys.

I think this may be related to keymap inheritance.  On the multi-tty branch,
`function-key-map' is the common parent of all terminal-local keymaps
(`local-function-key-map').  To speed up terminal initialization, term/xterm.el
prepares a third keymap with the terminal-dependent function keys (such as
`xterm-function-map'), and set a copy of that as the intermediate parent of
`local-function-key-map'.  The result is as follows:

	function-key-map
	^
	|
	anonymous copy of xterm-function-map
	^
	|
	local-function-key-map

Xterm-mouse-mode simply adds a new define-key in function-key-map.  Apparently
this doesn't work right when it does this before the above chain is created.
`local-function-key-map' is different depending on whether xt-mouse is loaded
before or after terminal initialization.  This shouldn't happen.

Unfortunately, I don't have time to debug this now.  I'll return to this later,
unless somebody else fixes it in the meantime.  (It is very much possible that I
simply misunderstood how keymap inheritance works when I wrote the above code.)

-- 
Karoly

Re: [multi-tty] Odd regression in vcursor mode in terminal

[Karoly Lorentey]

csant wrote:
> Taking the freedom to report bugs specific to the multi-tty branch
> directly to the emacs-devel list  -  I noticed an odd regression with
> vcursor in the multi-tty branch .  I have managed to boil it down to
> this snippet from my ~/.emacs :
> 
>     (setq vcursor-key-bindings 't)
>     (load "vcursor")
>     (xterm-mouse-mode 1)
> 
> When loading this in ~/.emacs on a startup with
>     $ ./src/emacs -nw
> of a fresh compile of a checkout of the multi-tty branch, C-S-up
> produces the character `A' instead of vcursor-previous-line . However,
> when starting
>     $ ./src/emacs -Q -nw
> and then finding that file and doing a `M-x eval-last-sexp' on each of
> the three items above, everything works as expected .  Also running in X
> gives no problems .

This doesn't seem related to vcursor at all.  The simplest way to reproduce this
that I could find is just having the following in .emacs:

	(load-library "xt-mouse")

The bug is caused by some problem related to `local-function-key-map' during
terminal initialization.  .emacs is loaded *before* term/xterm.el sets up the
local-function-key-map on the terminal, and apparently changing
`function-key-map' before that breaks function keys.

I think this may be related to keymap inheritance.  On the multi-tty branch,
`function-key-map' is the common parent of all terminal-local keymaps
(`local-function-key-map').  To speed up terminal initialization, term/xterm.el
prepares a third keymap with the terminal-dependent function keys (such as
`xterm-function-map'), and set a copy of that as the intermediate parent of
`local-function-key-map'.  The result is as follows:

	function-key-map
	^
	|
	anonymous copy of xterm-function-map
	^
	|
	local-function-key-map

Xterm-mouse-mode simply adds a new define-key in function-key-map.  Apparently
this doesn't work right when it does this before the above chain is created.
`local-function-key-map' is different depending on whether xt-mouse is loaded
before or after terminal initialization.  This shouldn't happen.

Unfortunately, I don't have time to debug this now.  I'll return to this later,
unless somebody else fixes it in the meantime.  (It is very much possible that I
simply misunderstood how keymap inheritance works when I wrote the above code.)

-- 
Karoly