From: Stefan Monnier <monnier@iro.umontreal.ca>
To: landes@mailc.net
Cc: emacs-devel@gnu.org
Subject: Re: completing-read enhancement
Date: Mon, 17 Aug 2009 10:54:17 -0400 [thread overview]
Message-ID: <jwvzl9ycxhm.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <19080.30520.886412.850420@leaf.lop> (Paul Landes's message of "Sun, 16 Aug 2009 16:16:40 -0500")
>> > To the developer, it offers a quicker way of prompting the user purely
>> > based on a list of choices (either symbols or strings) and.
>> > It adds the following features:
>> > - accepts either symbols or string as input and converts between type
>> > automatically
>> > - returns user input as either a symbol or string
>> When/why are these useful?
> For the former: anytime you want a discrete set of branches in a
> function and don't want to convert using a lot of `intern' and
> `symbol-name' calls.
I figured this part ;-)
What I meant is: how often does this happen for you.
My impression is that it's not very frequent, but maybe you've seen
it at many different places.
>> As a convention in Emacs, we usually prefer to start with an empty
>> input (and rely on the "use default if the result is the empty
>> string"), so I don't think this is something we want to encourage.
> Is this a new convention?
No, not at all. It dates back to the introduction of the `def' argument
to completing-read.
> Seems I've run across many functions that
> allow it (including `completing-read').
We definitely allow and support it because it is occasionally good.
But we generally discourage its use.
> What's the alternative to when it's useful to start with text to edit
> rather than creating this text from scratch?
Usually we provide the value in `def' and let the user hit M-n if she
wants to edit the default.
> This is tangential, but I've actually recently looked for a GNU Emacs
> style guide but haven't found anything with the exception of the elisp
> manual. Is there one? If so, I'd like to read up on this (and other
> things concerning style).
There is no such style guide that I know. We have some coding
conventions in the Elisp manual, but it's about as far as it goes.
If someone wants to start adding a "UI style guide" section, we'd be
happy to install it.
>> As for "adding default", I don't find in the code where/how this is done,
>> could you explain what you mean by that?
> I meant adding the default parameter to the function.
I do not understand what you mean.
>> One problem with your function is that it has even more arguments than
>> completing-read (which already has too many).
> I agree, it has a lot of parameters that are passed to it, but no more
> that are required than `completing-read'. Only the first two are
> required and most use cases won't require more than three or maybe
> four.
The problem is not the length of the compulsory parameters, but the
overall length.
Stefan
next prev parent reply other threads:[~2009-08-17 14:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-11 3:01 completing-read enhancement Paul Landes
2009-08-11 15:12 ` Stefan Monnier
2009-08-12 1:57 ` Paul Landes
2009-08-16 5:04 ` Stefan Monnier
2009-08-16 21:16 ` Paul Landes
2009-08-17 14:54 ` Stefan Monnier [this message]
2009-08-20 0:24 ` Paul Landes
2009-09-10 5:13 ` Paul Landes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvzl9ycxhm.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=landes@mailc.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.