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

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

[Drew Adams]

All Info links respect mouse-1-click-follows-link, except those in the header
line. 

All links appear the same, and they should all act the same. Links in the header
line should respect mouse-1-click-follows-link, like all the others.
 
 
In GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600)
 of 2008-03-26 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 

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

[Stefan Monnier]

tag 374 +moreinfo
thanks

> All Info links respect mouse-1-click-follows-link, except those in the header
> line. 

What does this mean, exactly?  They do react to a mouse-1 click.
So do you mean that they should not react to a mouse-1 click if
mouse-1-click-follows-link is nil?
If so, what other binding would you expect mouse-1 to trigger when
mouse-1-click-follows-link is nil?


        Stefan

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

[Drew Adams]

> tag 374 +moreinfo
> thanks
> 
> > All Info links respect mouse-1-click-follows-link, except 
> > those in the header line. 
> 
> What does this mean, exactly?

It means that clicks in the header line links should do what clicks on the
non-header line links do: they too should respect the variable's value.

> They do react to a mouse-1 click.
> So do you mean that they should not react to a mouse-1 click if
> mouse-1-click-follows-link is nil?

Yes, of course. That's what the variable is for: to turn off link sensitivity to
mouse-1 clicks. Otherwise, the default behavior would be the only behavior, and
there would be no option.

Well, strictly speaking, an option might remain, as a numerical value, but it
would be called something like `mouse-click-link-delay', and the doc string
would not say "Non-nil means _that_ clicking mouse-1 on a link follows the
link."

The option is a boolean flag nil/non-nil, whose non-nil value has the secondary
effect of specifying a click delay, beyond which the link is not followed.

To be more clear, the doc string should perhaps explicitly state that nil means
the same as non-nil plus waiting the full delay: "the normal Mouse-1 action
(typically set point)."

> If so, what other binding would you expect mouse-1 to trigger when
> mouse-1-click-follows-link is nil?

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.

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

[Stefan Monnier]

tag 374 -moreinfo +wontfix
thanks

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


        Stefan

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

[Drew Adams]

> > 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.

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

[Lennart Borgman (gmail)]

Drew Adams wrote:
> IMO, the _default_ behavior of mouse-1 should be to not follow links.

I disagree, I think it is a good default. The reason is the same as 
before when we discussed this: Users are accustomed to this from other 
apps, for example web browsers.

However it might be good to only use this for links that have a visual 
clue in the form of underlining (if default faces are used).

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

[Drew Adams]

> > IMO, the _default_ behavior of mouse-1 should be to not 
> > follow links.
> 
> I disagree, I think it is a good default. 

Yes, we disagree. Forget that I spoke about the default - let's not open that
discussion again.

The point here is about users being _able_ to have the traditional
(pre-22)behavior, not about setting the traditional behavior as the default.

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

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>> IMO, the _default_ behavior of mouse-1 should be to not 
>>> follow links.
>> I disagree, I think it is a good default. 
> 
> Yes, we disagree. Forget that I spoke about the default - let's not open that
> discussion again.

Ok.

> The point here is about users being _able_ to have the traditional
> (pre-22)behavior, not about setting the traditional behavior as the default.

Wouldn't that need be much less if the links where underlined or only 
underlined links where followed by mouse-1 (as I wrote in the previous 
comment to your proposal)?

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

[Drew Adams]

> > The point here is about users being _able_ to have the traditional
> > (pre-22)behavior, not about setting the traditional 
> > behavior as the default.
> 
> Wouldn't that need be much less if the links where underlined or only 
> underlined links where followed by mouse-1 (as I wrote in the 
> previous comment to your proposal)?

1. That is independent. You can make a separate bug or enhancement report, if
you like. That is not what this is about.

2. No. The need is to be able to click mouse-1 on a link, regardless of how it
is displayed, and not follow the link. That's what `mouse-1-follows-link' is
for: to be able to not have mouse-1 follow links.

I often want to just click somewhere in a buffer - including its text area,
mode-line, and header-line, just to select the buffer. Perhaps that is because I
use separate frames a lot. Users are various.

The same principle applies to links in the header-line and mode-line that
applies to links elsewhere. Just as I want to be able to click anywhere in Dired
to select the buffer, so I want to be able to click anywhere in Info to select
the buffer.

It has nothing to do with link appearance. (It would not help to underline links
in Dired.) Quite the contrary: I don't want to have to look carefully to see if
I'm clicking on a link, just to select a buffer. I don't want to check whether
text is underlined or whatever.

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

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>> The point here is about users being _able_ to have the traditional
>>> (pre-22)behavior, not about setting the traditional 
>>> behavior as the default.
>> Wouldn't that need be much less if the links where underlined or only 
>> underlined links where followed by mouse-1 (as I wrote in the 
>> previous comment to your proposal)?

> It has nothing to do with link appearance. (It would not help to underline links
> in Dired.) Quite the contrary: I don't want to have to look carefully to see if
> I'm clicking on a link, just to select a buffer. I don't want to check whether
> text is underlined or whatever.

