I do not have enough programming experience to debug and fix the
problem myself.
I am afraid the only way to solve this is running XEmacs (and libgpm) under a
debugger and look at what happens. Even without much pogramming
experience that should be doable.
I assume you work with current gpm (1.14) otherwise all bets are off.
Karl, did you? Debian hamm seems to have 1.13.
If there is indeed a conflict, it is not a problem with gpm: we
really
do it extra-extra clean way, calling back the original handler if
there is any. A conflict is possible (likely) however if the app
opens the gpm connection first and _then_ installs its own SIGTSTP
handler, overwriting ours. If that is the problem, merely changing
the order of initialisations should help.
As far as grep can see XEmacs does not install its own SIGTSTP handler
at all. Basically, all it does is send SIGTSTP to its whole program
group if M-x suspend-emacs is called.
unless you can/want to modify Emacs internals, _and_ can find the
one
very special place in in the Emacs code where to call GPM_DRAWPOINTER
from, the redisplay will clobber the pointer again.
That will be at the end of the redisplay code, that should not be too
difficult.
find that one special place, so I had the pointer visible through
drags. I am almost sure that piece of code is different for XEmacs.
I don't think it is that different.
That said, I once added gpm support to GNU Emacs the dirty way (the
way XEmacs seems to do it now, judging by your info)
I find the current way gpm is implemented (114 lines of C code,
including comments and whitespace) in XEmacs very clean. It does not
involve running another subprocess from lisp nor does it involve
manufacturing events from lisp code. The latter is only possible as of
21.0 anyway and is very tricky to get right.
Jan