GNU bug report logs - #27158
25.2; Eliminating old usage of completing-read from built-in files

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Drew Adams <drew.adams <at> oracle.com>, Ryan <rct <at> thompsonclan.org>, 27158 <at> debbugs.gnu.org
Subject: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files
Date: Thu, 1 Jun 2017 00:20:55 +0300

On 5/31/17 6:19 PM, Drew Adams wrote:

>>> Just because some callers might not need it does not mean that
>>> it is not useful for other callers.
>>
>> They can use the DEFAULT argument.
> 
> So are you arguing that DEFAULT should be a mandatory argument?
> I addressed that in my first message.

No, I don't (hence the "can", not "must"). I addressed that in my first 
message. Go ahead and give it a read.

>>>> Prohibit them from finishing completion, except through entering
>>>> a valid value, or pressing C-g.
>>>
>>> (while <no valid value> <get input with completion>)
>>>
>>> Is that hard?
>>
>> It makes completing-read-function calling convention
>> more complex for no real gain.
> 
> So you do think that it is hard?  Hard to believe.

You've rephrased and misstated the above statement (which is obviously 
true) into something you can disagree with. Go back and read it again.

> And how so, no real gain?  If there is no real gain for
> you then don't do it.

I'm talking about what the API allows to do. You counter that with "the 
callers can opt not to do that". That is a useless observation.

> You said you wanted to keep
> prompting and getting input as long as the user tried
> to exit with no input.  Now you are saying that doing
> that would e no real gain.  (?)

No, I'm saying something different. The API gives two different ways to 
specify the default value of "" (one explicit and one implicit). There 
is no benefit in it.

> But if an explicit DEFAULT arg is the solution then your
> completion system need only set arg DEFAULT to "" when
> it is nil, no?  Or set it to the first completion candidate
> when it is nil or "".  Or ... <whatever floats your boat>.

Let's take ido-completing-read as an example. It shows the available 
options in the minibuffer right away. There are two types of callers.

1. Ones that want to see "" as the default. They are served by the 
current completing-read calling convention, and they can use the calling 
convention where "" has to be specified explicitly in the DEFAULT 
argument. The only difficulty is the backward compatibility and updating 
the existing code that is still out there.

2. Ones that don't want to see "" returned, ever, because they don't 
know what to do with it. Your proposed solution is:

(while <no valid value> <get input with completion>)

How will that look to the user faced with ido-completing-read? Suppose 
that function is modified to behave most compatibly with 
completing-read, that is, adds "" to the collection and makes it first 
in the list (as the default value).

The user sees that "" at the beginning of the list, has to skip over it 
to choose a valid completion (two actions instead of one, which is 
especially a problem if the first real option is usually the one user 
will want to take), and if they choose "", nothing happens except they 
have to choose again, while "" still hovers annoyingly at the beginning 
of the list.

That's ridiculous.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.