From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#13333: 24.3.50; (emacs) `Minibuffer History' Date: Tue, 1 Jan 2013 20:11:59 -0800 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1357099967 8270 80.91.229.3 (2 Jan 2013 04:12:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2013 04:12:47 +0000 (UTC) To: 13333@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 02 05:13:03 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TqFhP-0007bl-CW for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Jan 2013 05:13:03 +0100 Original-Received: from localhost ([::1]:41752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqFhA-0007HJ-7d for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Jan 2013 23:12:48 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:60559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqFh7-0007HB-4r for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2013 23:12:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TqFh5-0004ns-RB for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2013 23:12:45 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqFh5-0004no-NQ for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2013 23:12:43 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TqFiM-0005Y2-BE for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2013 23:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Jan 2013 04:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 13333 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: Original-Received: via spool by submit@debbugs.gnu.org id=B.135710003021299 (code B ref -1); Wed, 02 Jan 2013 04:14:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 2 Jan 2013 04:13:50 +0000 Original-Received: from localhost ([127.0.0.1]:39550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TqFiA-0005XU-0E for submit@debbugs.gnu.org; Tue, 01 Jan 2013 23:13:50 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49158) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TqFi5-0005XK-LH for submit@debbugs.gnu.org; Tue, 01 Jan 2013 23:13:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TqFgn-0004lS-Re for submit@debbugs.gnu.org; Tue, 01 Jan 2013 23:12:26 -0500 Original-Received: from lists.gnu.org ([208.118.235.17]:51327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqFgm-0004lE-Qy for submit@debbugs.gnu.org; Tue, 01 Jan 2013 23:12:25 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:60520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqFgl-0007Fj-Mr for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2013 23:12:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TqFgg-0004kS-4e for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2013 23:12:23 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:27025) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqFgf-0004kE-Uo for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2013 23:12:18 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r024CFBr025296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Jan 2013 04:12:16 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r024CE2X021456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2013 04:12:15 GMT Original-Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r024CE37016488 for ; Tue, 1 Jan 2013 22:12:14 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jan 2013 20:12:14 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac3on09Jz8BPSlGbTXKf9805gL3hmg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:69283 Archived-At: 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. "" is incorrect (search for it in the node). Uppercasing "" and "" is also incorrect. These function keys, like others (, , 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'