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#27193: 25.2; tmm should use completing-read-default Date: Fri, 2 Jun 2017 14:25:42 -0700 (PDT) Message-ID: <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="__1496438744561258540abhmp0009.oracle.com" X-Trace: blaine.gmane.org 1496438786 19875 195.159.176.226 (2 Jun 2017 21:26:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Jun 2017 21:26:26 +0000 (UTC) To: Ryan Thompson , 27193@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 02 23:26:14 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 1dGu5F-0004bJ-Gz for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jun 2017 23:26:13 +0200 Original-Received: from localhost ([::1]:51512 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGu5K-0005lY-RX for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jun 2017 17:26:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGu5A-0005lO-PC for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 17:26:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGu55-0006cZ-Ld for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 17:26:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49307) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGu55-0006cN-Fa for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 17:26:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dGu54-0000uZ-IS for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 17:26:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Jun 2017 21:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27193 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 27193-submit@debbugs.gnu.org id=B27193.14964387603495 (code B ref 27193); Fri, 02 Jun 2017 21:26:02 +0000 Original-Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 21:26:00 +0000 Original-Received: from localhost ([127.0.0.1]:51984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGu50-0000uH-3r for submit@debbugs.gnu.org; Fri, 02 Jun 2017 17:25:59 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:16649) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGu4w-0000u2-SG for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 17:25:56 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v52LPlS2016284 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jun 2017 21:25:48 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v52LPlFH011332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Jun 2017 21:25:47 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v52LPioN031320; Fri, 2 Jun 2017 21:25:45 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: userv0022.oracle.com [156.151.31.74] 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:133177 Archived-At: --__1496438744561258540abhmp0009.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =C2=A0 I don't understand that argument.=C2=A0 (But to be clear, I don't really care much about `tmm'.) =C2=A0 Fair enough. My post certainly assumes quite a bit familiarity with tmm. I'= m happy to elaborate below. =C2=A0 I am familiar with tmm. I don't care much about it (or for it). I use HYPER= LINK "https://www.emacswiki.org/emacs/LaCarte"LaCarte instead. =C2=A0 I don't see that its use of `completing-read' is particularly exotic or problematic.=C2=A0 This is it: (completing-read ...) I don't see anything at all unusual about that. And the collection function, `tmm--completion-table', is likewise pretty ordinary, I think... You say: > tmm already pretty much relies on the assumption that > completing-read is actually calling completing-read-default. I don't see any evidence of that. =C2=A0 tmm's weirdness is not in the actual call to completing-read. That completi= ng-read call is wrapped by "(minibuffer-with-setup-hook #'tmm-add-prompt ..= .)", which in turn calls=C2=A0tmm-define-keys, which sets up a bunch of non= -standard key bindings, which have the effect of implementing a menu system= with single-keypress activation of menu items, rather than completion of a= substring with string matching.=20 =C2=A0 I could have added that to the list of things that I do not find extraordin= ary or problematic in general for `completing-read-function': the key bindi= ngs, the completion function, all of it. =C2=A0 The case that needs to be made for your proposal is really (IMO) that there= are NO values of `completing-read-function', apart from `completing-read-d= efault', which would be compatible with the tmm code. =C2=A0 I don't think you can make that case. I sense you are extrapolating from yo= ur own particular use of `completing-read-function' (and similar uses). =C2=A0 The result is not even recognizable as completing-read. =C2=A0 I don't think so. Certainly no more unrecognizable than Ido, which doesn't = use *Completions*, defines its own keys, etc. There is lots of room for dif= ferent uses of `completing-read', and some of those uses might not look muc= h like the behavior of `completing-read-default'. Nothing wrong with that, = in itself. =C2=A0 And whether a user might or might not realize that `completing-read' is bei= ng used is not relevant, IMO.=20 =C2=A0 And your proposed fix is simply to impose `completing-read-default', which = hardly supports your argument that tmm provides some kind of anomalous, non= -completing-read `completing-read'. `completing-read-default' is the canoni= cal `completing-read' behavior, if there ever was one. And that's the behav= ior that tmm provides by default. =C2=A0 The use of completing-read is merely an implementation detail =C2=A0 How so? Please think about providing a different implementation of tmm, whi= ch doesn't use `completing-read'. That will let us know whether `completing= -read' is used only as an implementation detail. =C2=A0 in a system that is *not* actually doing completion of any kind.=20 =C2=A0 Of course it does completion.=C2=A0 Erase chars in the minibuffer from the = right and then hit TAB - completion. It's not a completion to write home ab= out, but it's completion. =C2=A0 So pluggable completion backends don't make any sense for tmm,=20 =C2=A0 That too sounds overly broad. I think that you have too readily convinced y= ourself that this and that don't make any possible sense, and you are prone= to nail things down to prevent what you see as the nonsensical. If such we= re truly nonsensical then they would likely never exist, and there would be= no reason to forbid them. =C2=A0 I sense that you think of "pluggable completion backends", that is, uses of= `completing-read-function', as necessarily something similar to what your = code does. =C2=A0 [FWIW I don't think of `completing-read-function' as providing only a "plug= gable completion backend". Do you think of `isearch-search-fun-function' as= a "pluggable search backend"? Backend? frontend? There are many angles to = something like completion or search or... There is not just a backend and a= frontend. Likewise, what you call an "alternative completion system". =C2=A0 Really, we're just talking about a completion function - a value for `compl= eting-read-function'. That has wide scope - there are few constraints on wh= at it must do. I don't see the justice in adding a constraint for tmm that = it cannot do anything except `completing-read-default'.] =C2=A0 and I can't imagine any other value of completing-read-function that would = make sense for tmm besides completing-read-default.=20 =C2=A0 All you need to imagine is something similar to `completing-read-default' b= ut slightly different in some respect. That's all you need to imagine, but = nothing prevents more imagination. =C2=A0 And what you or I can imagine is not really the point. The question is whet= her tmm.el must limit itself to `completing-read-default'. I don't see why = it should, just because we know of some values of `completing-read-function= ' that don't do the right thing for tmm. =C2=A0 Looking at the "git blame" output for tmm, that call to completing-read has= definitely not been updated since completing-read-function was introduced = except for minor bugfixes,=20 =C2=A0 That's irrelevant. =C2=A0 so it makes sense that tmm would be expecting one and only one implementati= on of completing-read. =C2=A0 That does not follow at all. =C2=A0 This kind of argument could (inappropriately, IMO) be applied to any number of completely normal uses of `completing-read'. I see no reason to impose a dichotomy of either a `completing-read-function' similar to yours or else `completing-read-default'.=C2=A0 There are likely other benign values of the variable, besides just `completing-read-default'. =C2=A0 I'm not trying to set a general precedent here. tmm is the only code that I= 'm aware of that uses completing-read in this way. =C2=A0 I agree that it is not a common way of using it. It doesn't follow that the= only possible value of `completing-read-function' that is compatible with = tmm is `completing-read-default'. Not at all. =C2=A0 It sounds like (and no, I haven't looked into it; it just sounds like it) you have some particular `completing-read-function' values in mind, which you have found are incompatible with tmm's use of `completing-read'. =C2=A0 The alternative completing-read-function providers that I am aware of are o= f are ido-ubiquitous (written by me), ivy, and helm. I'll also include icic= les, even though uses some other mechanism besides modifying completing-rea= d-function. ido-ubiquitous and ivy both have code to deactivate themselves = when completing-read is called by tmm because otherwise their completion sy= stems would break it, while icicles and helm simply break tmm when enabled.= Thus, to my knowledge there is currently no other completing-read-function= that doesn't break tmm (except for those that make exceptions specifically= for tmm). =C2=A0 Again, it is irrelevant that there are uses of `completing-read-function' t= hat break tmm. And what you or I am aware of, or even what might exist anyw= here today, does not define the scope of possibilities. =C2=A0 [I drink values of the variable `liquid'. Some values, such as strong sulfu= ric acid, are quite incompatible with my proper functioning. That doesn't m= ean that the only possible value or the only compatible value for me is the= default value, `water'. =C2=A0 I drink blindly - I don't know what's in the glass. The only requirement my= mouth imposes is that the variable value be a liquid. It is up to whoever = fills my glass to DTRT.] =C2=A0 And if those uses of `completing-read-function' are incompatible with tmm, = and they thus deactivate themselves for tmm commands, that is exactly the r= ight approach, IMO. It is exactly that which I suggested to you (without kn= owing that that is what you already do). =C2=A0 [Tmm does work with Icicles, BTW. (But Icicles does not use `completing-rea= d-function', among other reasons because it wants to work also with older E= macs versions.)] =C2=A0 If so, that's not an argument for preventing the use of other values of `completing-read-function' with tmm. (Clearly the value `completing-read-default' is fine, for instance.)=C2=A0 That's not an argument for tmm to do something to prevent all use of `completing-read-function'. Instead, it's an argument for the code that defines and uses a particular `completing-read-function' to take care of the contexts where it makes sense, and to stop itself from being used in other contexts, where it might cause trouble. Only that code knows the kinds of context where its own `completing-read-function' makes sense and where it does not.=C2=A0 Code such as tmm should not try to guess what kinds of trouble different values of `completing-read-function' might cause. I don't think tmm should throw up its hands and say, "Gee, there might be some values of `completing-read-function' that are troublesome, so let's just prevent all use of that variable."=C2=A0 That doesn't make sense, to me. =C2=A0 Based on my explanation above, that is precisely what I think tmm should do= : avoid using completing-read-function entirely. =C2=A0 I know you think that, but I don't see why. There are surely values of `com= pleting-read-function' that do not bother tmm. We know of one already: `com= pleting-read-default'. Why would you suppose that there can be no others? =C2=A0 To look at it another way, tmm was originally written to use completing-rea= d as an implementation detail, and later the function that used to be calle= d completing-read was renamed to completing-read-default, but tmm was never= updated to use the new name. This patch rectifies that. =C2=A0 That's completely imagination. `completing-read-default' is not the new nam= e of what was once `completing-read'. `completing-read' has never used code= like `completing-read-default'. (It has always been written in C.) =C2=A0 What I would say that perhaps you will think goes a bit in your direction i= s this: If you can rewrite `tmm.el' so that it has the same behavior withou= t using `completing-read', and the code is at least as simple and easy to m= aintain, then I'd say go ahead and do that. =C2=A0 That would support your idea that `completing-read' is only an implementati= on detail etc., and the question of `completing-read-function' would become= moot. =C2=A0 If you want additional suggestions, maybe describe just what the problem is that your completion function causes for tmm.=C2=A0 It's hard to offer suggestions if you only state that it is incompatible, without going into any detail.=C2=A0 (Not that you must ask for input about this. But if you would like some then giving more detail might help.) Please use your own judgment (as I said, I don't really care much about `tmm'), but a priori this sounds like overkill. It sounds a bit like trying to bend Emacs to fit your `completing-read-function'.=C2=A0 I can understand such a motivation, believe me; I don't ascribe a bad intention to you.=C2=A0 A guess is that you are not sure what to do, to prevent inappropriate application of your value of `completing-read-function' in this or that context. If you think it causes trouble in some contexts, or it is not able to handle some contexts properly, then I'd suggest you consider walling it off from those use cases.=C2=A0 It might take some time to discover which contexts it causes trouble for, but that's OK - you could add them as you discover them.=C2=A0 Tmm sounds like a start.=C2=A0 The right approach, IMO, is to teach your code when to use its `completing-read-function' and when not to use it.=C2=A0 Put differently, consider teaching your `completing-read-function' when and where to hold back and just punt to the default behavior. =C2=A0 This is exactly how ido-ubiquitous and ivy both currently work: they essent= ially have a blacklist of callers for which they revert to standard complet= ion. tmm is on the blacklist for both packages.=20 =C2=A0 That's great. Problem solved. That's the right approach, IMO. =C2=A0 Certainly, for any alternative completion system=20 =C2=A0 Any? Again with the superlatives. There is more to the world... =C2=A0 there will be cases where it needs to fall back to standard completion. In = my view, the completion system should be able to determine purely based on = the calling context (i.e. its arguments and any relevant dynamically-bound = variables) whether or not it needs to punt. Making this decision based on t= he name of the caller instead of the context to make this decision is admit= ting that not enough context was provided. I view it as a workaround, not a= desirable design pattern, and someday in the future I hope to be able to r= emove the blacklist from ido-ubiquitous. =C2=A0 In the case of tmm, the best heuristic I can think of would be to inspect t= he key bindings of all the letters and numbers. If any of them are locally = rebound in the minibuffer to something other than self-insert-command, then= punt.=20 =C2=A0 That would be silly, IMHO. There can be plenty of uses of `completing-read'= where letter or number keys are bound to commands other than `self-insert-= command'. =C2=A0 [FWIW, though not directly relevant, when Icicle mode is on there are no ke= ys bound to `self-insert-command' in any of the minibuffer completion keyma= ps. (But there are keys bound to `icicle-self-insert'.)] =C2=A0 However, this doesn't work in practice because the bindings happen in minib= uffer-setup-hook, so putting a check at the front of this hook is too early= , and putting it at the end is too late because (in the case of ido-ubiquit= ous) an error is triggered before reaching the end of the hook. This was pa= rtly my motivation for suggesting the change in tmm rather than working aro= und it in ido-ubiquitous: because the blacklist approach is the only way fo= r ido-ubiquitous to fix it. =C2=A0 It sounds like it is already doing things the right way. (And yes, it might= mean a slight maintenance chore for you if libraries such as tmm change si= gnificantly.) =C2=A0 It's obvious that it is possible for someone to create a `completing-read-function' that causes trouble here or there.=C2=A0 But such trouble is up to the causer to fix or tame. =C2=A0 For the reasons described above, I would be very surprised if there was *an= y* alternative completion system that didn't break tmm. =C2=A0 Just pick a value of `completing-read-function' that is only slightly diffe= rent from `completing-read-default', to convince yourself otherwise. =C2=A0 I really think you have your particular use case too much in mind, here. `c= ompleting-read-function' =C2=A0just means something that uses the same argu= ments as `completing-read-default' and does something somewhat similar. Its= marching orders are pretty general. =C2=A0 The approach of preventing code like `tmm.el' from letting other code use `completing-read-function' does not look like it heads in the right direction.=C2=A0 But mine is just one opinion.=C2=A0 I ask only that you think some more about this. =C2=A0 As mentioned above, tmm is the only code I'm aware of that does anything li= ke this, and I don't see this as a general approach to be applied anywhere = else.=C2=A0 =C2=A0 OK, that's reassuring. =C2=A0 Hopefully the above clarifies my rationale in proposing this change. =C2=A0 Thanks for clarifying. I hope my comments above clarify my point of view al= so, and I hope they help. --__1496438744561258540abhmp0009.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

 

