GNU bug report logs - #30491
26.0; (elisp) `Profiling'

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30491 <at> debbugs.gnu.org
Subject: bug#30491: 26.0; (elisp) `Profiling'
Date: Sun, 18 Feb 2018 07:52:36 -0800 (PST)

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.