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: Fri, 22 Oct 2004 17:56:09 +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 1098460990 21695 80.91.229.6 (22 Oct 2004 16:03:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 22 Oct 2004 16:03:10 +0000 (UTC) Cc: emacs-devel@gnu.org, Stefan Monnier , Drew Adams , Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 22 18:03:01 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 1CL1sZ-0005ht-00 for ; Fri, 22 Oct 2004 18:02:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CL204-0002ck-Lx for ged-emacs-devel@m.gmane.org; Fri, 22 Oct 2004 12:10:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CL1uG-0000DC-T9 for emacs-devel@gnu.org; Fri, 22 Oct 2004 12:04:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CL1uF-0000CU-Tx for emacs-devel@gnu.org; Fri, 22 Oct 2004 12:04:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CL1uF-0000CJ-PG for emacs-devel@gnu.org; Fri, 22 Oct 2004 12:04:43 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CL1mN-0007PN-M4 for emacs-devel@gnu.org; Fri, 22 Oct 2004 11:56:35 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1CL1lu-0006zG-El; Fri, 22 Oct 2004 11:56:07 -0400 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Fri, 22 Oct 2004 17:03:51 +0200") 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:28730 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28730 storm@cua.dk (Kim F. Storm) writes: > David Kastrup writes: > >>> Why do preview-latex images need to have mouse-face property ? >>> Images can have mouse-2 bindings even without that. >> >> But the mouse-face property is the normal way to indicate that using >> mouse-2 will do something different from pasting. > > What visible effect do you get for an image when moving the mouse > over it? Transparent areas of the image turn green (or whatever your highlight color is). preview-latex explicitly places a transparent border around images to achieve that effect. Even if the image is not transparent, some part of the line spacing usually turns green. > You can also change the mouse pointer shape. But that's not the "traditional way" since it was not available for as long. And it's beside the point, anyway, since it does not provide any better idea about when to interchange mouse-1 and mouse-2. >> So what? preview-latex images don't have a non-standard binding >> for mouse-1. So I am citing it as an example that will cause >> trouble and requires a migration plan instead of a sudden change. > > It was one way to avoid the mouse-1 remapping (by trivial code > rewrite). > > I have little hope of finding a perfect solution (i.e. one which > works for everything without anything having to adapt to some kind > of method to fine-tune the behaviour in specific cases). Maybe it's > ok if it works in 95% of all cases (and the remaning 5% must be > tweaked a little to work). Sure. That's why I say we need a migration plan. Providing an option, and then at some time making that option a default is not a migration plan. We need to define what an application needs to do in order to get consistent behavior both with and without that option, and we need to get the message out. And then, at one time, people can hope to turn this option on and off according to their preferences without expecting to get something completely inconsistent. And when we arrive at that stage, it might make sense switching the default of the option. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum