From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: signal handling bogosities Date: 20 Dec 2002 10:44:53 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20021219140425.GB28566@gnu.org> Reply-To: Miles Bader NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1040348861 26738 80.91.224.249 (20 Dec 2002 01:47:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2002 01:47:41 +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 18PCGK-0006x8-00 for ; Fri, 20 Dec 2002 02:47:40 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18PCHi-0006Ib-00 for ; Fri, 20 Dec 2002 02:49:06 +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 18PCGC-0001xG-02 for emacs-devel@quimby.gnus.org; Thu, 19 Dec 2002 20:47:32 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18PCFY-0001U6-00 for emacs-devel@gnu.org; Thu, 19 Dec 2002 20:46:52 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18PCFB-0000np-00 for emacs-devel@gnu.org; Thu, 19 Dec 2002 20:46:31 -0500 Original-Received: from tyo202.gate.nec.co.jp ([202.32.8.202]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18PCFA-0000ga-00; Thu, 19 Dec 2002 20:46:28 -0500 Original-Received: from mailgate3.nec.co.jp ([10.7.69.192])gBK1kIU26174; Fri, 20 Dec 2002 10:46:19 +0900 (JST) Original-Received: from mailsv4.nec.co.jp (mailgate52.nec.co.jp [10.7.69.191]) by mailgate3.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id gBK1kHi16319; Fri, 20 Dec 2002 10:46:17 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id gBK1isq01526; Fri, 20 Dec 2002 10:45:46 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) id gBK1irB10617; Fri, 20 Dec 2002 10:44:53 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 9CB453702; Fri, 20 Dec 2002 10:44:53 +0900 (JST) Original-To: Gerd Moellmann System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <20021219140425.GB28566@gnu.org> Original-Lines: 71 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:10296 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10296 Gerd Moellmann writes: > My feeling is that the cost of restructuring the code to use an event > loop could be pretty high, but I've never investigated this very > deeply because Richard thought the current way of doing things is > good, and an event loop is an abomination :). There were lots of > other things to do anyway, so I didn't pursue this further. > > 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). > > When that is done, normal redisplay could be used to draw the > mouse-highlight, but it would have to be extended to use mouse-face > for part of the text, which it currently doesn't. Also, the logic > determining which parts of a buffer/window are to be redisplayed would > have to be extended somehow so that the highlighted region is > displayed despite the fact that there have been no buffer changes. Perhaps I'm confused, but why can't the existing code that runs from the signal handler just be called from the event loop instead, at least as an easy first-step? For instance, if the signal handler currently looks like: void signal_handler (...) { if (some_test) do_mouse_stuff (mouse_info); else if (some_other_test) do_exposure_stuff (other info); } change it to be like: void signal_handler (...) { if (some_test) queue_mouse_event (mouse_info); else if (some_other_test) queue_exposure_event (exposure_info); } void event_loop_function (...) { while (event in event loop) { ... if (event->type == mouse_event) do_mouse_stuff (event->mouse_info) else if (event->type == exposure_event) do_exposure_stuff (event->exposure_info) ... } } In other words, re-use as much of the existing code as possible, but change the place where it's called. My (vague) reasoning is that if it currently can be called from a _signal handler_, which is possibly the worst possible case, then the code must be pretty safe to call from just about anywhere -- so why not the event loop? Thanks, -Miles -- I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff