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