GNU bug report logs - #30516
26.0; `C-h k' for mouse click is now confusing and less useful

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sun, 18 Feb 2018 17:20:02 UTC

Severity: minor

Tags: moreinfo

Found in version 26.0

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30516 in the body.
You can then email your comments to 30516 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#30516; Package emacs. (Sun, 18 Feb 2018 17:20:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 18 Feb 2018 17:20:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0; `C-h k' for mouse click is now confusing and less useful
Date: Sun, 18 Feb 2018 09:16:47 -0800 (PST)
A change for the worse seems to have been made to the help displayed
by `C-h k' for a mouse click.

Instead of clearly showing two separate help sections, one for the up
event and one for the down event, what you see now is help for the up
event followed immediately - with no separation, by this sentence:

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

That sentence follows text that describes the _command_ that is bound
to the up event.  But that sentence is NOT about that command.  It is
instead about an entirely different key (event): the down event.

This can only confuse users.  It is especially pernicious because that
sentence can be misread as being about the context of the command bound
to the up event.

Please clearly separate this information about `C-h k' from information
about the up-even command.  And consider putting it in parentheses.

And please consider having a link in *Help* that shows you the help for
the down event, instead of making a user go back to the original buffer
and repeat `C-h k' holding the mouse-button pressed > 0.5 sec.  Making a
user do that makes little (no?) sense.  That down-event information
should be available when the up-event is described.  Just show a link
that lets users see that down-event information.

This help was clearer before, it seems to me.  If there was a real
need for some kind of change, please accommodate that need with
more sensible and less confusing help information.  It should be
possible to do better than what we see now.  Thx.

In GNU Emacs 26.0.91 (build 1, x86_64-w64-mingw32)
 of 2018-01-22
Repository revision: 752fba992b793a74d202c9cfc3e1a92fd458e748
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30516; Package emacs. (Sun, 14 Jul 2019 15:52:01 GMT) Full text and rfc822 format available.

Message #8 received at 30516 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 30516 <at> debbugs.gnu.org
Subject: Re: bug#30516: 26.0; `C-h k' for mouse click is now confusing and
 less useful
Date: Sun, 14 Jul 2019 17:51:31 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> A change for the worse seems to have been made to the help displayed
> by `C-h k' for a mouse click.
>
> Instead of clearly showing two separate help sections, one for the up
> event and one for the down event, what you see now is help for the up
> event followed immediately - with no separation, by this sentence:
>
>   For documentation of the corresponding mouse down
>   event <down-mouse-1>, click and hold the mouse button
>   longer than 0.5 second(s).

If I `C-h k mouse-1', I get the contents below, so I'm unable to
reproduce this.  Are you still seeing this on the trunk, or do you have
a different recipe for how to reproduce it?

---

There were several key-sequences:

  <down-mouse-1> at that spot runs the command mouse-drag-region
  <mouse-1> at that spot runs the command mouse-set-point

They're all described below.



<down-mouse-1> at that spot runs the command mouse-drag-region (found
in global-map), which is an interactive compiled Lisp function in
‘mouse.el’.

It is bound to <down-mouse-1>.

(mouse-drag-region START-EVENT)

Set the region to the text that the mouse is dragged over.
Highlight the drag area as you move the mouse.
This must be bound to a button-down mouse event.
In Transient Mark mode, the highlighting remains as long as the mark
remains active.  Otherwise, it remains until the next input event.

When the region already exists and ‘mouse-drag-and-drop-region’
is non-nil, this moves the entire region of text to where mouse
is dragged over to.



<mouse-1> at that spot runs the command mouse-set-point (found in
global-map), which is an interactive compiled Lisp function in
‘mouse.el’.

It is bound to <mouse-1>.

(mouse-set-point EVENT &optional PROMOTE-TO-REGION)

  Probably introduced at or before Emacs version 22.1.

Move point to the position clicked on with the mouse.
This should be bound to a mouse click event type.
If PROMOTE-TO-REGION is non-nil and event is a multiple-click, select
the corresponding element around point, with the resulting position of
point determined by ‘mouse-select-region-move-to-beginning’.

[back]


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 14 Jul 2019 15:52:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30516; Package emacs. (Sun, 14 Jul 2019 21:59:01 GMT) Full text and rfc822 format available.

Message #13 received at 30516 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 30516 <at> debbugs.gnu.org
Subject: RE: bug#30516: 26.0; `C-h k' for mouse click is now confusing and
 less useful
