From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#33595: 26; Have `try-completion' or `completion--done' run abnormal hook if sole completion Date: Wed, 02 Jan 2019 10:27:58 -0500 Message-ID: References: <13f934bf-e79c-47cb-88a5-7ee58cdc9242@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1546442826 28700 195.159.176.226 (2 Jan 2019 15:27:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2019 15:27:06 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33595@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 02 16:27:01 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 1geiQ9-0007KB-JN for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Jan 2019 16:27:01 +0100 Original-Received: from localhost ([127.0.0.1]:45532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1geiSG-0001G2-CU for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Jan 2019 10:29:12 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1geiSA-0001Fv-2z for bug-gnu-emacs@gnu.org; Wed, 02 Jan 2019 10:29:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1geiS6-0008K2-Vk for bug-gnu-emacs@gnu.org; Wed, 02 Jan 2019 10:29:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36211) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1geiS6-0008Ja-Qx for bug-gnu-emacs@gnu.org; Wed, 02 Jan 2019 10:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1geiS6-0000oG-GD for bug-gnu-emacs@gnu.org; Wed, 02 Jan 2019 10:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Jan 2019 15:29:02 +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.15464428823037 (code B ref 33595); Wed, 02 Jan 2019 15:29:02 +0000 Original-Received: (at 33595) by debbugs.gnu.org; 2 Jan 2019 15:28:02 +0000 Original-Received: from localhost ([127.0.0.1]:44871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geiR7-0000ml-TJ for submit@debbugs.gnu.org; Wed, 02 Jan 2019 10:28:02 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:53088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geiR5-0000mY-Lp for 33595@debbugs.gnu.org; Wed, 02 Jan 2019 10:28:01 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x02FRwrg011886; Wed, 2 Jan 2019 10:27:58 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 291A46A7F5; Wed, 2 Jan 2019 10:27:58 -0500 (EST) In-Reply-To: <13f934bf-e79c-47cb-88a5-7ee58cdc9242@default> (Drew Adams's message of "Tue, 1 Jan 2019 23:11:49 -0800 (PST)") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6452=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6452> : inlines <6990> : streams <1808922> : uri <2773730> 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:154089 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. 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 ...). 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, ... 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). >> 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 add >> a new `completion-extra-properties` alongside to :exit-function. > No, I don't think that's relevant. 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. >> 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 regardless >> 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. 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? Why should the user not want to see the same result when completing to an exact-but-not-sole match? 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. > [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).] 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. > 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. Why only in that specific case? > Hitting TAB again at that point does nothing now - it's a no-op. > If this hook were bound it would instead do something. 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)? I think I'm beginning to understand. But I think it belongs in the completion data (i.e. alongside :exit-function). Stefan