From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: alarm_signal_handler is called too frequently Date: Mon, 01 Nov 2004 10:06:13 +0100 Message-ID: <4185FC85.70100@swipnet.se> References: <7E7ABFB6-2693-11D9-9BC4-000D93505B76@swipnet.se> <41813425.2010001@swipnet.se> <4181EA7E.2020309@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1099300314 29216 80.91.229.6 (1 Nov 2004 09:11:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 1 Nov 2004 09:11:54 +0000 (UTC) Cc: mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 01 10:11:45 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1COYE5-0006UT-00 for ; Mon, 01 Nov 2004 10:11:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1COYM4-0004Wt-RI for ged-emacs-devel@m.gmane.org; Mon, 01 Nov 2004 04:20:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1COYHx-0002uy-5r for emacs-devel@gnu.org; Mon, 01 Nov 2004 04:15:45 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1COYHt-0002sy-TY for emacs-devel@gnu.org; Mon, 01 Nov 2004 04:15:42 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1COYHr-0002rd-G3 for emacs-devel@gnu.org; Mon, 01 Nov 2004 04:15:40 -0500 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1COY9M-0005O9-D4; Mon, 01 Nov 2004 04:06:52 -0500 Original-Received: from coolsville.localdomain ([83.226.180.220] [83.226.180.220]) by mxfep01.bredband.com with ESMTP id <20041101090651.HAVA4883.mxfep01.bredband.com@coolsville.localdomain>; Mon, 1 Nov 2004 10:06:51 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040916 X-Accept-Language: en-us, en Original-To: rms@gnu.org In-Reply-To: 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: main.gmane.org gmane.emacs.devel:29264 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29264 Richard Stallman wrote: > Sorry, I misunderstood. The timer_check is not run from popup_get_selection > for popup menus because the argument do_timers is 0: > > if (do_timers && !XtAppPending (Xt_app_con)) > timer_check (1); > > But for dialogs, do_timer is 1, so timers do get checked when a dialog is > popped up. > > Can anyone figure out why these two cases uses different values for > do_timer? They also use different values for down_on_keypress. > cthose arguments are clearly there so that the two callers could treat > these differently. There must have been a reason. I can't say why the do_timer argument is different, the modification was made by you almost 2 years ago: 2002-12-21 Richard M. Stallman * xmenu.c (popup_get_selection): Now static. New arg DO_TIMERS. If it is non-nil, run timers. Use an unwind-protect to requeue the events that were read ahead. (popup_get_selection_unwind): New subroutine. (popup_get_selection_queue): File-scope variable now holds that queue. (xmenu_show): Pass 0 for DO_TIMERS to popup_get_selection. (xdialog_show): Pass 1 for DO_TIMERS to popup_get_selection. Use an unwind-protect to pop down the dialog box. (xdialog_show_unwind): New subroutine implements that. I can speculate that since popup menus does a grab and dialog does not, there might have been some difference in event handling. The reason for the difference in down_on_keypress is that when a popup menu is up, the keyboard is grabbed, so no keypresses goes to the Emacs frame anyway. But for a dialog there might be events that goes to the Emacs frame (for example if you have focus-follows-mouse and the focus is not on the dialog, but on the frame). For such events the dialog is popped down (as per the old behaviour from previous Emacs versions). > > I guess we just have to get rid of the call to timer_check in > popup_get_selection. > > I guess we do. Will this mean that the cursor doesn't blink? > If so, it would be good to make sure that the cursor is ON > rather than off. Yes, it means that the cursor does not blink for popup menus or dialogs. This is the same as for Emacs 21.2 (the oldest I have here). The difference is that in CVS Emacs the cursor turns hollow when a dialog or menu is popped up, previously it stayed solid. Jan D.