need obsolete arg in (read-from-minibuffer ...)
ken
works as desired, but 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))
What do the elisp mavens on this list say?
--
Anything is easy if you know how to do it.
Drew Adams
> 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))
What do you mean by "work"? And what do you mean "without" the obsolete arg?
That argument must be present if you include any arguments to the right of it.
What is considered (by some) to be "obsolete" is to use a non-nil value for the
argument. That's all. You cannot simply remove the arg if you include args
such as the DEFAULT-VALUE and INHERIT-INPUT-METHOD. A nil argument can be
omitted if there are no non-nil args coming after it (i.e., to the right).
ken
>> 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))
>
> 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. However, the docs say that this arg is obsolete.
I take this to mean that it should be left as "nil".
> That argument must be present if you include any arguments to the right of it.
That's correct.
>
> What is considered (by some) to be "obsolete" is to use a non-nil value for the
> argument. That's all. You cannot simply remove the arg if you include args
> such as the DEFAULT-VALUE and INHERIT-INPUT-METHOD. A nil argument can be
> omitted if there are no non-nil args coming after it (i.e., to the right).
I agree.
Drew Adams
> > the obsolete arg?
>
> isn't displayed in the minibuffer for editing by the user.
> However, the docs say that this arg is obsolete.
> I take this to mean that it should be left as "nil".
Correct. By "obsolete" the docs mean that that the Emacs developers think you
should leave it as nil (i.e., not use the INITIAL-CONTENTS argument), and use
only the DEFAULT-VALUE argument.
They think that the only useful use cases make no use of INITIAL-CONTENTS. But
see the doc string wrt the HIST arg, where they allow for an exception.
However, if you understand the difference between DEFAULT-VALUE and
INITIAL-CONTENTS, and _you prefer_ the behavior of INITIAL-CONTENTS for some
reason in some particular context, then use it. Personally, I do not consider
INITIAL-CONTENTS obsolete, FWIW.
Remember that you can pull the DEFAULT-VALUE into the minibuffer using `M-n'.
So the difference typically comes down to which you find more convenient: having
a value in the minibuffer initially (and having to get rid of it if you really
want something else instead) or pulling a value into the minibuffer when you
need it, using `M-n'.
If the default/initial value is used most of the time, then you might find it
more convenient to have the minibuffer prefilled with it. If it is not used
most of the time then you might find it more convenient not to have to clear it
out of the minibuffer and type another value. And this relative convenience
might change, depending on the command and the context.
Personally, I bind `M-k' to a command that clears out the minibuffer, and I
prefill the minibuffer. I prefill it with the value of DEFAULT-VALUE if
INITIAL-CONTENTS is empty (nil), which is typically the case. IOW, I have in
effect an automatic `M-n'. I hit `M-k' when I don't want the value. Other
people prefer to hit `M-n' when they do want the value.
A lot can depend on how appropriate/useful the default values are for the
commands you use. If the programmer provided only lousy default values, then
you probably don't want the minibuffer prefilled with them.
In Icicles, whether to prefill or not is a user choice (option).
http://www.emacswiki.org/emacs/Icicles_-_Customization_and_General_Tips#toc11
Stefan Monnier
>>> 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).
>> 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...
> 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
ken
>>> What do you mean by "work"? And what do you mean "without"
>>> the obsolete arg?
>> isn't displayed in the minibuffer for editing by the user.
>> I take this to mean that it should be left as "nil".
>
> should leave it as nil (i.e., not use the INITIAL-CONTENTS argument), and use
> only the DEFAULT-VALUE argument.
>
> They think that the only useful use cases make no use of INITIAL-CONTENTS. But
> see the doc string wrt the HIST arg, where they allow for an exception.
>
> However, if you understand the difference between DEFAULT-VALUE and
> INITIAL-CONTENTS, and _you prefer_ the behavior of INITIAL-CONTENTS for some
> reason in some particular context, then use it. Personally, I do not consider
> INITIAL-CONTENTS obsolete, FWIW.
>
> Remember that you can pull the DEFAULT-VALUE into the minibuffer using `M-n'.
> So the difference typically comes down to which you find more convenient: having
> a value in the minibuffer initially (and having to get rid of it if you really
> want something else instead) or pulling a value into the minibuffer when you
> need it, using `M-n'.
>
> If the default/initial value is used most of the time, then you might find it
> more convenient to have the minibuffer prefilled with it. If it is not used
> most of the time then you might find it more convenient not to have to clear it
> out of the minibuffer and type another value. And this relative convenience
> might change, depending on the command and the context.
>
Really? This is why that 2nd arg was declared obsolete!? That's rather
goofy. I thought there was some technical reason for it-- something to
do with code. Oh well.... Thanks for the answer.
Drew Adams
> That's rather goofy. I thought there was some technical
> Thanks for the answer.
I gave you what I think the rationale was for declaring it obsolete, based on
what is written in the doc. But I don't speak for those who decided this, and
your interpretation of the doc might be different from mine.
ken
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.
ken
>
> 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).
read-from-minibuffer has that history arg that I want to look into
eventually (maybe if I later do a Version 2 of what I'm doing now). But
there'd be a twist: Because the user would be required to input a
*unique* string, it would mean s/he couldn't input anything already
listed in the history. I first thought of a while loop which would
throw the user back into the minibuffer if the typed/chosen string
weren't unique... but that seems bogus. It would be a smoother UI if
the minibuffer opened once and didn't close until the string the user
typed (or selected) was unique (or the user did a quit).
How would that be done in read-from-minibuffer or with read-string?
Thanks some more.
>
>....
Stefan Monnier
> goofy. I thought there was some technical reason for it-- something to
> do with code. Oh well.... Thanks for the answer.
No, it's not technical, it's to try and make the UI more uniform.
Stefan