[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: alarm_signal_handler is called too frequently

From: Jan D.
Subject: Re: alarm_signal_handler is called too frequently
Date: Mon, 01 Nov 2004 10:06:13 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040916

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  <address@hidden>

        * 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]