bug#30491: 26.0; (elisp) `Profiling'

[Drew Adams <drew.adams@oracle.com>]

> And I found that the action that is now associated with a
> `mouse-1' click, which is to "open" the entry of the line
> clicked, is more annoying than helpful.  Clicking to set
> point is too useful to be lost or relegated to "slow"
> clicking.  I ended up using only the keyboard to move the
> cursor, which isn't always ideal for direct access.

I have `mouse-1-click-follows-link' = nil, which normally
means that `mouse-1' click just sets point.  At the very
least it normally does NOT mean that `mouse-1' click does
the same thing that `mouse-2' click does.

In this context, I would like `mouse-2' to do what `mouse-1'
is currently doing: open the clicked entry.  And I would
like (and expect) that `mouse-1' simply sets point, as
usual.

This change to making `mouse-1' always open the entry
seems to go against Emacs convention and subvert the
user's setting of `mouse-1-click-follows-link'.

Not only that, but the normal behavior of non-nil
`mouse-1-click-follows-link' is that if you hold `mouse-1'
depressed for a moment the command simply sets point.
But in the profiler report buffer doing that instead
shows `C-h f' output for the function.

So it seems that the Profiler report key bindings do
not respect `mouse-1-click-follows-link' for either
a nil or a non-nil value.

This is bad design, IMO - a design bug.  It is pretty
much impossible, it seems, to use `mouse-1' to set
point.