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

[Drew Adams]

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

My bad about that part.  Holding `mouse-1' depressed
does not show help on the function.  But I was right
that it also does not set point (as it should, if
`mouse-1-click-follows-link' were respected).

Holding `mouse-1' for a moment does nothing different.
The slow click just toggles the entry, same as a fast
click.

---

I was confused here by reading the help for `C-h k'
for the `mouse-1' click.  At the end of that help I
read this:

  For documentation of the corresponding mouse down
  event <down-mouse-1>, click and hold the mouse button
  longer than 0.5 second(s).

I was misreading that as applying to the command whose
doc I was reading: `profiler-report-toggle-entry'.

Instead, that sentence is about the key action I used
at the prompt of `C-h k'.

I think this help text is unclear.  99% of the text
is about a COMMAND - the command bound to the mouse
up event.  And then, with no separation at all, we
read a sentence that is suddenly about the second
event you caused in response to the `C-h k' prompt'.

This is awful (IMHO).  At the very least, that
sentence should be set off with a clear separator
(e.g. horizontal line or C-l char), and it should
be in parentheses.

Some better help design is needed for this, in any
case.  I'm sure I won't be the last user to fall
prey to this design gotcha.