I don't understand that argument.&nb= sp; (But to be clear, I don't
really care much about `tmm'.)<= /p>

 

<= p class=3DMsoNormal>Fair enough. My post certainly assumes quite a bit fami= liarity with tmm. I'm happy to elaborate below.

 

I am familiar with tmm. I don't care much about it (or for it)= . I use LaCarte ins= tead.

 

I don't see that
its use of `completing-read' is particularly e= xotic or
problematic.  This is it: (completing-read ...)
I don't = see anything at all unusual about that.
And the collection function, `tm= m--completion-table',
is likewise pretty ordinary, I think...

You say:
> tmm already pretty much = relies on the assumption that
> completing-read is actually calling c= ompleting-read-default.
I don't see any evidence of that.

=

 

tmm's weirdness is not in the actual call to completing-re= ad. That completing-read call is wrapped by "(minibuffer-with-setup-ho= ok #'tmm-add-prompt ...)", which in turn calls tmm-define-keys, w= hich sets up a bunch of non-standard key bindings, which have the effect of= implementing a menu system with single-keypress activation of menu items, = rather than completion of a substring with string matching.

=  

I could have added = that to the list of things that I do not find extraordinary or problematic = in general for `completing-read-function': the key bindings, the completion= function, all of it.

 

The case that= needs to be made for your proposal is really (IMO) that there are NO values of `completing-read-function', apart from `completing-read-default= ', which would be compatible with the tmm code.

 

