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#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Date: Wed, 2 Jan 2019 08:20:51 -0800 (PST) Message-ID: <4f16869e-5f88-47bc-a118-5ea37cfb6d9a@default> References: <13f934bf-e79c-47cb-88a5-7ee58cdc9242@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1546446010 30830 195.159.176.226 (2 Jan 2019 16:20:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2019 16:20:10 +0000 (UTC) Cc: 33595@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 02 17:20:06 2019 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 1gejFU-0007qV-Ii for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Jan 2019 17:20:04 +0100 Original-Received: from localhost ([127.0.0.1]:45942 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gejHa-0005Ru-WA for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Jan 2019 11:22:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gejHS-0005Rh-I3 for bug-gnu-emacs@gnu.org; Wed, 02 Jan 2019 11:22:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gejHP-0000kL-48 for bug-gnu-emacs@gnu.org; Wed, 02 Jan 2019 11:22:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33305) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gejHO-0000jq-31 for bug-gnu-emacs@gnu.org; Wed, 02 Jan 2019 11:22:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gejHN-0002Fs-SA for bug-gnu-emacs@gnu.org; Wed, 02 Jan 2019 11:22:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Jan 2019 16:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33595 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33595-submit@debbugs.gnu.org id=B33595.15464460678598 (code B ref 33595); Wed, 02 Jan 2019 16:22:01 +0000 Original-Received: (at 33595) by debbugs.gnu.org; 2 Jan 2019 16:21:07 +0000 Original-Received: from localhost ([127.0.0.1]:44917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gejGV-0002Eb-6X for submit@debbugs.gnu.org; Wed, 02 Jan 2019 11:21:07 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:41504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gejGT-0002Dm-Q3 for 33595@debbugs.gnu.org; Wed, 02 Jan 2019 11:21:06 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x02GIlfc051560; Wed, 2 Jan 2019 16:20:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=XzPY5Nwups7QQRQdpPmuxOG5qrqakEnQ41kwo/W87Jk=; b=0AmIM7B50HvBSaRTT0dFCfIdc4tOUmDamCKwh8CdJjThqWlMsI95yJzIJ1fppzZIeNjm XvCawdru2cjrK4XUh1TpRUO7T4IMCtMzgKjngDs3xjyOd5v3Aptin6jaRRaNHXrnzo/A YT3oWjT4D5XxgCgJpZYvmXsezk9yDuOm4Rr18G/XtN5lgbQDVBLXtyh9cs1hC7DxqGfl HFF4x7krQZ2SASD6pcbjAXiK+Tblq2EDCIjre1LXIrbFDBZXLHIoAclL4FSHG/Z8L2aZ ZS6p4nxItAVI84nxdRjZB4l2qopT9vWq5PSsQhacIN5O39BrUJgsTqV9ZHRZgWb/vHVS rw== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2pp1jr2t1r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 02 Jan 2019 16:20:59 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x02GKrU0006641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Jan 2019 16:20:53 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x02GKqMw003383; Wed, 2 Jan 2019 16:20:53 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4783.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9124 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901020147 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:154091 Archived-At: > >> More concretely, do you expect a hook function places on this variable > >> to apply for "any completion table" or would it be specific to > >> a particular completion table? > > The former. At least I don't see how this has anything to > > do with what kind of completion is used or how it's done. >=20 > Not sure what you mean by "kind of completion" but a completion table > describes the "kind" of completion in the sense of describing the set of > possible completions (i.e. either a set of function names, or a set of > file names, or ...). >=20 > In your example, the hook function calls `describe-function` so it only > makes sense when the completion table is a set of function names, an > becomes absurd when it's a set of file names, or Git revisions, ... If that's what you meant by your question then yes, I think I answered that when I said that the person who writes the code that invokes `completing-read', say, is the person who adds a function to the hook, or binds the hook - or not (does not use the hook). What you put on the hook typically is specific to the completion candidates you provide, and to the command that uses the candidate the user chooses. If that's what you meant by "tightly linked to the completion table", then yes. But the hook does not change the completion table or change completion in any way. It's only about what a user does with a completion (the "UI" you mentioned?). > So in your example, your hook function is very tightly linked to the > completion table. I still don't understand this example well enough to > understand if/how it's linked to the UI (e.g. what should happen if the > user happens to use, say, ido-ubiquitous to complete his function names). Ido? Idon't. I don't know either. Try it, to see. ;-) > >> The example you give in `my-describe-function` gives me the impression > >> that those would inevitably be tightly linked to the completion table. > >> So instead of a hook variable, it would probably make more sense to ad= d > >> a new `completion-extra-properties` alongside to :exit-function. > > No, I don't think that's relevant. >=20 > What do you mean by "relevant"? It would require the code to be a bit > different but you could get the exact same behavior with it. It's not clear yet that you are clear about what this is about. But if you feel you are, and if you think there's a better way to provide such behavior to users, go for it. As I said, I don't use this myself. It's just something simple that I saw as possible, easy, and (I expect) likely to be of some (limited) use. If you want to close the bug, I won't cry. > >> PS: I'm not sure I completely understand the intended behavior of > >> `my-describe-function`, but I get the impression that for this > >> particular example, a maybe even better approach is to use > >> minibuffer-with-setup-hook to set a post-command-hook that calls > >> describe-function whenever the minibuffer names a valid function > >> (whether we get there via completion or plain typing, and regardle= ss > >> if it's the sole completion). > > > > No, that's something else. This is not about describing > > everything that shows up in the minibuffer. It's about > > a user asking to do something with a (full) completion - on > > demand. Something defined by the person who wrote the code > > calling for completion. Something specific for the command > > that is asking for user input, or at least for its candidates. >=20 > One part I don't fully understand is why this code wants to call > `describe-function` only and exactly when the user hits TAB and it > completes to an sole match. Why should the user not want to see that > same result when typing the name explicitly instead of completing to it? I never said a user could not want that. But there is a difference between typing something and knowing that it is one of a set of provided choices. Doing this only for a sole completion (which is what I'd recommend here) avoids having it kick in at a zillion places where a user likely doesn't want it. In my view of this it would be only on demand, and only when a user knows that what's in the minibuffer is a full completion (what Emacs calls completed and unique). That's the goal here. But feel free to design something different, for some different, but perhaps related, purpose. > Why should the user not want to see the same result when completing to > an exact-but-not-sole match? A user might. See above. Users can want all kinds of things. Different users, and the same user, can want different things at different times. This simple suggestion is not trying to do more than what I suggested. It's not trying to provide an extended eldoc or a partial Icicles/Helm or anything of the sort. The hook function can do pretty much anything with the completion, and it can ignore it. It's not limited to providing more info about the completion. This just lets a user, on demand, invoke an action (defined by whoever wrote the code invoking the input-reading function) on user input that has already been completed (the input is complete and unique). That's all. Really not a big deal. > Another thing I don't understand about your example is: what is the user > expected to do after hitting TAB (which completed to a sole match)? > The only thing left to do seems to be RET but that's redundant since > `describe-function` was already called. >=20 > > [To be clear about one thing: This is not at all for _me_, as > > it has no effect with my setup, which uses Icicles, which (1) > > completes and uses TAB differently and (2) has a different > > mechanism for optionally doing something when there is a sole > > completion. I just thought/think that this might be useful > > for some users (and it is simple).] >=20 > It's not as simple as it seems: if the user goes to some other buffer in > the middle of the completion, your completion-sole-match-functions will > not wreak havoc in unrelated completions. I don't know what you mean. Maybe give a specific example (e.g. recipe, using the patch)? Or not. I haven't tried to look for problems this might introduce, as none came to mind spontaneously. Do you really see something problematic here? I don't want to spend a lot of time on this. If you don't get it, or you don't think it's helpful, or you think it's problematic, please feel free to drop it and close the bug. No harm done. But I'm happy to answer questions about what the behavior or intention is, if I know the answers. IOW, if you're interested then we can continue to chat if something's not clear or there's a problem, but if you're not interested then let's call it quits. > > When TAB tells you that there is only one completion for your > > input (and completes to it), you can hit RET to choose that > > completion (act on it). But in some cases you might want to > > first, or instead, take some other action on it - in particular, > > maybe get some more info about it. This lets you do that. >=20 > Why only in that specific case? See above. Did I answer that sufficiently? > > Hitting TAB again at that point does nothing now - it's a no-op. > > If this hook were bound it would instead do something. >=20 > Ah, so you want this hook to be run when TAB is hit a second time, in > which case it normally does nothing (tho that depends on the config, it > may also display the *Completions* buffer)? Absolutely. If you just try the code I think it will become clear what the behavior and intention are. It's harder to describe than to experience. If you try it then maybe it will be easier to discuss any problems you see or further questions you have. > I think I'm beginning to understand. But I think it belongs in the > completion data (i.e. alongside :exit-function). I don't. But you're the expert on that. Go for it, if you think it's useful and that's a better approach. Do you think that's easier for someone writing a call to `completing-read' or `read-file-name', while giving users the same behavior? You're not just trying to promote uptake of `completion-extra-properties', are you? ;-) Really, I have no problem with your providing this some other way, or with deciding not to provide it at all.