From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ryan Thompson Newsgroups: gmane.emacs.bugs Subject: bug#27193: 25.2; tmm should use completing-read-default Date: Fri, 02 Jun 2017 22:52:16 +0000 Message-ID: References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114928f4eb396205510201ee" X-Trace: blaine.gmane.org 1496443998 18987 195.159.176.226 (2 Jun 2017 22:53:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Jun 2017 22:53:18 +0000 (UTC) To: Drew Adams , 27193@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 03 00:53:13 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 1dGvRQ-0004Xl-EM for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Jun 2017 00:53:12 +0200 Original-Received: from localhost ([::1]:51718 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGvRU-0005k3-32 for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jun 2017 18:53:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGvRK-0005hO-8d for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 18:53:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGvRH-00030Z-0j for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 18:53:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49395) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGvRG-00030G-Qb for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 18:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dGvRG-0002us-HV for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 18:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ryan Thompson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Jun 2017 22:53: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.149644395711178 (code B ref 27193); Fri, 02 Jun 2017 22:53:02 +0000 Original-Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 22:52:37 +0000 Original-Received: from localhost ([127.0.0.1]:52072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGvQq-0002uD-4A for submit@debbugs.gnu.org; Fri, 02 Jun 2017 18:52:37 -0400 Original-Received: from mail-it0-f41.google.com ([209.85.214.41]:34516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGvQn-0002tz-D1 for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 18:52:34 -0400 Original-Received: by mail-it0-f41.google.com with SMTP id m47so6817474iti.1 for <27193@debbugs.gnu.org>; Fri, 02 Jun 2017 15:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thompsonclan-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2+c1phaG+7DLlbhcslO34MvRpQzR2fRnb5cpFG5lIM8=; b=hXfMGiSn3LpVMumHtgIlYut0Olp4wVgSB8L3zKzIz7OOM5NZDk7qxPXIUlke4zG8JS gHbLfa3XDEMTPb8AAahUZjC4uaLyVGvWWvAlAcAEwKUcL5AYxQjpVByvxToVi4eBXeni wZlElJoME+CqFtaQOPNmPoFaUzV/4IFxqpvwokypVTY1sH4RmSED8TV/MG0jCqhSO/jy iGJALcBsT9O9WjjyrN3p1U/yzADHVXgk3+FiEDqUXi2DRppZFJSH51+tSW6UQfE+j06a i22xz5mPCFv9h34cCPfNA5BKN/mGuN5/YpYh/yU4P8OHpzjAeVuNtr/xgbHJJLniiSBY 6G0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2+c1phaG+7DLlbhcslO34MvRpQzR2fRnb5cpFG5lIM8=; b=kvUyp/P2Iz76DtYWZ1TYFxnW7x8v5B9ymSxRvBtYZ9p0iAS/E9idAVcfpIWSn56o2K b4FqFY1GGlZmcBSq6okw4b562tX4OjrCVUOu0vv9PosBilGNNPo9kgHc72opd1tEBB8u swMcjGCdKSAvzfNFrCilccjfk0rB62iz7QlVr3kgOxfDcdN6UYo/kA/plc1U20JVQY6l aeCW59GFSHqqWsLrRNmhSq/P9BWLmg+DsQFe1dUCAYHvOs8MucCwDiyFh1jzSnfa24Ew 7lPmrVOrcyULIm2MtdxlPxNvztptjNKvTMoyNPRdM3DLlg5pjSP0SrQ3zAGoBVVCOEOq zeGQ== X-Gm-Message-State: AODbwcAOR88g+kbttFcis+/jSL80/R6Amerwo355APYqD/i0yZhFTzil FbZun9+8O4e0tFIBGApXI6VcEgNmx17Z X-Received: by 10.107.165.148 with SMTP id o142mr10435653ioe.179.1496443947524; Fri, 02 Jun 2017 15:52:27 -0700 (PDT) In-Reply-To: <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> 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:133185 Archived-At: --001a114928f4eb396205510201ee Content-Type: text/plain; charset="UTF-8" (Note: I think several more replies came in while I was writing this; I haven't read those yet.) Ok, so if I'm understanding correctly, the thrust of your argument is that completing-read is a very general function that supports a very wide range of behaviors/usages, to such a degree that tmm's usage does not seem like an anomalous or unusual way to use it. I might not agree on what constitutes a typical usage of completing-read, but I can definitely agree that it is a very general function, and in practice no alternative value of completing-read-function that works substantially differently from completing-read-default is likely to be capable of replicating all of that functionality. So given your recommendation that alternative completion functions should "punt" cases they can't handle back to completing-read-default, along with the high likelihood that every alternate completion system is going to have something that it can't handle and needs to punt on, would you be interested in a patch that implements that punting mechanism within completing-read itself, so that ido-ubiqutous, ivy, helm, and others don't all have to invent their own punting code? I'm thinking along the lines of wrapping the call to completing-read-function with a condition-case that catches a "completing-read-fallback" signal, and calls completing-read-default instead. So any completion system that wants to punt just has to throw the appropriate signal. Some replies to specific points, which may or may not be moot: > > 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 implementation detail. > Magit implements a very similar system of using single-key shortcuts to activate items from a textual menu, with multiple levels of menus. It doesn't use completing-read. Of course it does completion. Erase chars in the minibuffer from the right > and then hit TAB - completion. It's not a completion to write home about, > but it's completion. > I would say that the fact that tmm does completion on hitting TAB is an internal implementation detail leaking out, i.e. an unintended side-effect of the fact that it uses completing-read internally. The main functionality of tmm is single-key shortcut access to menu items, not completion of user-entered text with matching strings from a set of choices. > > So pluggable completion backends don't make any sense for tmm, > > > > That too sounds overly broad. I think that you have too readily convinced > yourself 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 were truly 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 code does. > I don't think I'm making a broad statement. My claim is that settings that affect how completion works should not affect tmm because tmm isn't doing completion (or rather, tmm is doing completion only incidentally due to a leaky abstraction). I still stand by this claim, regardless of whether tmm's use of completing-read is considered typical or not. (If you accept this claim, there's probably some other completion-related settings that tmm should also ignore.) [FWIW I don't think of `completing-read-function' as providing only a > "pluggable 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". > Well, I'm not sure exactly what to call it. I suppose "alternative values of completing-read-function" is more technically correct, but it's a real mouthful. 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 the justice in adding a constraint for > tmm that it cannot do anything except `completing-read-default'.] > > > > and I can't imagine 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.' > I was implicitly assuming that no one would bother to implement a new completion function from scratch unless it differed substantially from an existing one. > > And what you or I can imagine is not really the point. The question is > whether 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. > > > > 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 irrelevant. > > > > so it makes sense that tmm would be expecting one and only one > implementation of completing-read. > > > > That does not follow at all. > > > > 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'. There are likely other > benign values of the variable, besides just > `completing-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 possible value of `completing-read-function' that is compatible > with tmm is `completing-read-default'. Not at all. > > > > 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'. > > > > The 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 > icicles, even though uses some other mechanism besides modifying > completing-read-function. ido-ubiquitous and ivy both have code to > deactivate themselves when completing-read is called by tmm because > otherwise their completion systems 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). > > > > Again, it is irrelevant that there 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 scope of possibilities. > > > > [I drink values of the variable `liquid'. Some values, such as strong > sulfuric acid, are quite incompatible with my proper functioning. That > doesn't mean that the only *possible* value or the only *compatible* > value for me is the default value, `water'. > > > > 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.] > > > > And if those uses of `completing-read-function' are incompatible with tmm, > and they thus deactivate themselves for tmm commands, that is exactly the > *right* approach, 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-function', 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 > other values of `completing-read-function' with tmm. > (Clearly the value `completing-read-default' is fine, > for instance.) 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. 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." That doesn't make sense, to me. > > > > Based on 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 bother tmm. We know of one already: > `completing-read-default'. Why would you suppose that there can be *no* > others? > > > > To look 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 completing-read was renamed to completing-read-default, > but tmm was never updated to use the new name. This patch rectifies that. > > > > That's completely imagination. `completing-read-default' is not the new > name of what was once `completing-read'. `completing-read' has never used > code like `completing-read-default'. (It has always been written in C.) > > > > What I would say that perhaps you 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 support your idea that `completing-read' is only an > implementation detail etc., and the question of `completing-read-function' > would become moot. > I've provided Magit's popups as an example of similar functionality implemented without completing-read. I'm not a user of tmm, I just want to make sure my completion function doesn't break it. > > > 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 into any > detail. (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'. I can understand such a > motivation, believe me; I don't ascribe a bad intention > to you. 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. 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. Tmm sounds like > a start. > > > The right approach, IMO, is to teach your code when to > use its `completing-read-function' and when not to use > it. Put differently, consider teaching your > `completing-read-function' when and where to hold back > and just punt to the default behavior. > > > > This is exactly how ido-ubiquitous and ivy both currently work: they > essentially have a blacklist of callers for which they revert to standard > completion. tmm is on the blacklist for both packages. > > > > That's great. Problem solved. That's the right approach, IMO. > > > > Certainly, for any alternative completion system > > > > Any? 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 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 > the name of the caller instead of the context to make this decision is > admitting 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 remove the blacklist from ido-ubiquitous. > > In the case of tmm, the best heuristic I can think of would be to inspect > the 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. > > > > 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'. > > > > [FWIW, though not directly relevant, when Icicle mode is 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-insert'.)] > My heuristic was meant specifically for ido-ubiquitous: the heuristic is that if any letters or numbers are bound to something other than self-insert-command, the caller is probably doing something fancy that won't work well with ido completion. In any case, it was merely meant as one example of how a completion function might infer from context whether it should punt without having to identify callers by name. Anyway, regardless of whether this patch is accepted or not, ido-ubiquitous will still need a blacklist either way, since functions like read-file-name that are already covered by normal ido-mode will always be on that blacklist. So I'm not exactly submitting this patch to make my implementation easier. I just thought that having tmm ignore completing-read-function would make it less fragile and mean one less obstacle for anyone implementing a new complting-read-function. --001a114928f4eb396205510201ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Note: I think several more replies came in while I w= as writing this; I haven't read those yet.)