I don't think you can make that case. I sense you are extrapol= ating from your own particular use of `completing-read-function' (and simil= ar uses).

 =

The result is not even recognizable a= s completing-read.

 

I don't think so. Certainly no more unrecognizable than Ido, = which doesn't use *Completions*, defines its own keys, etc. There is lots o= f room for different uses of `completing-read', and some of those uses migh= t not look much like the behavior of `completing-read-default'. Nothing wro= ng with that, in itself.

 

And whethe= r a user might or might not realize that `completing-read' is being = used is not relevant, IMO.

 

And you= r proposed fix is simply to impose `completing-read-default', which hardly = supports your argument that tmm provides some kind of anomalous, non-comple= ting-read `completing-read'. `completing-read-default' is the canonical `co= mpleting-read' behavior, if there ever was one. And that's the behavior tha= t tmm provides by default.

 

The use of completin= g-read is merely an implementation detail

 =

How so? Please think about providing a= different implementation of tmm, which doesn't use `completing-read'. That= will let us know whether `completing-read' is used only as an implementati= on detail.

 = ;

in a system that is *not* actually = doing completion of any kind.

 

Of course it does completion.=C2=A0 Erase chars i= n the minibuffer from the right and then hit TAB - completion. It's not a c= ompletion to write home about, but it's completion.

 

So pluggable completion backends don't make any sense for tmm,

 

That too so= unds overly broad. I think that you have too readily convinced yourself tha= t this and that don't make any possible sense, and you are prone to = nail things down to prevent what you see as the nonsensical. If such were t= ruly nonsensical then they would likely never exist, and there would be no = reason to forbid them.

I sense that= you think of "pluggable completion backends", that is, uses of `= completing-read-function', as necessarily something similar to what your co= de does.

 <= /o:p>

