all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: dieter@duenenhof-wilhelm.de, 19152@debbugs.gnu.org
Subject: bug#19152: 25.0.50; "You can run the command `debug-on-entry' with M-x deb-o RET"
Date: Sun, 23 Nov 2014 08:16:17 -0800 (PST)	[thread overview]
Message-ID: <2fcbcddc-6db0-4477-a1cc-cdd7df330d2c@default> (raw)
In-Reply-To: <87y4r26uc6.fsf@vsl28t2g.ww011>

> Actually I find these messages very instructive for people like me,
> which had no idea about this (new with Emacs-25?) abbreviation
> ability!

Then turn them for your own use.  And no, it is not new with
Emacs 25.  And even if there were some new completion matching
method, that is not a reason to bother users by drawing their
attention to it for their `M-x' use.  Let people learn normally.

You "had no idea about this".  Fine.  RTFM.  Read NEWS.  Explore
Emacs - there are a thousand ways to learn how to use it.

Some developer's new discovery (even of something that is not
new) might be a shiny new toy to that developer, but that is not
a reason to send up fireworks to advertise its existence.

> > This is not progress.  Noise, not help.  What were you thinking?
> 
> In the contrary I appreciate such messages very much because they
> remind me to become more efficient.

Again, for your own use, please.

> *But* above hint is not optimal!  It should have
> been for example  `M-x d-o- <RET>' and not: M-x deb-o RET!

Not necessarily.  Depends on the current values of
`completion-styles' and `completion-category-overrides'.

Does your messaging take those into account?  Are we going to
be analyzing possible completions for the current command now,
in order to give users a reasonable and context-sensitive such
"help" message?

The right thing is to drop this.  Let users learn about the
standard (and any nonstandard but possibly current) ways that
command names (and other names) can be abbreviated.

There will always be some users (typically newbies, but we are
all newbies for some parts of Emacs) who find such a message
helpful, because they haven't read the doc yet or otherwise
learned about this or that UI feature.

That's not a reason to turn this crap on by default.  Control
it by `novice.el', if you like, or add a user option (off by
default) `for novice-ui-help'.

> So bug#19152 is for real, since the hints are not yet conforming to
> key binding conventions and might return an ambiguous and not optimal
> (regarding to speed) key sequence.

One person's optimal is another person's bother.  There are
many ways to match a name.  Some might be more optimal for some
users in some contexts than others.  But there is nothing gained
by trying to find "the optimal" one ("regarding to speed" or any
other quality).  It is a matter of a user's key bindings, keyboard
layout, personal preferences, etc.

Not to mention that some (especially newbie?) users will take
such a message as an admonition that they are doing something
wrong, and that they should or must mend their ways to do
things the indicated "right way".

YAGNI.  This is not a good idea; sorry.

Please remove it, at at least as default behavior.  A reminder
that a command is bound to a key is a reasonable feature.  And
even for that we have a user option (`suggest-key-bindings').

If you want to add another user option for this noise, I have
no objection, as long as this behavior is off by default.

Just one opinion, of course.





  parent reply	other threads:[~2014-11-23 16:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-23  3:14 bug#19152: 25.0.50; "You can run the command `debug-on-entry' with M-x deb-o RET" Drew Adams
2014-11-23 11:15 ` H. Dieter Wilhelm
2014-11-23 15:36   ` Lars Magne Ingebrigtsen
2014-11-23 15:54     ` H. Dieter Wilhelm
2014-11-23 15:41   ` Jay Belanger
2014-11-23 16:14     ` H. Dieter Wilhelm
2014-11-23 16:16   ` Drew Adams [this message]
     [not found] ` <mailman.14373.1416741437.1147.bug-gnu-emacs@gnu.org>
2014-11-23 18:54   ` Alan Mackenzie
2014-11-23 18:59     ` Ivan Shmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2fcbcddc-6db0-4477-a1cc-cdd7df330d2c@default \
    --to=drew.adams@oracle.com \
    --cc=19152@debbugs.gnu.org \
    --cc=dieter@duenenhof-wilhelm.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.