From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: finger-pointer curser as default for mouse-face text Date: Mon, 25 Oct 2004 14:51:28 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098708846 7277 80.91.229.6 (25 Oct 2004 12:54:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Oct 2004 12:54:06 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, drew.adams@oracle.com, "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 25 14:53:52 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CM4MB-0001ST-00 for ; Mon, 25 Oct 2004 14:53:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CM4Tp-0004uz-Pm for ged-emacs-devel@m.gmane.org; Mon, 25 Oct 2004 09:01:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CM4SJ-0004FC-SI for emacs-devel@gnu.org; Mon, 25 Oct 2004 09:00:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CM4SG-0004Dx-Mb for emacs-devel@gnu.org; Mon, 25 Oct 2004 09:00:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CM4SG-0004Dh-9y for emacs-devel@gnu.org; Mon, 25 Oct 2004 09:00:08 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CM4K1-0005sg-PC for emacs-devel@gnu.org; Mon, 25 Oct 2004 08:51:37 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1CM4JW-0004NA-BY; Mon, 25 Oct 2004 08:51:06 -0400 Original-To: Stefan In-Reply-To: (Stefan's message of "Mon, 25 Oct 2004 07:47:44 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28902 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28902 Stefan writes: >>> What is the behavior of latex-preview in the case of mouse-1 and in >>> the case of mouse-2? Is mouse-face applied to the actual text or >>> just to the (before|after)-string? > >> The behavior of preview-latex when clicking with mouse-1 on a preview >> image is to simply set point on the image (i.e., the behavior is just >> the default, and preview-latex does not tamper with it). You will >> often need to do this to cut and paste the text passage that is hidden >> by the image, for example, it you are doing a mathematical derivation >> and start with the source text of the last equation in order to derive >> the next one. When clicking with mouse-2 on the image, the image is >> replaced by the underlying text. The image has a mouse-face that is >> visible indication that you can mouse-2 the image. > > So it's the image (which is placed on a before-string) No insinuations, please. If the image were placed on a before-string, you could not move point to it in the first place. The image is placed in the display property of the text (actually, the display property of an overlay, and this overlay has the mouse-face). > which has the `mouse-face', not the buffer's text, right? Wrong. > So Kim's patch won't interfere since Kim's patch checks > (get-char-property (point) 'mouse-face) which should return nil in > your case. Shouldn't. > Have you tried his patch or were you just "running it in your head" > (like I usually do myself)? It does not actually matter since I merely cited preview-latex as one case that would appear not to fit the assumptions behind Kim's patch. Whether or not an inconsistency in behavior might perchance render the patch inoperative in this case by shere luck does not change the basic premise: we need a proper migration strategy to do something like that. preview-latex itself is not much of a problem: it is under my control and I can make it cope if it is the only application in the world that gets in trouble with such a change. But I have no reason to believe that. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum