bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Dmitry Gutov
Subject: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files
Date: Thu, 1 Jun 2017 00:20:55 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0

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.





reply via email to

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