[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#374: Info header line does not respectmouse-1-click-follows-link

From: Drew Adams
Subject: bug#374: Info header line does not respectmouse-1-click-follows-link
Date: Sat, 14 Jun 2008 11:21:14 -0700

> > 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.
> In normal use, there are plenty of other places on the screen 
> where you can click to do that.

Please don't tell me where I can click. Just let me customize an option to turn
off mouse-1 following links - everywhere. That should be what
`mouse-1-click-follows-link' is for. If you want to create another option for
that, fine. It is a regression to not have this possibility at all.

> `mouse-1-click-follows-link' was
> introduced to resolve conflicts where "clicking elsewhere" is not an option,
> i.e. because you might either want to follow the link or want to place
> point within the link's text.

No. The use of a numeric delay in `mouse-1-click-follows-link' was added for
that. The option itself was introduced to allow mouse-1 to follow links for some
users but not impose that behavior on all users.

There is absolutely no reason not to let users turn off mouse-1 following links
everywhere. Please don't tell us that there is plenty of room to click in the
back of the bus. Why would you prevent someone from choosing to not follow links
with mouse-1 anywhere?

Even in a context where one cannot set point, I would not want mouse-1 to follow
a link. I might have accidentally clicked that link - I still don't want to
follow it. If nothing else is appropriate, then a nil or 0 option value should
make mouse-1 just do nothing for a link: `ignore'.

How would that be objectionable? It would not prevent anyone from using mouse-1
to follow links. The 0 and nil values currently don't serve anyone. And neither
follows what the doc string suggests.

> > 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.
> Try Emacs-21 and take a look at its mode-line.  You'll see it has
> mouse-1 on the buffer name active as well.  

Yes, it was a bug then, as well, but it could be argued that that is actually a
button, not a link. I never used Emacs 21, so I never filed any bugs against it.
I prefer Emacs 20 to Emacs 21 (by far), at least on Windows.

Personally, I would like to see an option to prevent mouse-1 from activating
buttons, as well. Whatever the action is, if mouse-2 already does it, then users
should be able to choose to use _only_ mouse-2 for that. 

Emacs is now entre deux chaises wrt mouse-1 and mouse-2. We have tried to let
mouse-1 do what mouse-2 does wrt links and buttons because that is what newbies
expect (yes, and what some oldies prefer). But we should not prohibit other
Emacs users from _not_ using mouse-1 that way. Anywhere. Users should be able to
easily get rid of this redundancy, if they wish.

> Emacs-22 might be "worse" in this respect

Yes, it is much worse. What was true only for buttons is now true for links

> but I don't think it's a good idea to force such mouse-1
> bindings to be redundant (so they can be disabled with
> mouse-1-click-follows-link).

I am not forcing anything. I want you to be able to use mouse-1 to follow links.

You are forcing me to follow links with mouse-1 (in some situations). It is you
that is arguing to force redundancy on users (between mouse-1 and mouse-2, for
both links and buttons). Give users the choice; that's all I'm asking.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]