From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David.Kastrup@t-online.de (David Kastrup) Newsgroups: gmane.emacs.devel Subject: Re: No possibility of determining image position/object from click Date: 15 Jun 2002 19:10:10 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200206091519.g59FJFk00269@aztec.santafe.edu> <200206151413.g5FEDpp10322@aztec.santafe.edu> <1659-Sat15Jun2002195833+0300-eliz@is.elta.co.il> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1024161139 31251 127.0.0.1 (15 Jun 2002 17:12:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 15 Jun 2002 17:12:19 +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.33 #1 (Debian)) id 17JH63-00087w-00 for ; Sat, 15 Jun 2002 19:12:19 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17JHVO-0007uc-00 for ; Sat, 15 Jun 2002 19:38:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17JH5t-0000Ru-00; Sat, 15 Jun 2002 13:12:09 -0400 Original-Received: from mailout08.sul.t-online.com ([194.25.134.20]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17JH5P-0000QV-00 for ; Sat, 15 Jun 2002 13:11:39 -0400 Original-Received: from fwd10.sul.t-online.de by mailout08.sul.t-online.com with smtp id 17JH5N-0003Mo-03; Sat, 15 Jun 2002 19:11:37 +0200 Original-Received: from tupik.goethe.zz (520018396234-0001@[62.226.11.189]) by fwd10.sul.t-online.com with esmtp id 17JH5B-0HJWvwC; Sat, 15 Jun 2002 19:11:25 +0200 Original-Received: (from dak@localhost) by tupik.goethe.zz (8.11.6/linuxconf) id g5FHABM02408; Sat, 15 Jun 2002 19:10:11 +0200 Original-To: Eli Zaretskii In-Reply-To: <1659-Sat15Jun2002195833+0300-eliz@is.elta.co.il> Original-Lines: 43 X-Sender: 520018396234-0001@t-dialin.net Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4890 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4890 "Eli Zaretskii" writes: > > From: David.Kastrup@t-online.de > > Date: 15 Jun 2002 16:34:25 +0200 > > > > > > Emacs does not update the > > screen while it is busy, which can easily last for a few seconds. If > > I click onto the screen during that time, buffer positions and > > keymaps will be calculated corresponding to what the screen will look > > like after the next screen update finally gets done. > > How is this different from the situation where a user types C-w in > the middle of a lengthy calculation which will eventually change the > text inside the region (and thus the result of C-w). > > In other words, typing ahead when Emacs is busy always runs a risk of > doing the wrong thing. Am I missing something? When clicking on something, we establish a visual correlation between the object we are clicking on and the mouse pointer, not between the naked screen position and the mouse pointer. That is, when we are queing keyboard events, we are conceptually queuing "process C-x C-w" "process C-d" ... With mouse clicks, we are conceptually queuing "click on object/buffer position ...", not "click on screen pixel coordinates ...". The perceived discrepancy in processing is quite disconcerting. During such busy calculations, for example tooltips are still being processed, and they are processed taking into account the look of the buffer _before_ redisplay (which is the only thing that makes sense to the user, anyhow), at least that is my impression. The tooltip in my case then promises something like "[button-2] toggles preview", but if you press the button, and this gets queued, and then some other stuff gets updated in a process sentinel or wherever else before the event gets processed, something quite different from what the tooltip promised will happen. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: David.Kastrup@t-online.de