* need obsolete arg in (read-from-minibuffer ...) @ 2011-03-18 20:23 ken 2011-03-18 20:37 ` Drew Adams 0 siblings, 1 reply; 10+ messages in thread From: ken @ 2011-03-18 20:23 UTC (permalink / raw To: GNU Emacs List The below is a stripped-down version of a function I'm writing. It 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: need obsolete arg in (read-from-minibuffer ...) 2011-03-18 20:23 need obsolete arg in (read-from-minibuffer ...) ken @ 2011-03-18 20:37 ` Drew Adams 2011-03-18 22:12 ` ken [not found] ` <mailman.23.1300486344.31996.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 10+ messages in thread From: Drew Adams @ 2011-03-18 20:37 UTC (permalink / raw To: gebser, 'GNU Emacs List' > 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? 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). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need obsolete arg in (read-from-minibuffer ...) 2011-03-18 20:37 ` Drew Adams @ 2011-03-18 22:12 ` ken 2011-03-18 23:03 ` Drew Adams [not found] ` <mailman.23.1300486344.31996.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 10+ messages in thread From: ken @ 2011-03-18 22:12 UTC (permalink / raw To: Drew Adams; +Cc: 'GNU Emacs List' On 03/18/2011 04:37 PM Drew Adams 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)) > > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: need obsolete arg in (read-from-minibuffer ...) 2011-03-18 22:12 ` ken @ 2011-03-18 23:03 ` Drew Adams 2011-03-19 2:22 ` ken [not found] ` <mailman.0.1300501334.15172.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 10+ messages in thread From: Drew Adams @ 2011-03-18 23:03 UTC (permalink / raw To: gebser; +Cc: 'GNU Emacs List' > > What do you mean by "work"? And what do you mean "without" > > the obsolete arg? > > 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". 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need obsolete arg in (read-from-minibuffer ...) 2011-03-18 23:03 ` Drew Adams @ 2011-03-19 2:22 ` ken 2011-03-19 2:34 ` Drew Adams [not found] ` <mailman.0.1300501334.15172.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 10+ messages in thread From: ken @ 2011-03-19 2:22 UTC (permalink / raw To: Drew Adams, GNU Emacs List On 03/18/2011 07:03 PM Drew Adams wrote: >>> What do you mean by "work"? And what do you mean "without" >>> the obsolete arg? >> 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". > > 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. > > .... 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: need obsolete arg in (read-from-minibuffer ...) 2011-03-19 2:22 ` ken @ 2011-03-19 2:34 ` Drew Adams 0 siblings, 0 replies; 10+ messages in thread From: Drew Adams @ 2011-03-19 2:34 UTC (permalink / raw To: gebser, 'GNU Emacs List' > 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. 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <mailman.0.1300501334.15172.help-gnu-emacs@gnu.org>]
* Re: need obsolete arg in (read-from-minibuffer ...) [not found] ` <mailman.0.1300501334.15172.help-gnu-emacs@gnu.org> @ 2011-03-22 1:02 ` Stefan Monnier 0 siblings, 0 replies; 10+ messages in thread From: Stefan Monnier @ 2011-03-22 1:02 UTC (permalink / raw To: help-gnu-emacs > 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. No, it's not technical, it's to try and make the UI more uniform. Stefan ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <mailman.23.1300486344.31996.help-gnu-emacs@gnu.org>]
* Re: need obsolete arg in (read-from-minibuffer ...) [not found] ` <mailman.23.1300486344.31996.help-gnu-emacs@gnu.org> @ 2011-03-19 1:59 ` Stefan Monnier 2011-03-19 5:23 ` ken 2011-03-19 5:51 ` need obsolete arg in (read-from-minibuffer ...) in Version 2.0 ken 0 siblings, 2 replies; 10+ messages in thread From: Stefan Monnier @ 2011-03-19 1:59 UTC (permalink / raw To: help-gnu-emacs >>> 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). >> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need obsolete arg in (read-from-minibuffer ...) 2011-03-19 1:59 ` Stefan Monnier @ 2011-03-19 5:23 ` ken 2011-03-19 5:51 ` need obsolete arg in (read-from-minibuffer ...) in Version 2.0 ken 1 sibling, 0 replies; 10+ messages in thread From: ken @ 2011-03-19 5:23 UTC (permalink / raw Cc: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need obsolete arg in (read-from-minibuffer ...) in Version 2.0. 2011-03-19 1:59 ` Stefan Monnier 2011-03-19 5:23 ` ken @ 2011-03-19 5:51 ` ken 1 sibling, 0 replies; 10+ messages in thread From: ken @ 2011-03-19 5:51 UTC (permalink / raw Cc: help-gnu-emacs On 12/31/1969 07:00 PM wrote: >>>> .... > > 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. > >.... ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-03-22 1:02 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-18 20:23 need obsolete arg in (read-from-minibuffer ...) ken 2011-03-18 20:37 ` Drew Adams 2011-03-18 22:12 ` ken 2011-03-18 23:03 ` Drew Adams 2011-03-19 2:22 ` ken 2011-03-19 2:34 ` Drew Adams [not found] ` <mailman.0.1300501334.15172.help-gnu-emacs@gnu.org> 2011-03-22 1:02 ` Stefan Monnier [not found] ` <mailman.23.1300486344.31996.help-gnu-emacs@gnu.org> 2011-03-19 1:59 ` Stefan Monnier 2011-03-19 5:23 ` ken 2011-03-19 5:51 ` need obsolete arg in (read-from-minibuffer ...) in Version 2.0 ken
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.