Asynchronous events in Carbon or Cocoa Emacs (macosx)

[Lloyd Zusman]

I'm not sure whether the following question is appropriate in this forum.
I've posted it in a few other emacs-related mailing lists and newsgroups,
but no one has responded. I figure that you developers might understand
this issue best, and you might be able to quickly answer my question.
Please forgive me if I have misjudged and should have not posted this here.

Under macosx (Leopard), I can run the latest builds of Carbon Emacs 
(22.3.1) or Cocoa Emacs (23.0.60) inside of a Terminal window by invoking
the following command lines from within Terminal:

    /path/to/Contents/MacOS/Emacs -nw FILE

... where FILE is the item that I want to edit.

If I run it in this way, events handled via Emacs' `special-event-map'
are invoked asynchronously and in real time ... or at least in near-real
time (they're processed the next time that Emacs becomes idle). For example,
if I define a [sigusr1] event, its `special-event-map' handler gets invoked
the next moment that Emacs goes idle after I send a USR1 signal to its
process. This is the behavior that I am expecting.

However, if I run Carbon or Cocoa Emacs without the `-nw' flag so that it 
creates and manages its own window outside of Terminal, these
`special-event-map' events don't get invoked in near-real time any more, but
rather, they only get processed the next time I interact directly with the
Emacs window with either the mouse or a keystroke.

In other words, if I am trapping [sigusr1] as described above and send a
USR1 signal to the process, nothing happens until after I click in the Emacs 
window with the mouse or perform some sort of keyboard interaction with it,
at which time the [sigusr1] events that have accumulated all get processed,
one after the other.

It's as if the windowed version of Carbon and Cocoa Emacs can only process
`special-event-map' events in synchronization with the keyboard and mouse
input queues. Or perhaps the explanation is that these versions of Emacs
don't consider themselves to be in an idle state except immediately after
they've finished processing keyboard and mouse events. Or maybe there's
a different explanation for this; I'm not an Emacs developer, so I'm only 
guessing.

Has anyone else seen this behavior? If so, is there any way that you know
of to tell the windowed version of Carbon/Cocoa Emacs to process [sigusr1]
and other `special-event-map' events asynchronously from the keyboard and
mouse, in the same way that they get processed when Emacs is started in
a Terminal window with the `-nw' option?

Thanks in advance.

-- 
 Lloyd Zusman
 address@hidden
 God bless you.