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: Sat, 21 Dec 2002 21:02:54 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20021222020254.GA3681@gnu.org> References: <20021220220656.GA3527@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1040522644 11132 80.91.224.249 (22 Dec 2002 02:04:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 22 Dec 2002 02:04:04 +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 18PvT2-0002sM-00 for ; Sun, 22 Dec 2002 03:03:48 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18PvVL-00048W-00 for ; Sun, 22 Dec 2002 03:06:11 +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 18PvSW-0004di-05 for emacs-devel@quimby.gnus.org; Sat, 21 Dec 2002 21:03:16 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18PvSJ-0004dc-00 for emacs-devel@gnu.org; Sat, 21 Dec 2002 21:03:03 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18PvSH-0004dR-00 for emacs-devel@gnu.org; Sat, 21 Dec 2002 21:03:02 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18PvSH-0004dL-00 for emacs-devel@gnu.org; Sat, 21 Dec 2002 21:03:01 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.10) id 18PvSA-00015T-00; Sat, 21 Dec 2002 21:02:54 -0500 Original-To: Richard Stallman Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Blat: Foop 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:10317 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10317 On Sat, Dec 21, 2002 at 03:26:32PM -0500, Richard Stallman wrote: > In fact I find it confusing (as a user) that it updates mouse-faces > almost always, but most things only when it's `ready'. > > Emacs won't let you *change* text in the buffer until it is `ready', > and of course they don't update until they change. By contrast, the > locus of mouse highlighting does change, whenever you move the mouse. I'm sure there's a way you can think of it so that it `makes sense' (and of course I understand technically why it happens the way it does). None-the-less, I really do find it confusing in practice because seeing the buffer contents apparently change makes it _feel_ like emacs is ready do so something (even though it's not), and I'm subsequently surprised when I try to do something else and can't. Consider another apparently similar case: In X (unlike some other window systems), you can move, resize, and iconify windows even when the underlying applications aren't ready to respond (and so can't redraw). In contrast with emacs mouse-faces, this _feels_ right to me. I guess the only way I can explain the difference is that in X the window frame title bar visually appear to be a `wrapper,' and I can easily think of them as being a completely separate layer and thus follow different rules of interaction. In emacs, mouse highlighting is visually part of the buffer contents, and so it's harder to think it as being somehow separate. [However, I think it _would_ seem natural if one could move emacs-window boundaries without being to actually interact with the buffer, because they're visually distinct layers] Anyway, those are my thoughts. -Miles -- `The suburb is an obsolete and contradictory form of human settlement'