unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Asynchronous events in Carbon or Cocoa Emacs (macosx)
@ 2008-10-10 23:51 Lloyd Zusman
  2008-10-11  3:05 ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 3+ messages in thread
From: Lloyd Zusman @ 2008-10-10 23:51 UTC (permalink / raw)
  To: emacs-devel

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
 ljz@asfast.com
 God bless you.







^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-10-11  4:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-10 23:51 Asynchronous events in Carbon or Cocoa Emacs (macosx) Lloyd Zusman
2008-10-11  3:05 ` YAMAMOTO Mitsuharu
2008-10-11  4:04   ` Lloyd Zusman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).