From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] mouse-1 click follows link Date: Sat, 30 Oct 2004 19:09:13 -0500 (CDT) Message-ID: <200410310009.i9V09DM03843@raven.dms.auburn.edu> References: <200410292354.i9TNsCq01994@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1099181443 17979 80.91.229.6 (31 Oct 2004 00:10:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 31 Oct 2004 00:10:43 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 31 02:10:31 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 1CO3Ik-0006ts-00 for ; Sun, 31 Oct 2004 02:10:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CO3Qf-00079k-VW for ged-emacs-devel@m.gmane.org; Sat, 30 Oct 2004 20:18:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CO3QR-00075J-AH for emacs-devel@gnu.org; Sat, 30 Oct 2004 20:18:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CO3QQ-00074q-FB for emacs-devel@gnu.org; Sat, 30 Oct 2004 20:18:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CO3QQ-00074a-AH for emacs-devel@gnu.org; Sat, 30 Oct 2004 20:18:26 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CO3I3-0001dQ-Sk for emacs-devel@gnu.org; Sat, 30 Oct 2004 20:09:48 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i9V09NFu000498; Sat, 30 Oct 2004 19:09:23 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id i9V09DM03843; Sat, 30 Oct 2004 19:09:13 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: storm@cua.dk In-reply-to: (storm@cua.dk) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29200 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29200 Kim Storm wrote: > Hopefully I am misunderstanding this, as it would obviously be > disastrous, even for an optional feature. Can you elaborate on this? Yes. You blindly rebind mouse-1 to mouse-2 without having the _slightest_ idea what mouse-2 is bound to. This is reckless and obviously unacceptable. It represents a danger to the unsuspecting user, who will only expect the rebinding for true links. You expect package authors to adapt to your change, but it is completely unrealistic to expect all of them to do that. Most package authors do not read Emacs devel. Also, even if by some miracle all package authors would do that, then this would _still_ not solve the problem. The user may upgrade to a new Emacs version without upgrading all outside packages he uses. So far we have identified two examples of this in external packages (preview-latex and AUCtex) -- it would be trivial for those to add the dont-follow-link property. It is not only non-trivial but impossible to check all external packages. I could be wrong, but I have the impression that you did not even check all uses of the mouse-face property that are included with the Emacs distribution. I think it is better to mark the exceptions, rather than the rule. I am not sure that they are the exception, if you count uses of the mouse-face property in the source code, rather than occurrences in actual Emacs buffers. But anyway, this is irrelevant, because it quite simply would be irresponsible to blindly execute some random command, regardless of whether such a blind execution occurs in 90 percent or .01 percent of the cases. The danger is too big. On the other hand, if the behavior only occurs when the text has the link property, then it only occurs for things somebody has explicitly checked. The only thing that can happen for overlooked "true" links is that mouse-1 sets point instead of following the link. No real harm happened and the user can file a bug report. Eventually all real links will be accounted for. Even though only implementing the behavior for text that has been explicitly given the link property would be a lot better than the concrete patch you proposed, I still do not believe that it would be ideal. Unlike your concrete patch, I believe that it would be acceptable, but I believe that there _must_ be simpler and better ways to get the same effect. Sincerely, Luc.