From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files Date: Wed, 31 May 2017 07:51:47 -0700 (PDT) Message-ID: <820b1931-918c-48c2-aca5-ed1d62d9c09a@default> References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="__1496242309564140232abhmp0012.oracle.com" X-Trace: blaine.gmane.org 1496242411 7011 195.159.176.226 (31 May 2017 14:53:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 May 2017 14:53:31 +0000 (UTC) To: Ryan Thompson , 27158@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 31 16:53:26 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG500-0001SO-F1 for geb-bug-gnu-emacs@m.gmane.org; Wed, 31 May 2017 16:53:24 +0200 Original-Received: from localhost ([::1]:59995 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dG505-0006xn-Rv for geb-bug-gnu-emacs@m.gmane.org; Wed, 31 May 2017 10:53:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dG4zi-0006mZ-Dn for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 10:53:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dG4ze-0007z6-F3 for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 10:53:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44877) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dG4ze-0007z2-AU for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 10:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dG4ze-00032L-4A for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 10:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 31 May 2017 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27158 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27158-submit@debbugs.gnu.org id=B27158.149624232411599 (code B ref 27158); Wed, 31 May 2017 14:53:02 +0000 Original-Received: (at 27158) by debbugs.gnu.org; 31 May 2017 14:52:04 +0000 Original-Received: from localhost ([127.0.0.1]:47553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG4yh-00030w-Jp for submit@debbugs.gnu.org; Wed, 31 May 2017 10:52:04 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43195) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG4yd-0002zv-CJ for 27158@debbugs.gnu.org; Wed, 31 May 2017 10:52:02 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4VEpqLo004925 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 May 2017 14:51:52 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v4VEpqwr024493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 May 2017 14:51:52 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4VEpnMe029285; Wed, 31 May 2017 14:51:51 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133089 Archived-At: --__1496242309564140232abhmp0012.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "" is just the default default, if you like (or not). =C2=A0 Thanks, that's actually a good way to think about it. =C2=A0 Would you make a default arg be mandatory instead of optional? Is that it?=C2=A0 If not, what default default would you propose? What should be returned if no explicit default is provided and the user hits RET with no input? =C2=A0 Thinking some more about it, I guess one solution would be to give REQUIRE-= MATCH could gain a special 3rd value, such as `force', which would mandate = that the returned value is a valid completion. (Not sure what should happen= in this case if DEF is provided and is not a valid completion.) =C2=A0 Today, `force' (or `abc', for that matter) does not exit IF at least some c= ompletion is performed. What you are requesting is, I guess, that it not ex= it even if no completion is performed - that it would be able to exit only = if one of the candidates is chosen. =C2=A0 That would be backward-incompatible, since today the symbol `force' means t= he same as any other non-nil, non-t REQUIRE-MATCH value. Not the end of the= world, but one consideration. =C2=A0 Today, you can just test the "" return value and re-issue the `completing-r= ead'. Do that in a loop in and you have the behavior you want, no? =C2=A0 The problem comes when implementing a completion system that returns the fi= rst available completion when pressiong RET (e.g. ido and ivy). In the case= of an empty input, RET causes these completion systems to return the first= element of COLLECTION if no default was specified.=20 =C2=A0 I think you are saying that those systems want/need to behave that way, but= `completing-read' does not behave that way out of the box? But you can mak= e calls to `completing-read' always behave that way, right (see above)? =C2=A0 Sometimes this is correct, but sometimes this is wrong, as in the following= usage pattern: =C2=A0 (defun pick-a-fruit () =C2=A0 (interactive) =C2=A0 (let* ((default "banana") =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (prompt =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (format "Pick a frui= t (default %s): " default)) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (collection '("apple" "ban= ana" "cherry")) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (selection =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (completing-read pro= mpt collection nil t))) =C2=A0=C2=A0=C2=A0 (when (string=3D selection "") =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (setq selection default)) =C2=A0=C2=A0=C2=A0 (message "You selected %s" selection))) =C2=A0 I don't follow. What is the behavior that you want? The above seems to be f= ine, as would be to repeatedly calli `completing-read' until the user enter= ed something (that completes). Which behavior do you want? =C2=A0 This pattern is used in e.g. Info-follow-reference. The problem is that the= re's no way for the completion function to know whether it's being used in = this way or not, so if the user presses RET on an empty input and the defau= lt wasn't provied to completing-read, it doesn't know whether it should ret= urn the empty string or the first match.=20 =C2=A0 Do you want your completion system to obey the (outside) call to `completin= g-read' or to do its own thing of returning the first candidate on empty in= put? =C2=A0 It sounds like you have a system that wants to have an alternative completi= on behavior from what some of the possible behaviors `completing-read' prov= ides, but you also want it to (sometimes?) respect the behavior that `compl= eting-read' provides. =C2=A0 And you cannot tell when you want this and when you want that, that is, whe= n the behavior specified by the (outside) code should be respected and when= the usual behavior of your completion should be imposed instead. =C2=A0 Is that it? If so, that doesn't sound like a problem with `completing-read'= . And I don't see how letting REQUIRE-MATCH =3D `force' would change anythi= ng. IIUC, you don't have control over (outside) calls to `completing-read',= so you cannot change them to use `force' or whatever. =C2=A0 For an example where returning the first match seems like the more correct = behavior, see read-char-by-name, which throws an error on the empty string.= =20 =C2=A0 (So does `Info-follow-reference', BTW: "No reference was specified".) =C2=A0 Raising an error on empty input is not the same thing as forcing input to b= e non-empty. Today it is easy to test for empty input (and so throw an erro= r), thanks to the default default behavior of returning "". =C2=A0 This ambiguity makes it difficult to reconcile the desired convenience feat= ure of "return the first match on RET" with the documented completing-read = behavior of "return the empty string on empty input + RET" without breaking= some functions.=20 =C2=A0 But your chosen convenience itself apparently gets in the way when you want= to respect an (outside) call to `completing-read' that expects a different= behavior, no? =C2=A0 This doesn't sound like a problem with `completing-read'. It sounds like a = problem reconciling a one-size-fits-all convenient completion behavior (ret= urn the first candidate if no input) with (outside) code that might expect = a different behavior for empty input. =C2=A0 And it's not even possible to implement an automatic fallback to completing= -read-default, because there's no way for the completion function to know w= hether the caller is expecting that behavior (Info-follow-reference) or is = expecting it not to happen (read-char-by-name).=20 =C2=A0 Isn't that the real problem you're having: that there is no way to know whe= n to respect the caller and when to impose a different completion behavior?= How can changing `completing-read' help solve that problem? =C2=A0 Ultimately, that's the issue: if completing-read is called with a DEF being= nil, the calling code may or may not be expecting it to return the empty s= tring, =C2=A0 It's normal for different calling code to expect different such behavior, n= o? And you are trying to accommodate those different expectations (at least= sometimes?), instead of overriding them, no? =C2=A0 and while not expecting the empty string might represent a bug in the calle= r,=20 =C2=A0 Why suppose that? Sure, it's possible, but it's more likely that that's the= desired behavior. When trying to accommodate outside code, you might need = to put on its rose-colored glasses, not only the rose-colored glasses of yo= ur completion system. ;-) =C2=A0 the existence of such functions makes it difficult to implement ido-style c= ompletion that does the right thing in all cases. =C2=A0 Can you give a concrete example, describing the intended behavior by the ou= tside caller, your intended behavior, and the problem you have in achieving= either one? =C2=A0 Going back to your statement that "empty string is just the default default= ", it's possible that one might get reasonable behavior for ido and ivy by = taking this statement literally and prepending "" to the list of completion= s when DEF is nil.=20 =C2=A0 Does that do what you want? =C2=A0 By "reasonable" I mean correct behavior in all of the cases that completing= -read-default is correct, and bug-for-bug compatibility in functions that d= on't expect completing-read to return "". I'll try that out and see how it = works. =C2=A0 Thanks for the insights. I guess you can close this. =C2=A0 No reason to be hasty in closing it. Better for us all to understand just w= hat the problem is. So far, I admit that I don't, so I can't say much that = is helpful here. --__1496242309564140232abhmp0012.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

"" is just t= he default default, if you like (or not).

<= p class=3DMsoNormal> 

Th= anks, that's actually a good way to think about it.

 

Would you make a default ar= g be mandatory instead of optional?
Is that it?  If not, what defau= lt default would you propose?
What should be returned if no explicit def= ault is provided and
the user hits RET with no input?

 

Thinking some more about it, I guess one solution would be to = give REQUIRE-MATCH could gain a special 3rd value, such as `force', which w= ould mandate that the returned value is a valid completion. (Not sure what = should happen in this case if DEF is provided and is not a valid completion= .)

 <= /p>

Today, `force' (or `abc', for that matt= er) does not exit IF at least some completion is performed. What you are re= questing is, I guess, that it not exit even if no completion is performed -= that it would be able to exit only if one of the candidates is chosen.

 =

That would be backward-incompatible, s= ince today the symbol `force' means the same as any other non-nil, non-t RE= QUIRE-MATCH value. Not the end of the world, but one consideration.

 

=

Today, you can just test the "" = return value and re-issue the `completing-read'. Do that in a loop in and y= ou have the behavior you want, no?

 

The probl= em comes when implementing a completion system that returns the first avail= able completion when pressiong RET (e.g. ido and ivy). In the case of an em= pty input, RET causes these completion systems to return the first element = of COLLECTION if no default was specified.

 

I think you are saying that those sy= stems want/need to behave that way, but `completing-read' does not b= ehave that way out of the box? But you can make calls to `completing-read' = always behave that way, right (see above)?

 

Some= times this is correct, but sometimes this is wrong, as in the following usa= ge pattern:

 

(defun pick-a-fruit ()
=
=C2=A0 (interactive)
=C2=A0 (let* ((default "<=
span class=3Dinbox-inbox-pl-s>banana")
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 (prompt
<= pre>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 (format "Pic= k a fruit (default %s): " default))
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 (collection '("apple&quo=
t; "banana" "c=
herry"))
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (selection
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (complet=
ing-read prompt collection nil t)))
=C2=A0=C2=A0=C2=
=A0 (when (string=3D selection "")
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 (setq selec=
tion default))
=C2=A0=C2=A0=C2=A0 (message "You selec=
ted %s" selection)))
 

I don't follow. What is the behavior that you want? The above = seems to be fine, as would be to repeatedly calli `completing-read' until t= he user entered something (that completes). Which behavior do you want?

&= nbsp;

This pattern is used in e.g. Inf= o-follow-reference. The problem is that there's no way for the completion f= unction to know whether it's being used in this way or not, so if the user = presses RET on an empty input and the default wasn't provied to completing-= read, it doesn't know whether it should return the empty string or the firs= t match.

 

Do you want your completion system to obey the (outside) call to `comp= leting-read' or to do its own thing of returning the first candidate on emp= ty input?

 =

It sounds like you have a= system that wants to have an alternative completion behavior from what som= e of the possible behaviors `completing-read' provides, but you also want i= t to (sometimes?) respect the behavior that `completing-read' provides.

 =

And you cannot tell when you want this= and when you want that, that is, when the behavior specified by the (outsi= de) code should be respected and when the usual behavior of your completion= should be imposed instead.

 

Is that= it? If so, that doesn't sound like a problem with `completing-read'. And I= don't see how letting REQUIRE-MATCH =3D `force' would change anything. IIU= C, you don't have control over (outside) calls to `completing-read', so you= cannot change them to use `force' or whatever.

 

For an example where returning the first match seems like the more correct= behavior, see read-char-by-name, which throws an error on the empty string= .

=  

(S= o does `Info-follow-reference', BTW: "No reference was specified"= .)

 <= /span>

Raising an error on empty input = is not the same thing as forcing input to be non-empty. Today it is easy to= test for empty input (and so throw an error), thanks to the default defaul= t behavior of returning "".

 

But your chosen convenience itself apparently gets= in the way when you want to respect an (outside) call to `completing-read'= that expects a different behavior, no?

 

This doesn't sound like a problem with `completing-read'. It sounds li= ke a problem reconciling a one-size-fits-all convenient completion behavior= (return the first candidate if no input) with (outside) code that might ex= pect a different behavior for empty input.

 

And = it's not even possible to implement an automatic fallback to completing-rea= d-default, because there's no way for the completion function to know wheth= er the caller is expecting that behavior (Info-follow-reference) or is expe= cting it not to happen (read-char-by-name). <= o:p>

 

Isn't that the real problem you're = having: that there is no way to know when to respect the caller and when to= impose a different completion behavior? How can changing `completing-read'= help solve that problem?

 

Ultimately, that's th= e issue: if completing-read is called with a DEF being nil, the calling cod= e may or may not be expecting it to return the empty string,

=  

It's normal for dif= ferent calling code to expect different such behavior, no? And you are tryi= ng to accommodate those different expectations (at least sometimes?), inste= ad of overriding them, no?

 

and while not expect= ing the empty string might represent a bug in the caller,

&n= bsp;

Why suppose that? Sur= e, it's possible, but it's more likely that that's the desired behavior. Wh= en trying to accommodate outside code, you might need to put on its = rose-colored glasses, not only the rose-colored glasses of your completion = system. ;-)

&nbs= p;

the existence of such functions mak= es it difficult to implement ido-style completion that does the right thing= in all cases.

 

Can you give a concrete exa= mple, describing the intended behavior by the outside caller, your intended= behavior, and the problem you have in achieving either one?

 

Going back to your statement that "empty string is ju= st the default default", it's possible that one might get reasonable b= ehavior for ido and ivy by taking this statement literally and prepending &= quot;" to the list of completions when DEF is nil.

&nbs= p;

Does that do what you w= ant?

 

By "reasonable" I mean correct b= ehavior in all of the cases that completing-read-default is correct, and bu= g-for-bug compatibility in functions that don't expect completing-read to r= eturn "". I'll try that out and see how it works.

<= /div>

 

Thanks for the insights. I guess you can close this.

 

No reason to be hasty in closing it. Better for us all = to understand just what the problem is. So far, I admit that I don't, so I = can't say much that is helpful here.

--__1496242309564140232abhmp0012.oracle.com--