Ok, so = if I'm understanding correctly, the thrust of your argument is that com= pleting-read is a very general function that supports a very wide range of = behaviors/usages, to such a degree that tmm's usage does not seem like = an anomalous or unusual way to use it. I might not agree on what constitute= s a typical usage of completing-read, but I can definitely agree that it is= a very general function, and in practice no alternative value of completin= g-read-function that works substantially differently from completing-read-d= efault is likely to be capable of replicating all of that functionality.
So given your recommendation that alternative completion f= unctions should "punt" cases they can't handle back to comple= ting-read-default, along with the high likelihood that every alternate comp= letion system is going to have something that it can't handle and needs= to punt on, would you be interested in a patch that implements that puntin= g mechanism within completing-read itself, so that ido-ubiqutous, ivy, helm= , and others don't all have to invent their own punting code? I'm t= hinking along the lines of wrapping the call to completing-read-function wi= th a condition-case that catches a "completing-read-fallback" sig= nal, and calls completing-read-default instead. So any completion system th= at wants to punt just has to throw the appropriate signal.

Some replies to specific points, which may or may not be moot:

=

=C2= =A0

Please t= hink about providing a different implementation of tmm, which doesn't u= se `completing-read'. That will let us know whether `completing-read= 9; is used only as an implementation detail.


Magit implements a very si= milar system of using single-key shortcuts to activate items from a textual= menu, with multiple levels of menus. It doesn't use completing-read.

Of c= ourse it does completion.=C2=A0 Erase chars in the minibuffer from the righ= t and then hit TAB - completion. It's not a completion to write home ab= out, but it's completion.


I would say that the fact that tmm does completion on hitti= ng TAB is an internal implementation detail leaking out, i.e. an unintended= side-effect of the fact that it uses completing-read internally. The main = functionality of tmm is single-key shortcut access to menu items, not compl= etion of user-entered text with matching strings from a set of choices.
=C2=A0

=C2=A0

=

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

=C2=A0

=

That = too sounds overly broad. I think that you have too readily convinced yourse= lf 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 s= uch were truly nonsensical then they would likely never exist, and there wo= uld be no reason to forbid them.

=C2=A0

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

=C2=A0
<= div>I don't think I'm making a broad statement. My claim is that se= ttings that affect how completion works should not affect tmm because tmm i= sn't doing completion (or rather, tmm is doing completion only incident= ally due to a leaky abstraction). I still stand by this claim, regardless o= f whether tmm's use of completing-read is considered typical or not. (I= f you accept this claim, there's probably some other completion-related= settings that tmm should also ignore.)

[FWIW I don't think of `completing-read-funct= ion' as providing only a "pluggable completion backend". Do y= ou think of `isearch-search-fun-function' as a "pluggable search b= ackend"? Backend? frontend? There are many angles to something like co= mpletion or search or... There is not just a backend and a frontend. Likewi= se, what you call an "alternative completion system".
<= /p>


