all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.