[FWIW I don't think of `co= mpleting-read-function' as providing only a "pluggable completion back= end". Do you think of `isearch-search-fun-function' as a "pluggab= le search backend"? Backend? frontend? There are many angles to someth= ing like completion or search or... There is not just a backend and a front= end. Likewise, what you call an "alternative completion system".<= o:p>

 

Really, we're just talking about a = completion function - a value for `completing-read-function'. That has wide= scope - there are few constraints on what it must do. I don't see t= he justice in adding a constraint for tmm that it cannot do anything except= `completing-read-default'.]

 

and I can't imagin= e any other value of completing-read-function that would make sense for tmm= besides completing-read-default. =

 

All you need to imagine is something similar = to `completing-read-default' but slightly different in some respect. That's= all you need to imagine, but nothing prevents more imagination.

 =

And what you or I can imagine is not r= eally the point. The question is whether tmm.el must limit itself to `compl= eting-read-default'. I don't see why it should, just because we know of som= e values of `completing-read-function' that don't do the right thing for tm= m.

 <= /span>

Looking at the "git blame" output = for tmm, that call to completing-read has definitely not been updated since= completing-read-function was introduced except for minor bugfixes,

 

That's irre= levant.

 

so it makes sense that tmm would be exp= ecting one and only one implementation of completing-read.

&n= bsp;

That does not follow = at all.

 

This kind of argument could (inappropriately, IMO) beapplied to any number of completely normal uses of
`completing-read'.
I see no reason to impose a dichotomy of either a
`completing-read= -function' similar to yours or else
`completing-read-default'.  The= re are likely other
benign values of the variable, besides just
`comp= leting-read-default'.

=  

I'm not trying to set = a general precedent here. tmm is the only code that I'm aware of that uses = completing-read in this way.

 

I agree that = it is not a common way of using it. It doesn't follow that the only possibl= e value of `completing-read-function' that is compatible with tmm is `compl= eting-read-default'. Not at all.

 

It sounds like (and no, I haven't loo= ked into it;
it just sounds like it) you have some particular
`comple= ting-read-function' values in mind, which
you have found are incompatibl= e with tmm's use of
`completing-read'.

<= p class=3DMsoNormal> 

Th= e alternative completing-read-function providers that I am aware of are of = are ido-ubiquitous (written by me), ivy, and helm. I'll also include icicle= s, even though uses some other mechanism besides modifying completing-read-= function. ido-ubiquitous and ivy both have code to deactivate themselves wh= en completing-read is called by tmm because otherwise their completion syst= ems would break it, while icicles and helm simply break tmm when enabled. T= hus, to my knowledge there is currently no other completing-read-function t= hat doesn't break tmm (except for those that make exceptions specifically f= or tmm).

 

Again, it is irrelevant that ther= e are uses of `completing-read-function' that break tmm. And what you or I = am aware of, or even what might exist anywhere today, does not define the s= cope of possibilities.

[I drink val= ues of the variable `liquid'. Some values, such as strong sulfuric acid, ar= e quite incompatible with my proper functioning. That doesn't mean that the= only possible value or the only compatible value for me is t= he default value, `water'.

 

I drink = blindly - I don't know what's in the glass. The only requirement my mouth i= mposes is that the variable value be a liquid. It is up to whoever fills my= glass to DTRT.]

 

And if those uses = of `completing-read-function' are incompatible with tmm, and they thus deac= tivate themselves for tmm commands, that is exactly the right approa= ch, IMO. It is exactly that which I suggested to you (without knowing that = that is what you already do).

 

[Tmm = does work with Icicles, BTW. (But Icicles does not use `completing-read-fun= ction', among other reasons because it wants to work also with older Emacs = versions.)]

 = ;

If so, that's not an argument for preventing the use of
o= ther values of `completing-read-function' with tmm.
(Clearly the value `= completing-read-default' is fine,
for instance.)  That's not an arg= ument for tmm to do
something to prevent all use of `completing-read-fun= ction'.

Instead, it's an argument for the code that defines and
u= ses a particular `completing-read-function' to take
care of the contexts= where it makes sense, and to stop
itself from being used in other conte= xts, where it might
cause trouble.

