Re: need obsolete arg in (read-from-minibuffer ...)

[ken <gebser@mousecar.com>]

On 12/31/1969 07:00 PM  wrote:
>>>> the docs say that 2nd arg is obsolete.  However,
>>>> I've tried a lot of permutations of the args listed and I 
>>>> can't get this function to work without using that obsolete 2nd arg.
>>>> (defun mygetstr (def-val)
>>>> (read-from-minibuffer "Enter/Edit string: "
>>>> def-val nil nil nil def-val t))
> 
> First note: you probably don't want to use read-from-minibuffer, but use
> read-string instead (read-from-minibuffer is lower-level and slightly more
> tricky to use right).

I guess I should have asked this list before I spent so much time trying
to get it to work.  But now that it's working, I think I'll just keep it.


> 
>>> What do you mean by "work"?  And what do you mean "without" the
>>> obsolete arg?
>> Sorry, I should have been clearer.  If I change the 2nd arg from
>> "def-val" to "nil", then def-val isn't displayed in the minibuffer for
>> editing by the user.
> 
> Exactly: placing the default value into the minibuffer text is what
> is discouraged.  Instead, you should pass it as the `default-value'
> argument and manually make your prompt look like
> "<prompt> (default <def>): "
> I know it sounds silly, but ...blablabla... history ...blablabla...

I think I see what you're saying:  The default value is displayed in the
prompt, but not after the prompt in the editable section of the
minibuffer, yes?  If so, when the user just hits RET, is the default
value confirmed (and returned), or does this return nil?  It's ambiguous
to me now and I think it would be ambiguous to the user... probably
leading to his/her getting not what was intended.

Me, I don't think it's a big deal to do C-a C-k to clear a string
provided in the minibuffer.  I do it without even having to think about
it.  If there were a keyboard on its handlebars, I could do it while
riding my bike in heavy traffic.  I don't get what all the juice is about.

Moreover, I sometimes C-a C-k a string in the minibuffer (and then
commonly yank it back) just because I want the string in the kill ring
for subsequent use elsewhere.  If it's not editably displayed there,
this trick is out and the window and it's considerably fricking more
typing I have to do.  :-(

The more typing I can have emacs do for me, the better I like it.  I
guess I'm just an obsolete, deprecated kind of guy.


> 
>> However, the docs say that this arg is obsolete.
>> I take this to mean that it should be left as "nil".
> 
> Unless you really have a good argument why you want the initial
> minibuffer content to not be empty, of course.  The "obsolete" is really
> about the UI guidelines and should be enforced differently ideally, but
> for now that's what we have.
> 
> 
>         Stefan

Rather than say "obsolete", the docs would better say "discouraged for
non-technical reasons"... and then maybe even give those reasons.  A few
words like that would have saved me a lot of time today, time which
would have been better spent writing more code.

But thanks to all for the clarifications.