Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

From: Ryan Thompson <[email-masked]>
Date: Tue, 06 Jun 2017 00:06:44 +0000

On Mon, Jun 5, 2017 at 7:01 PM Dmitry Gutov <[email-masked]> wrote:

> Does it work well in the "don't want any default" case?
>

It does the same thing as completing-read-default, which is that it allows
you to enter an empty string by pressing RET and assumes that the calling
function is expecting that to happen. In particular, this means that any
code that wrongly assumed that setting REQUIRE-MATCH would guarantee
returning an element of COLLECTION is now equally broken in both standard
completion and ido completion, as opposed to being spuriously "fixed" by
ido ignoring the spec of completing-read.

'prepend-empty-string' sounds like what I'd expect;
> 'append-empty-string' doesn't sounds particularly useful (what's the
> goal here?); 'Any other value' kind of looks like over-engineering.
>

I wasn't sure if any of those made sense other than prepend-empty-string
and nil, but they were 2 lines of code each, and I can remove them later (I
haven't made a release for this yet). The idea behind append-empty-string
was that you might to make it possible to return the empty string even
though REQUIRE-MATCH is non-nil, but you don't want it to be the default.
The function thing was just "I dunno, maybe someone needs someone else."
I'll probably remove them if I don't find a use for them. They're not used
at the moment.

Anyway, I'm finding it to work pretty well without requiring a distinction
between commands that do or do not expect the empty string. I merged that
branch into my bleeding-edge branch and fixed a bunch of bugs, and I'm
going to test it for a while before releasing.