unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: 13333@debbugs.gnu.org
Subject: bug#13333: 24.3.50; (emacs) `Minibuffer History'
Date: Tue, 1 Jan 2013 20:11:59 -0800	[thread overview]
Message-ID: <A64605487866469D901A64F9ACD0287D@us.oracle.com> (raw)


There are multiple problems with this node.
 
1. I was trying to find the place in the manual where we mention using
`M-n' to retrieve one or more default values for minibuffer input.  I
tried looking in the index for "default value" and even just "default",
but I found no such entries.
 
This concept of "default input", "default input value" "default
minibuffer input" etc. (choose your own entries) needs to be indexed.
 
Just tucking this behavior away under the topic of minibuffer history is
not sufficient in terms of indexing - it is a convenient hack that `M-n'
doubles as a way to retrieve default values, but looking up information
about the history should not be the only way to stumble upon info about
default input values.  Both concepts regarding minibuffer input: (a)
history (past inputs) and (b) default input values, need to be indexed.
 
2. Searching for "default" in this node, which is presumably the node
where #1 needs to be documented, I find an explanation that isn't very
good.  For one thing, it speaks of "default arguments".  There are no
arguments or parameters here.  These are default values for possible
minibuffer input.  This is user doc.
 
Users should not need to think in terms of `read-from-minibuffer',
`completing-read', or any other such function.  They should not even
need to be aware of these.  They don't care that some function is being
called to read their input, and the default values for their input are
also passed as parts of an argument to such a function.
 
3. We should also not say this, as it is not helpful and can be
confusing:
 
 You can think of this as moving through the "future history" list.
 
There is no logical connection between the set of default values and the
history list - whether "future history" or past.  The only connection is
that we have made the `M-n' key do double duty.  That's a good hack, but
there is zero reason to confuse users by inviting them to think of
retrieving default values as `moving through the "future history" list.'
 
Default values, like completion candidates, are shortcuts to entering
input.  Yes, something you input gets added to a history, but that does
not mean that the concept of a default input value - any more than the
concept of a completion candidate - is the same as that of a past input.
 
Default values are choices as much as completions are.  Neither set is
ordered temporally.  Putting the former on the `M-n' list is a
convenience that is NOT related to the fact that `M-n' can also move
forward along the history list.
 
4. Some keys are written incorrectly.  "`M-p'" is correct.  "<M-n>" is
incorrect (search for it in the node).  Uppercasing "<Up>" and "<Down>"
is also incorrect.  These function keys, like others (<home>, <end>,
etc.) should be lowercase.  That is the way Emacs itself communicates
regarding them, and it is the way Emacs doc should represent them also.
 
(Smarter would be to also get rid of the useless angle brackets, and
just use `...'.  But that's another story.)
 

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-12-31 on ODIEONE
Bzr revision: 111388 rudalics@gmx.at-20121231113513-subz2dazg6yjukzh
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
 






             reply	other threads:[~2013-01-02  4:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-02  4:11 Drew Adams [this message]
2013-01-02  4:15 ` bug#13333: 24.3.50; (emacs) `Minibuffer History' Drew Adams
2013-01-03  0:17 ` Juri Linkov
2013-01-03  0:38   ` Drew Adams
2021-08-23 14:41   ` Lars Ingebrigtsen
2021-08-23 15:33     ` bug#13333: [External] : " Drew Adams
2021-08-25  8:59     ` Gregory Heytings
2021-08-25 11:05       ` Lars Ingebrigtsen
2021-08-25 12:25         ` Gregory Heytings
2022-05-05 12:16           ` Lars Ingebrigtsen
2022-05-05 16:45             ` Howard Melman
2022-05-06 10:21               ` Lars Ingebrigtsen
2022-05-06 13:40                 ` Howard Melman
2022-05-06 13:57                   ` Eli Zaretskii
2022-05-06 14:54                     ` Howard Melman

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=A64605487866469D901A64F9ACD0287D@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=13333@debbugs.gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).