From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell* Date: Mon, 14 Oct 2019 23:49:58 +1300 Message-ID: References: <87fwm0zf60.fsf@jidanni.org> <874l0ct7vh.fsf@gnus.org> <0449ae1f85bbc0076cbfde9b61996660@webmail.orcon.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="212978"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: jidanni@jidanni.org, 9134@debbugs.gnu.org, monnier@iro.umontreal.ca To: Drew Adams , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 14 13:00:53 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iJy5t-000tJJ-7Y for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Oct 2019 13:00:53 +0200 Original-Received: from localhost ([::1]:47212 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJy5q-00020M-2j for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Oct 2019 07:00:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44841) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJxwN-0008OA-9T for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 06:51:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJxwL-0007Py-Ux for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 06:51:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57609) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iJxwL-0007PX-Qt for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 06:51:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iJxwL-0001Mx-NS for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 06:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Oct 2019 10:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9134 X-GNU-PR-Package: emacs Original-Received: via spool by 9134-submit@debbugs.gnu.org id=B9134.15710502065186 (code B ref 9134); Mon, 14 Oct 2019 10:51:01 +0000 Original-Received: (at 9134) by debbugs.gnu.org; 14 Oct 2019 10:50:06 +0000 Original-Received: from localhost ([127.0.0.1]:38197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iJxvS-0001La-4D for submit@debbugs.gnu.org; Mon, 14 Oct 2019 06:50:06 -0400 Original-Received: from smtp-2.orcon.net.nz ([60.234.4.43]:39071) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iJxvP-0001LJ-Cv for 9134@debbugs.gnu.org; Mon, 14 Oct 2019 06:50:04 -0400 Original-Received: from [116.251.203.173] (port=38223 helo=[192.168.20.103]) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1iJxvK-0006lF-L8; Mon, 14 Oct 2019 23:49:58 +1300 In-Reply-To: Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- 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: 209.51.188.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:169253 Archived-At: On 14/10/19 5:46 PM, Drew Adams wrote: > Doesn't the command performing the completion know this > information? Why isn't it sufficient for `C-h f' for that > command to provide the info? I'd think that if it's not > obvious the command's doc should let you know what things > you're completing against. Well, that can go through a LOT of indirection, so tracking down the actual source isn't that simple. Here we have: TAB => completion-at-point (command) => completion-at-point-functions (list) => comint-completion-at-point (function) => comint-dynamic-complete-functions (for me, a list of seven possiblities) => pcomplete-completions-at-point (function "using pcomplete's completion tables", however one establishes what that means -- certainly not in the elisp manual; AFAICS the pcomplete.el Commentary and code would need to be consulted) => pcomplete-completions (function which examines the buffer and employs various logic to figure out the appropriate completion function) => pcomplete/ssh (function) => pcmpl-ssh-hosts (function which actually does the thing) And frankly I only figured that out by working backwards, after grepping the code base for "known_hosts", setting debug-on-entry for `pcmpl-ssh-hosts', and then hitting TAB and finding how it actually arrived there. That's in no way simple to follow, even if the docstrings made everything really clear (which they do not; and possibly can't, given the involvement of "programmable completion" in the mix). As a side note, has it always been the case that, when asking about a variable with a buffer-local value, if you follow links in that *Help* buffer to other variables which also have buffer-local values in the original buffer, you'll only see the global values (because you're now local to the *Help* buffer)? I feel like it would be nice if the *Help* remained local to the same buffer for as long as you remained in the *Help* window. (For some reason this caught me out, but I'm probably inventing the idea that it used to be different.) > A priori, I don't think the info should be shown via a > transitory message or by putting an explanation in buffer > *Completions*. On reflection I agree that my suggestion wasn't a great idea; but I also don't think it's remotely practical to say that command documentation should be sufficient, when we're trawling through so many layers. What would perhaps be nice is for the *actual* sequence of events to be tracked internally, and reported on request, so that the user could ask "where did the completion(s) actually come from?" and be told the answer. -Phil