Well, I'm not sur= e exactly what to call it. I suppose "alternative values of completing= -read-function" is more technically correct, but it's a real mouth= ful.

<= u>=C2=A0Really, we're just talking a= bout a completion function - a value for `completing-read-function'. Th= at has wide scope - there are few constraints on what it must do. I don't see the justice = in adding a constraint for tmm that it cannot do anything except `completin= g-read-default'.]

=C2=A0

and I can't i= magine any other value of completing-read-function that would make sense fo= r tmm besides completing-read-default.

<= u>=C2=A0

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


=
I was implicitly assuming that no one would bother to implement a new = completion function from scratch unless it differed substantially from an e= xisting one.

=C2=A0

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 kno= w of some values of `completing-read-function' that don't do the ri= ght thing for tmm.

= =C2=A0

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

=C2=A0

=

That's irrelevant.

=
<= div>

=C2= =A0

so it makes sense that tmm woul= d be expecting one and only one implementation of completing-read.

=C2=A0

=

That does not follow at all.=

=C2=A0

This kind of argument could (inappr= opriately, IMO) be
applied to any number of completely normal uses of`completing-read'.

I see no reason to impose a dichotomy of eit= her a
`completing-read-function' similar to yours or else
`comple= ting-read-default'.=C2=A0 There are likely other
benign values of th= e 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 thi= s 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-functi= on' that is compatible with tmm is `completing-read-default'. Not a= t 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-func= tion' 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 a= re of are ido-ubiquitous (written by me), ivy, and helm. I'll also incl= ude icicles, even though uses some other mechanism besides modifying comple= ting-read-function. ido-ubiquitous and ivy both have code to deactivate the= mselves when completing-read is called by tmm because otherwise their compl= etion systems 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 ther= e are uses of `completing-read-function' that break tmm. And what you o= r I am aware of, or even what might exist anywhere today, does not define t= he scope of possibilities.

<= span style=3D"font-size:10.0pt;font-family:"Trebuchet MS","s= ans-serif";color:#244061">=C2=A0

[I drink values of the variable `= liquid'. Some values, such as strong sulfuric acid, are quite incompati= ble with my proper functioning. That doesn't mean that the only poss= ible value or the only compatible value for me is the default va= lue, `water'.

=C2=A0

I drink blindly - I don't know what= 9;s in the glass. The only requirement my mouth imposes is that the variabl= e 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 exa= ctly the right approach, IMO. It is exactly that which I suggested t= o you (without knowing that that is what you already do).

=C2=A0=

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

= =C2=A0

If so, that's not an argument for prevent= ing the use of
other values of `completing-read-function' with tmm.<= br>(Clearly the value `completing-read-default' is fine,
for instanc= e.)=C2=A0 That's not an argument for tmm to do
something to prevent = all use of `completing-read-function'.

Instead, it's an argu= ment for the code that defines and
uses a particular `completing-read-fu= nction' to take
care of the contexts where it makes sense, and to st= op
itself from being used in other contexts, where it might
cause tro= uble.

