emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pretest next week


From: YAMAMOTO Mitsuharu
Subject: Re: Pretest next week
Date: Fri, 06 Mar 2009 10:01:38 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Thu, 5 Mar 2009 19:15:17 +0200, Adrian Robert <address@hidden> said:

>> In the reported case, read_socket_hook is called from the select
>> (ns_select, actually) call in wait_reading_process_output, and a
>> menu bar activation there leads to Lisp evaluation containing
>> Faccept_process_output.

> It appears that a call verify-visited-file-modtime happens for each
> active menu item, which then triggers tramp to go and check on the
> server.  This causes a reentrant call to
> wait_reading_process_output, thence a reentrant call to ns_select.
> I've added a check in the latter to shortcircuit in the reentrant
> case.

I'm anxious whether the former reentrance (i.e.,
wait_reading_process_output) is safe.

> I've looked at your code in the Carbon AppKit port and it seems like
> your approach to handling menu events there could be applied to the
> NS port.  The only difference I see in your event handling is
> processing all event types in one function instead of passing them
> through NSApp-sendEvent: to go be distributed through ordinary Cocoa
> channels to widgets.  But since - sendEvent: is an interception
> point, the menu events could be taken there.

I vaguely remember that didn't work in some cases, maybe when Emacs is
used via "Screen Sharing.app" in Leopard.  Anyway you can try.

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]