all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 374@emacsbugs.donarmstrong.com, bug-gnu-emacs@gnu.org
Subject: bug#374: Info header line does not respect mouse-1-click-follows-link
Date: Sat, 14 Jun 2008 09:37:34 -0700	[thread overview]
Message-ID: <00bc01c8ce3c$f3079860$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <jwvlk18f3rc.fsf-monnier+emacsbugreports@gnu.org>

> > Whatever mouse-1 does on non-links, which is also whatever mouse-1
> > does elsewhere (e.g. non-header lines) when the variable is nil. In
> > most cases, it is what `mouse-set-point' does.
> 
> But mouse-set-point makes no sense on the header-line: there's no
> associated buffer position.

Wrong. You can click a non-link in the header-line or mode-line to set focus:
select its window/buffer. That is a primary use of the normal mouse-1 binding.

When mouse-1 follows links, you have to be careful where you click, to do that.
The bug is that for these screen areas, mouse-1 follows links regardless of the
option value.

> It's really like the mode-line, where
> mouse-1-click-follows-link is usually not taken into account either.

`mouse-1-click-follows-link' should also be taken into account in the mode-line,
for the same reason. Same bug or separate bug - take your pick.

Prior to the existence of option `mouse-1-click-follows-link', mouse-1 never
followed links - anywhere, ever. Users should still be able to obtain that
(superior) behavior. With that choice, users are able to click parts of Emacs at
nearly any location, to (typically) set focus.

IMO, the _default_ behavior of mouse-1 should be to not follow links. Failing
that change in default, users should at least have the _option_ to turn off link
following by mouse-1 everywhere. mouse-2 already follows links - there is no
reason to impose on _all users_ the redundancy of mouse-1 also doing that.

You cannot even use 0 as the value of the option in order to turn off link
following. That too is a (different) bug. The doc says that if the click time is
greater than the option value, then links are not followed: "The absolute
numeric value specifices the maximum duration of a "short click" in
milliseconds." If 0 is the max duration of a short click, then anything longer
than 0 should be treated the same as a long click.

Both 0 and nil should turn off link following by mouse-1 - *everywhere*. There
is no reason not to provide users with this pre-Emacs 22 behavior as an option.
Anything less is a regression.








  reply	other threads:[~2008-06-14 16:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-07  0:07 bug#374: Info header line does not respect mouse-1-click-follows-link Drew Adams
2008-06-14  2:03 ` Stefan Monnier
2008-06-14  8:08   ` Drew Adams
2008-06-14 15:16     ` Stefan Monnier
2008-06-14 16:37       ` Drew Adams [this message]
2008-06-14 17:02         ` Lennart Borgman (gmail)
2008-06-14 17:09           ` Drew Adams
2008-06-14 17:14             ` Lennart Borgman (gmail)
2008-06-14 17:34               ` Drew Adams
2008-06-14 17:44                 ` Lennart Borgman (gmail)
2008-06-14 18:18                   ` Drew Adams
2008-06-14 18:39                     ` Lennart Borgman (gmail)
2008-06-14 20:03                       ` Drew Adams
2008-06-14 20:34                         ` Lennart Borgman (gmail)
2008-06-14 17:18         ` Stefan Monnier
2008-06-14 18:21           ` bug#374: Info header line does not respectmouse-1-click-follows-link Drew Adams
2012-07-08  8:28 ` bug#374: Info header line does not respect mouse-1-click-follows-link Chong Yidong

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

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

  git send-email \
    --in-reply-to='00bc01c8ce3c$f3079860$0200a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=374@emacsbugs.donarmstrong.com \
    --cc=bug-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.