Only that code knows the kinds= of context where its own
`completing-read-function' makes sense and whe= re it does
not.  Code such as tmm should not try to guess what kind= s
of trouble different values of `completing-read-function'
might cau= se.

I don't think tmm should throw up its hands and say, "Gee,<= br>there might be some values of `completing-read-function'
that are tro= ublesome, so let's just prevent all use of
that variable."&n= bsp; That doesn't make sense, to me.

 

Based o= n my explanation above, that is precisely what I think tmm should do: avoid= using completing-read-function entirely.

 =

I know you think that, but I don't see= why. There are surely values of `completing-read-function' that do not bot= her tmm. We know of one already: `completing-read-default'. Why would you s= uppose that there can be no others?

 

To l= ook at it another way, tmm was originally written to use completing-read as= an implementation detail, and later the function that used to be called co= mpleting-read was renamed to completing-read-default, but tmm was never upd= ated to use the new name. This patch rectifies that.

 

<= span style=3D'font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";colo= r:#244061'>That's completely imagination. `completing-read-default' is not = the new name of what was once `completing-read'. `completing-read' has neve= r used code like `completing-read-default'. (It has always been written in = C.)

 =

What I would say that perhaps y= ou will think goes a bit in your direction is this: If you can rewrite `tmm= .el' so that it has the same behavior without using `completing-read= ', and the code is at least as simple and easy to maintain, then I'd say go= ahead and do that.

 

