From: Paul Landes <landes@mailc.net>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: completing-read enhancement
Date: Wed, 19 Aug 2009 19:24:21 -0500 [thread overview]
Message-ID: <19084.38837.791353.558931@leaf.dmz.lop> (raw)
In-Reply-To: <jwvzl9ycxhm.fsf-monnier+emacs@gnu.org>
Stefan Monnier writes:
> >> 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.
I use it quite a bit as I do a lot of things with symbols instead of
strings. I also use the default prompt enhancement and prefer the
user interface.
To be more specific in answering your question, I've used a lot in the
JDEE (Java development under emacs) in a large code base I'm
integrating into the project.
> >> 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.
Ah, OK.
> > 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.
It does seem the use cases for it are fewer than the use cases
starting with empty input. I also am a big fan of default input and
prefer that when possible.
> > 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.
Good to know. Is this in every function that gets input from the
minibuffer (or whatever the technical name is of the area, I forgot).
> > 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.
I might start something on the side like what you have here to a
document for myself and the JDEE project. Perhaps when I have some
weight to it, I'll submit 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.
It is the seventh argument to the function of discussion
(`read-completing-choice').
> >> 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.
Yes, I agree. Would it make sense to use CL style arguments?
Something like:
(read-completing-choice "Class" choices
:default default-input
:add-prompt-p t)
This would mean modifying my own code, but it is something I could
write something to programatically fix.
--
Paul Landes
landes@mailc.net
next prev parent reply other threads:[~2009-08-20 0:24 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
2009-08-20 0:24 ` Paul Landes [this message]
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=19084.38837.791353.558931@leaf.dmz.lop \
--to=landes@mailc.net \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.