[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]