unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] mouse-1 click follows link
Date: Sat, 30 Oct 2004 19:09:13 -0500 (CDT)	[thread overview]
Message-ID: <200410310009.i9V09DM03843@raven.dms.auburn.edu> (raw)
In-Reply-To: <m3r7nfn9rc.fsf@kfs-l.imdomain.dk> (storm@cua.dk)

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.

  reply	other threads:[~2004-10-31  0:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-29 13:04 [PATCH] mouse-1 click follows link Kim F. Storm
2004-10-29 23:54 ` Luc Teirlinck
2004-10-30 22:04   ` Kim F. Storm
2004-10-31  0:09     ` Luc Teirlinck [this message]
2004-10-31 12:49       ` Kim F. Storm
2004-11-01  7:24       ` Richard Stallman
2004-10-31  0:34     ` Luc Teirlinck
2004-10-31 12:53       ` Kim F. Storm
2004-10-31 15:24         ` Luc Teirlinck
2004-10-31 18:37           ` David Kastrup
2004-10-31 20:03             ` Luc Teirlinck
2004-10-31 20:13               ` David Kastrup
2004-10-31 21:40             ` Stefan
2004-10-31 23:39               ` Kim F. Storm
2004-11-01  0:33                 ` Stefan
2004-11-27  0:44         ` [NEW PATCH] " Kim F. Storm
     [not found]           ` <E1CYJ5T-0002qS-UR@fencepost.gnu.org>
2004-12-14 15:15             ` Kim F. Storm
2004-12-14 20:13               ` Robert J. Chassell
2004-12-14 23:33                 ` Kim F. Storm
2004-12-16 23:08                   ` Kevin Rodgers
2004-12-17  9:57                     ` Kim F. Storm
2004-12-17 10:20                     ` Alex Schroeder
2004-12-15  8:46                 ` Richard Stallman
2004-12-16 12:24               ` Richard Stallman
2004-12-16 15:12                 ` Kim F. Storm
2004-12-18  0:20                   ` Richard Stallman
2004-12-18 13:50                     ` Robert J. Chassell
2004-12-17 15:48                 ` Kim F. Storm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200410310009.i9V09DM03843@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).