From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: signal handling bogosities Date: Fri, 20 Dec 2002 12:12:24 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1040404964 14517 80.91.224.249 (20 Dec 2002 17:22:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2002 17:22:44 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18PQrC-0003m1-00 for ; Fri, 20 Dec 2002 18:22:42 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18PQsu-0001bj-00 for ; Fri, 20 Dec 2002 18:24:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18PQrD-0001NL-00 for emacs-devel@quimby.gnus.org; Fri, 20 Dec 2002 12:22:43 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18PQjV-0006L0-00 for emacs-devel@gnu.org; Fri, 20 Dec 2002 12:14:45 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18PQip-0005mE-00 for emacs-devel@gnu.org; Fri, 20 Dec 2002 12:14:05 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18PQhF-0004qj-00 for emacs-devel@gnu.org; Fri, 20 Dec 2002 12:12:25 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 18PQhE-0005AW-00; Fri, 20 Dec 2002 12:12:24 -0500 Original-To: miles@gnu.org In-reply-to: (message from Miles Bader on 19 Dec 2002 19:15:46 +0900) Original-cc: gerd@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:10309 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10309 That signal results in `note_mouse_movement', and then `note_mouse_highlight' being called: #11 0x080b2345 in note_mouse_highlight (f=0x850aa18, x=184, y=260) at /usr/local/src/emacs/src/xterm.c:7407 #12 0x080b162e in note_mouse_movement (frame=0x850aa18, event=0xbffd1064) at /usr/local/src/emacs/src/xterm.c:6893 #13 0x080b5f05 in handle_one_xevent (dpyinfo=0x84f5490, eventp=0xbffd13ac, bufp_r=0xbffd1418, numcharsp=0xbffd141c, finish=0xbffd13a8) at /usr/local/src/emacs/src/xterm.c:11291 note_mouse_highlight then tries to figure out the proper mouse-face-id, which calls face realization, and if realize-face-filter-functions has a non-nil value, calls the lisp interpreter, and thus dies as seen. I am surprised that the signal handler does face realization. I would have expected redisplay ought to do that job. When the signal handler runs, it should just look up the data that was computed by redisplay. In the past, face realization did not evaluate any Lisp code, so calling it from the signal handler was not a bug. It may have been bad design though. display the mouse face, and in other branches of the code the whole redisplay engine seems to be invoked, for exposure events (I don't know whether that can result in lisp code being called, but it seems as if it could -- given the complexity of redisplay, it's kind of hard to tell). That seems bizarre too. Can you please show me what you have learned about this? How hard would be to restructure things to just queue this stuff for an event-loop outside the signal handler to handle? That design has a serious drawback: the screen won't refresh while Emacs is running. The design idea used to be that the signal handler would update the screen in a simple way based on tables that were computed in advance by redisplay. This avoided the problem we have now, and would redisplay immediately even when Emacs is running. Can we make it work this way again? Gerd wrote: Specifically for mouse-highlighting there may be a cheaper solution, though. IIRC, I once talked with Stefan Monnier about generating mouse-highlight input events for mouse highlights instead of doing the display directly when handling the mouse movement event (analogous to help-echo, for example). If we handle mouse highlighting by generating input events to do the work at main program level, then the highlighting won't change when you move the mouse while Emacs is running a Lisp program. Is that acceptable? It is not as bad as failing to refresh the screen at all while a Lisp program is running, but it is still somewhat undesirable.