Date: Sun, 14 Jul 2019 14:58:06 -0700 (PDT)
> > A change for the worse seems to have been made to the help displayed
> > by `C-h k' for a mouse click.
> >
> > Instead of clearly showing two separate help sections, one for the up
> > event and one for the down event, what you see now is help for the up
> > event followed immediately - with no separation, by this sentence:
> >
> >   For documentation of the corresponding mouse down
> >   event <down-mouse-1>, click and hold the mouse button
> >   longer than 0.5 second(s).
> 
> If I `C-h k mouse-1', I get the contents below, so I'm unable to
> reproduce this.  Are you still seeing this on the trunk, or do you have
> a different recipe for how to reproduce it?

Still seeing it, `emacs -Q`, Emacs 26.2.

Please reread the bug report carefully.  It describes
perfectly what I (still) see.

---

What you report corresponds instead to what happens
if you do what it says in that somewhat puzzling
final paragraph, quoted in the bug report:

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

An ordinary `mouse-1' _click_ does NOT produce the
output you describe.  To get that, you need to
_press_ `mouse-1', _hold_ it pressed more than half
a second, and then release it.

The help I described is what you get when you click
`mouse-1'.  And it does NOT describe the _click_.
It describes only the last event of the click.

I imagine that someone intentionally implemented
this help "improvement", and that you will thus say
that it is behaving as designed.

The bug report is to say that, whether by design or
accident, the behavior is worse, not better, now.
For users, that is.  IMHO.

If some real problem (e.g. a bug) existed that
provoked this change, are you sure that it was
worse than the new behavior?  What was that
problem, if there was one?  Was it new, or had it
always been with us over the decades?

In any case, this bug report counts one user as
not appreciating the new behavior.  Do with it
what you will.

But it's hard to understand that you could not
repeat the reported behavior.  Just click.
Normally.

> <down-mouse-1> at that spot runs the command mouse-drag-region (found
> in global-map), which is an interactive compiled Lisp function in
> ‘mouse.el’.
> 
> It is bound to <down-mouse-1>.
> 
> (mouse-drag-region START-EVENT)
> 
> Set the region to the text that the mouse is dragged over.
> Highlight the drag area as you move the mouse.
> This must be bound to a button-down mouse event.
> In Transient Mark mode, the highlighting remains as long as the mark
> remains active.  Otherwise, it remains until the next input event.
> 
> When the region already exists and ‘mouse-drag-and-drop-region’
> is non-nil, this moves the entire region of text to where mouse
> is dragged over to.
> 

You skipped this line, which occurs after
that text and before the next text you cite:

  ----------------- up-event ----------------

> <mouse-1> at that spot runs the command mouse-set-point (found in
> global-map), which is an interactive compiled Lisp function in
> ‘mouse.el’.
> 
> It is bound to <mouse-1>.
> 
> (mouse-set-point EVENT &optional PROMOTE-TO-REGION)
> 
>   Probably introduced at or before Emacs version 22.1.

(That last ("Probably...") line is not in the Emacs 26.2
output that I see.  Perhaps it was added afterward.)

> Move point to the position clicked on with the mouse.
> This should be bound to a mouse click event type.
> If PROMOTE-TO-REGION is non-nil and event is a multiple-click, select
> the corresponding element around point, with the resulting position of
> point determined by ‘mouse-select-region-move-to-beginning’.




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Thu, 18 Jul 2019 06:06:02 GMT) Full text and rfc822 format available.

Notification sent to Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer. (Thu, 18 Jul 2019 06:06:02 GMT) Full text and rfc822 format available.

Message #18 received at 30516-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 30516-done <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#30516: 26.0;
 `C-h k' for mouse click is now confusing and less useful
Date: Thu, 18 Jul 2019 09:05:23 +0300
> Date: Sun, 14 Jul 2019 14:58:06 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 30516 <at> debbugs.gnu.org
> 
> > If I `C-h k mouse-1', I get the contents below, so I'm unable to
> > reproduce this.  Are you still seeing this on the trunk, or do you have
> > a different recipe for how to reproduce it?
> 
> Still seeing it, `emacs -Q`, Emacs 26.2.
> 
> Please reread the bug report carefully.  It describes
> perfectly what I (still) see.

Lars also described perfectly what he sees.  The reason for the
difference is that Lars tried that in Emacs 27, where the help text
for mouse clicks is more elaborate.

So I'm closing this bug report.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 15 Aug 2019 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 228 days ago.

Previous Next


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