From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tyler Smith Newsgroups: gmane.emacs.help Subject: Re: read-from-minibuffer with default value string Date: Mon, 06 Dec 2010 09:08:08 -0500 Message-ID: <87vd370zav.fsf@guruji.demimonde> References: <87zksk0xkk.fsf@guruji.demimonde> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291644824 9982 80.91.229.12 (6 Dec 2010 14:13:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Dec 2010 14:13:44 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Dec 06 15:13:40 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PPbox-0004ma-ID for geh-help-gnu-emacs@m.gmane.org; Mon, 06 Dec 2010 15:13:40 +0100 Original-Received: from localhost ([127.0.0.1]:55684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPbow-00048l-SV for geh-help-gnu-emacs@m.gmane.org; Mon, 06 Dec 2010 09:13:38 -0500 Original-Received: from [140.186.70.92] (port=56197 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPbk6-0001qe-3U for help-gnu-emacs@gnu.org; Mon, 06 Dec 2010 09:08:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPbk4-0004tl-Gu for help-gnu-emacs@gnu.org; Mon, 06 Dec 2010 09:08:37 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:41953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPbk4-0004tf-29 for help-gnu-emacs@gnu.org; Mon, 06 Dec 2010 09:08:36 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PPbjz-00021w-8u for help-gnu-emacs@gnu.org; Mon, 06 Dec 2010 15:08:32 +0100 Original-Received: from 76.177.51.182 ([76.177.51.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Dec 2010 15:08:31 +0100 Original-Received: from tyler.smith by 76.177.51.182 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Dec 2010 15:08:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 133 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 76.177.51.182 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:gHfOgRqECmuKLsbiwMGgZhQuGMY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:75514 Archived-At: "Drew Adams" writes: >> I'm confused by the documentation for read-from-minibuffer. It says >> that the INITIAL-CONTENTS argument is obsolete, but I can't duplicate >> the functionality using DEFAULT-VALUE. > > You are correct that it does not _duplicate_ the functionality. > >> I'm working on a function that will query the user for input using >> completing-read. If the value entered isn't in the collection used >> for completing-read, then the user is asked if they want to add the >> value to the collection. > > Note what you just said: "asked _if_" (i.e. whether). To me, that says > `y-or-n-p'. > > What you really do however is ask them again to input the (same) KEY > (and then for a corresponding CODE). You ask them for the (same) KEY > as a proxy for directly asking _whether_ they want to add an entry for > KEY. Actually, there is a y-or-n-p in there. The flow I'm aiming for is: Enter a value from the list (collecting-read ...) If the value isn't on the list, check to make sure this isn't a mistake (y-or-n-p ...) If the value is going to be added permanently, give the user another chance to make sure there are no typos in it (read-from-minibuffer ...). Most of the time this will require only one additional keystroke () to confirm the value. However, your suggestions below about combining the second two queries looks solid. >> >> How can I rewrite this to work without using INITIAL-CONTENTS? > > A few alternatives I can think of: > > 1. Use `read-string' with KEY as the DEFAULT-VALUE. This is likely > what you want to do here. That's exactly what I want, thanks! And I see that it follows immediately after read-from-minibuffer in the manual. I was so focused on trying to get read-from-minibuffer working apparently I didn't scroll down to the next function. Oops. > 2. Use `read-from-minibuffer' with INITIAL-CONTENTS, but also use a > cons as HIST. That usage is not considered obsolete AFAIK. The doc > string does suggest that _any_ use of this parameter is "obsolete" but > it also mentions using it with a cons HIST value. > > And the Elisp manual does not say INITIAL-CONTENTS is "obsolete" at > all - it says that it is "mostly deprecated" (equivocation), and it > describes a use case where it is presumably not deprecated: > > Use of INITIAL-CONTENTS is mostly deprecated; we recommend using > a non-`nil' value only in conjunction with specifying a cons cell > for HIST. *Note Initial Input. > > That's not the same thing as being obsolete, and the mention of using > a cons HIST seems to be outside of any deprecation/obsolescence. But > see also node `Initial Input'. Yes, I had been trying to puzzle over that page. You quote the passages that suggest INITIAL-CONTENTS is still ok, but it also includes the line: Use of a cons cell as the value for INITIAL arguments is deprecated in user code. I'm not sure if this might be a documentation bug, but it sure left me with mixed messages. > 3. Use `y-or-n-p' (or `yes-or-no-p') if you are not really letting > users add a different KEY here from what they entered the first time > (in `completing-read') and you just want to let them say _whether or > not_ to add an entry with the _given_ KEY (you would then still read > the CODE). IOW, you show them KEY in the `y-or-n-p' prompt, which asks > for confirmation to add an entry. That sounds like a better design than what I had initially set out to accomplish (described above). I'll play with both to see which gives me fewer problems as a user. > > FWIW, _personally_ (but who cares?) I do not consider INITIAL-CONTENTS > to be obsolete. It provides _different_ behavior from a DEFAULT value > (as you noticed). In particular, the value is inserted in the > minibuffer, and that might be just what is wanted in some contexts. Sure, my only concerns in sorting this out are 1) to learn to use correct, idiomatic elisp and 2) to avoid constructs that are likely to change/disappear in future emacs versions. I think your suggestions will allow me to avoid the issue entirely, which is good. > > That's me - but everyone is different. I don't think that one usage > pattern should be considered so superior in general that the other > should be deprecated. IMO, Emacs Dev should not have tried to be so > controlling here - there was no need for that. Agreed. > > > [FWIW, in Icicles a user option controls the treatment of the DEFAULT > value (when INTIAL-CONTENTS is nil or ""). Its possible values: > > nil - Do not insert default value or add it to prompt. > t - Add default value to prompt. Do not insert it. > `insert-start' - Insert default value and leave cursor at start. > `insert-end' - Insert default value and leave cursor at end. > `preselect-start' - Insert and preselect default value; > leave cursor at beginning. > `preselect-end' - Insert and preselect default value; > leave cursor at end. > > My personal preference is `insert-end'. The default value is `t' > (similar to vanilla Emacs behavior).] One more reason that I ought to dig into Icicles. I've been meaning to look at it, but there are still a few issues with higher priority. Not least is getting to work this morning. Thanks for your help! Tyler