[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ryan Thompson
Subject: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files
Date: Tue, 06 Jun 2017 00:06:44 +0000

On Mon, Jun 5, 2017 at 7:01 PM Dmitry Gutov <address@hidden> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]