Re: completing-read enhancement

[Stefan Monnier]

>> > 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