Thanks, I see. But I believe many people would think differently since 
they have learned otherwise from for example web browsers.

But with that I do not want to say I am against your proposal for an 
option. Personally I do not mind.

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

[Drew Adams]

> >>> The point here is about users being _able_ to have the traditional
> >>> (pre-22)behavior, not about setting the traditional 
> >>> behavior as the default.
> >>
> >> Wouldn't that need be much less if the links where 
> >> underlined or only underlined links where followed by
> >> mouse-1 (as I wrote in the 
> >> previous comment to your proposal)?
> 
> > It has nothing to do with link appearance. (It would not 
> > help to underline links in Dired.) Quite the contrary:
> > I don't want to have to look carefully to see if
> > I'm clicking on a link, just to select a buffer. I don't 
> > want to check whether text is underlined or whatever.
> 
> Thanks, I see. But I believe many people would think 
> differently since they have learned otherwise from for
> example web browsers.

And that's precisely why we let them use mouse-1 to follow links. I am not
proposing to take that away from anyone who expects or wants it.

> But with that I do not want to say I am against your proposal for an 
> option. Personally I do not mind.

Good. I can't believe anyone would mind. Why prevent some users from not
following any links with mouse-1?

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

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>>>> The point here is about users being _able_ to have the traditional
>>>>> (pre-22)behavior, not about setting the traditional 
>>>>> behavior as the default.
>>>> Wouldn't that need be much less if the links where 
>>>> underlined or only underlined links where followed by
>>>> mouse-1 (as I wrote in the 
>>>> previous comment to your proposal)?
>>> It has nothing to do with link appearance. (It would not 
>>> help to underline links in Dired.) Quite the contrary:
>>> I don't want to have to look carefully to see if
>>> I'm clicking on a link, just to select a buffer. I don't 
>>> want to check whether text is underlined or whatever.
>> Thanks, I see. But I believe many people would think 
>> differently since they have learned otherwise from for
>> example web browsers.
> 
> And that's precisely why we let them use mouse-1 to follow links. I am not
> proposing to take that away from anyone who expects or wants it.

I am sure you not. I just thought this was a good time to ask for 
consistency regarding underline. (I think telling about it in a context 
like this may be better than making it a separate proposal, but I am not 
sure.)

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

[Drew Adams]

> > And that's precisely why we let them use mouse-1 to follow 
> > links. I am not proposing to take that away from anyone
> > who expects or wants it.
> 
> I am sure you not. I just thought this was a good time to ask for 
> consistency regarding underline.

I object to that, and not just in this case. Nothing prevents you from starting
a new thread or filing a new bug, and even using "[was: Info header line does
not...]".

It hasn't happened yet in this case, but injecting a new topic can cause threads
to diverge and the original topic to become lost. It happens quite often in
emacs-devel. Everyone has done it, including me. Very few people ever
intentionally hijack a thread, but it happens quite often unintentionally.

The risk is always there, but it is strongest when the new topic is more
controversial than the original - people jump in to argue about the sidetrack. A
casual side proposal about key bindings or colors is almost sure to set some
people off, and can easily lead a thread astray.

In this case, I myself might want to contribute to a discussion about link
underlining (haven't thought about it), but I'm not going to do that within this
thread.

> (I think telling about it in a context like this may be better
> than making it a separate proposal, but I am not sure.)

Absolutely not. Yes, context helps. But nothing prevents you from copying some
of the context to a new thread. You can even keep the original subject with
"was", for reference.

It's hard enough to keep people focused on rational argument, without adding
forks in the path.

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

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>> And that's precisely why we let them use mouse-1 to follow 
>>> links. I am not proposing to take that away from anyone
>>> who expects or wants it.
>> I am sure you not. I just thought this was a good time to ask for 
>> consistency regarding underline.
> 
> I object to that, and not just in this case. Nothing prevents you from starting
> a new thread or filing a new bug, and even using "[was: Info header line does
> not...]".

It is a good idea.

> It hasn't happened yet in this case, but injecting a new topic can cause threads
> to diverge and the original topic to become lost. It happens quite often in
> emacs-devel. Everyone has done it, including me. Very few people ever
> intentionally hijack a thread, but it happens quite often unintentionally.
> 
> The risk is always there, but it is strongest when the new topic is more
> controversial than the original - people jump in to argue about the sidetrack.

You have good points, but I think it unfortunately always is a difficult 
choice. Perhaps your own reply also illustrates that.

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

[Stefan Monnier]

>> > 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.

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

> 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.

That's pretty much "always" been the case: you cannot blindly click (with
mouse-1 or something else) on "active" areas on the screen in general.
With mouse-1-click-follows-link deactivated, this is less often the
case, but it is still the case.

> 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.  Emacs-22 might be "worse"
in this respect 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).


        Stefan

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

[Drew Adams]

> > 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
also.

> 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.

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

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> All Info links respect mouse-1-click-follows-link, except those in the
> header line.

Fixed in trunk.  Thanks.