Re: completing-read enhancement

[Paul Landes]

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
address@hidden