Only that code knows the kinds of context where its own
`co= mpleting-read-function' makes sense and where it does
not.=C2=A0 Cod= e such as tmm should not try to guess what kinds
of trouble different va= lues of `completing-read-function'
might cause.

I don't t= hink tmm should throw up its hands and say, "Gee,
there might be so= me values of `completing-read-function'
that are troublesome, so let= 's just prevent all use of
that variable."=C2=A0 That do= esn't make sense, to me.

=C2=A0

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

=C2=A0

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

=
=

=C2=A0

To look at it another way, tmm was originall= y written to use completing-read as an implementation detail, and later the= function that used to be called completing-read was renamed to completing-= read-default, but tmm was never updated to use the new name. This patch rec= tifies that.

=C2=A0

That's completely imagination. `completin= g-read-default' is not the new name of what was once `completing-read&#= 39;. `completing-read' has never used code like `completing-read-defaul= t'. (It has always been written in C.)

=C2=A0<= /p>

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

=C2=A0

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


=
I've provided Magit's popups as an example of similar function= ality implemented without completing-read. I'm not a user of tmm, I jus= t want to make sure my completion function doesn't break it.
= =C2=A0

<= /u>

=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, wi= thout going into any
detail.=C2=A0 (Not that you must ask for input abou= t 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
ca= re 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 d= on't ascribe a bad intention
to you.=C2=A0 A guess is that you are n= ot sure what to do,
to prevent inappropriate application of your value o= f
`completing-read-function' in this or that context.

