Re: Pretest next week

[Adrian Robert <adrian.b.robert@gmail.com>]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> 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.