That would su= pport your idea that `completing-read' is only an implementation detail etc= ., and the question of `completing-read-function' would become moot.

 

<= blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'>

If = you want additional suggestions, maybe describe just
what the problem is= that your completion function causes
for tmm.  It's hard to offer = suggestions if you only
state that it is incompatible, without going int= o any
detail.  (Not that you must ask for input about this.
But = if you would like some then giving more detail might
help.)

Pleas= e use your own judgment (as I said, I don't really
care much about `tmm'= ), but a priori this sounds like
overkill.

It sounds a bit like t= rying to bend Emacs to fit your
`completing-read-function'.  I can = understand such a
motivation, believe me; I don't ascribe a bad intentio= n
to you.  A guess is that you are not sure what to do,
to preve= nt inappropriate application of your value of
`completing-read-function'= in this or that context.

If you think it causes trouble in some con= texts, or it
is not able to handle some contexts properly, then
I'd s= uggest you consider walling it off from those use
cases.  It might = take some time to discover which
contexts it causes trouble for, but tha= t's OK - you
could add them as you discover them.  Tmm sounds like<= br>a start. 


The right approach, IMO, is = to teach your code when to
use its `completing-read-function' and when n= ot to use
it.  Put differently, consider teaching your
`completi= ng-read-function' when and where to hold back
and just punt to the defau= lt behavior.

&nbs= p;

This is exactly how ido-ubiquit= ous and ivy both currently work: they essentially have a blacklist of calle= rs for which they revert to standard completion. tmm is on the blacklist fo= r both packages.

 

That's great. Problem solved. That's the right approach, IMO.<= o:p>

 

Certainly, for any alternative completion syste= m

=  

An= y? Again with the superlatives. There is more to the world...

 

there will be cases where it needs to fall back to standard = completion. In my view, the completion system should be able to determine p= urely based on the calling context (i.e. its arguments and any relevant dyn= amically-bound variables) whether or not it needs to punt. Making this decision based on the name of the caller i= nstead of the context to make this decision is admitting that not enough co= ntext was provided. I view it as a workaround, not a desirable design patte= rn, and someday in the future I hope to be able to remove the blacklist fro= m ido-ubiquitous.

 =

In the case of tmm, the best heur= istic I can think of would be to inspect the key bindings of all the letter= s and numbers. If any of them are locally rebound in the minibuffer to some= thing other than self-insert-command, then punt.

 

That would be silly, IMHO. The= re can be plenty of uses of `completing-read' where letter or number keys a= re bound to commands other than `self-insert-command'.

 

[FWIW, though not directly relevant, when Icicle mode i= s on there are no keys bound to `self-insert-command' in any of the = minibuffer completion keymaps. (But there are keys bound to `icicle-self-in= sert'.)]

 <= /o:p>

However, this doesn't work in practice= because the bindings happen in minibuffer-setup-hook, so putting a check a= t the front of this hook is too early, and putting it at the end is too lat= e because (in the case of ido-ubiquitous) an error is triggered before reac= hing the end of the hook. This was partly my motivation for suggesting the = change in tmm rather than working around it in ido-ubiquitous: because the = blacklist approach is the only way for ido-ubiquitous to fix it.=

 

It sounds like it is already doing things the righ= t way. (And yes, it might mean a slight maintenance chore for you if librar= ies such as tmm change significantly.)

 

It's obvious that it is possible = for someone to create
a `completing-read-function' that causes trouble h= ere
or there.  But such trouble is up to the causer to fix
or ta= me.

 <= /p>

For the reasons described above, I would= be very surprised if there was *any* alternative completion system that di= dn't break tmm.

 <= /o:p>

Just pick a value of `comp= leting-read-function' that is only slightly different from `completing-read= -default', to convince yourself otherwise.

 

I really think you have your particular use case too much in mind, = here. `completing-read-function' =C2=A0just means something that uses the s= ame arguments as `completing-read-default' and does something somewhat simi= lar. Its marching orders are pretty general.

 

The approach of preventing = code like `tmm.el' from
letting other code use `completing-read-function= ' does
not look like it heads in the right direction.  But
mine = is just one opinion.  I ask only that you think
some more about thi= s.

 

As mentioned above, tmm is the only code = I'm aware of that does anything like this, and I don't see this as a genera= l approach to be applied anywhere else. 

 

OK, that's reassuring.

 

Hopefully the abo= ve clarifies my rationale in proposing this change.

 

<= span style=3D'font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";colo= r:#244061'>Thanks for clarifying. I hope my comments above clarify my point= of view also, and I hope they help.

--__1496438744561258540abhmp0009.oracle.com--