Re: Pretest next week

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Thu, 5 Feb 2009 19:39:42 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:

>> That's actually a way I didn't adopt because it confuses the user:
>> it shows empty menu items if the user clicks the menu bar at the
>> timing of a read_socket_hook call from a QUIT macro in the context
>> of process filters or idle timers.

> In the current implementation it does this only if menus have not
> been clicked on before (else the previous items, albeit out-of-date
> ones) are shown.  This is better than nothing, though it should be
> better.

What happens if the user selects that "bogus" item?  Doesn't it
generate a bogus Emacs event that might not happen if the menu bar
activation is deferred?

> However I'm not really sure how often this "clicks the menu bar at
> the timing of a read_socket_hook call from a QUIT macro" occurs in
> practice.

The process filters and idle timers are a kind of "background tasks".
Users will expect that they can continue normal editing work (with
some delay, sometimes).  Also, some process filter takes time to
complete, and an idle timer can be designed so it can do a long task
if no input is pending.

> Anyway, what about the second-thread approach like W32, are there
> any gotchas you know about?

I guess menu bar item calculation can be deferred but not for starting
menu bar tracking in the case of NS.  For example, I'm not sure if the
following scenario can work properly:

  1. Evaluate `(while t)'.
  2. The user clicks the menu bar.  The GUI thread starts to wait for
     menu items to be calculated in the Lisp thread.  The Lisp thread
     is not ready to do that because of the tight loop.
  3. The user types C-g to quit the loop.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp