[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pretest next week
From: |
Adrian Robert |
Subject: |
Re: Pretest next week |
Date: |
Thu, 5 Mar 2009 19:15:17 +0200 |
YAMAMOTO Mitsuharu <address@hidden> writes:
> 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. There is still a delay when requesting a menu, but
this is
probably unavoidable if the visited modtime must be checked for each
menu
item.
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.