From: Dmitry Gutov <dgutov@yandex.ru>
To: Drew Adams <drew.adams@oracle.com>, Ryan <rct@thompsonclan.org>,
27158@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 [thread overview]
Message-ID: <f9cf57c4-7b82-f00e-056f-79dd0a820da7@yandex.ru> (raw)
In-Reply-To: <3d3bc85b-31d3-4701-8acd-45591d075253@default>
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.
next prev parent reply other threads:[~2017-05-31 21:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-31 4:41 bug#27158: 25.2; Eliminating old usage of completing-read from built-in files Ryan
2017-05-31 5:52 ` Drew Adams
2017-05-31 11:45 ` Ryan Thompson
2017-05-31 14:51 ` Drew Adams
2017-05-31 12:23 ` Dmitry Gutov
2017-05-31 14:51 ` Drew Adams
2017-05-31 14:59 ` Dmitry Gutov
2017-05-31 15:19 ` Drew Adams
2017-05-31 15:44 ` Ryan Thompson
2017-05-31 22:41 ` Dmitry Gutov
2017-05-31 23:16 ` Drew Adams
2017-05-31 23:54 ` Dmitry Gutov
2017-06-01 2:23 ` Drew Adams
2017-06-01 9:27 ` Dmitry Gutov
2017-06-01 14:57 ` Drew Adams
2017-06-01 20:53 ` Dmitry Gutov
2017-06-01 21:04 ` Ryan Thompson
2017-06-05 23:01 ` Dmitry Gutov
2017-06-06 0:06 ` Ryan Thompson
2017-06-06 0:09 ` Dmitry Gutov
2017-05-31 21:20 ` Dmitry Gutov [this message]
2020-08-24 14:58 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f9cf57c4-7b82-f00e-056f-79dd0a820da7@yandex.ru \
--to=dgutov@yandex.ru \
--cc=27158@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=rct@thompsonclan.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).