From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Pretest next week Date: Fri, 06 Feb 2009 10:10:38 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <64D7164D-024E-4720-908C-94684A768A6E@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1233930257 28859 80.91.229.12 (6 Feb 2009 14:24:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Feb 2009 14:24:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 06 15:25:31 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LVRe7-0003nT-1l for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2009 15:25:31 +0100 Original-Received: from localhost ([127.0.0.1]:55472 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVRcn-0003is-Oq for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2009 09:24:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVFEx-0002n7-Dt for emacs-devel@gnu.org; Thu, 05 Feb 2009 20:10:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVFEv-0002mv-SX for emacs-devel@gnu.org; Thu, 05 Feb 2009 20:10:42 -0500 Original-Received: from [199.232.76.173] (port=55021 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVFEv-0002ml-Os for emacs-devel@gnu.org; Thu, 05 Feb 2009 20:10:41 -0500 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:58915) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LVFEu-0002Zs-Tg for emacs-devel@gnu.org; Thu, 05 Feb 2009 20:10:41 -0500 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id E92972C4F for ; Fri, 6 Feb 2009 10:10:38 +0900 (JST) In-Reply-To: <64D7164D-024E-4720-908C-94684A768A6E@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by monty-python.gnu.org: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:108812 Archived-At: >>>>> On Thu, 5 Feb 2009 19:39:42 +0200, Adrian Robert 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