If you = think it causes trouble in some contexts, or it
is not able to handle so= me contexts properly, then
I'd suggest you consider walling it off f= rom 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 a= s you discover them.=C2=A0 Tmm sounds like
a start.=C2=A0<= /p>


The right approach, IMO, is to teach your code when to<= br>use its `completing-read-function' and when not to use
it.=C2=A0 = Put differently, consider teaching your
`completing-read-function' w= hen and where to hold back
and just punt to the default behavior.=

=C2=A0

This is exactly how ido-ubiquitous and i= vy both currently work: they essentially have a blacklist of callers for wh= ich they revert to standard completion. tmm is on the blacklist for both pa= ckages.

=C2=A0

<= /div>
<= div>

That's = great. Problem solved. That's the right approach, IMO.

= =C2=A0

Certainly, for any alter= native completion system

=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 c= ompletion system should be able to determine purely based on the calling co= ntext (i.e. its arguments and any relevant dynamically-bound variables) whe= ther or not it needs to punt. Making t= his decision based on the name of the caller instead of the context to make= this decision is admitting 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 remove the blacklist from ido-ubiquitous.

=

In the case of tmm, the best heuristi= c I can think of would be to inspect the key bindings of all the letters an= d numbers. If any of them are locally rebound in the minibuffer to somethin= g other than self-insert-command, then punt. =

=C2=A0

That would be silly, IMHO. There can be plenty of = uses of `completing-read' where letter or number keys are bound to comm= ands other than `self-insert-command'.

=C2=A0<= /p>

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


My heuristic was= meant specifically for ido-ubiquitous: the heuristic is that if any letter= s or numbers are bound to something other than self-insert-command, the cal= ler is probably doing something fancy that won't work well with ido com= pletion. In any case, it was merely meant as one example of how a completio= n function might infer from context whether it should punt without having t= o identify callers by name.

Anyway, regardless of = whether this patch is accepted or not, ido-ubiquitous will still need a bla= cklist either way, since functions like=C2=A0read-file-name=C2=A0that are already covered by normal ido-mode=C2=A0will always be on t= hat blacklist. So I'm not exactly submitting= this patch to make my implementation easier. I just thought that having tm= m ignore completing-read-function would make it less fragile and mean one l= ess obstacle for anyone implementing a new complting-read-function.<= /div>
--001a114928f4eb396205510201ee--