Re: read-from-minibuffer with default value string

[Tyler Smith <tyler.smith@eku.edu>]

"Drew Adams" <drew.adams@oracle.com> 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
(<enter>) 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