Re: GPM mouse tracking issues solved, kindof

I didn't receive it twice, but I don't care about receiving things twice in any case. But you shouldn't be doing what you're doing. The event-stream code has many places that assume that only specific types of events (i.e. not mouse motion events) are on the command-event queue. We could modify such code to allow for this possibility, but it seems as though you might run into the "excessive numbers of motion events" problem -- i.e. if XEmacs is very slow and behind in processing events, the queue could fill up with large numbers of GPM motion events. With X or MSWIN, this won't happen because XEmacs won't ask for an event until it's ready for one, and X and MSWIN won't generate mouse events until they're requested. So I think the cleanest way would be to do exactly what Jan proposes -- don't try to stuff your events at all; instead, create your own queue for motion, button, and all other GPM events, and put wrapper functions around the next-event and event-pending-p callbacks. When you do this, however, make sure you grep through the code for all places that might change these callbacks -- I have a vague feeling that in some cases (e.g. some debug-enabled code?), the callbacks might get changed in the middle of a running XEmacs. ben "William M. Perry" wrote: