From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams 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 14:37:39 +0000 (UTC) Message-ID: <8e5df45f-6001-4245-a82c-75b78834ded6@default> 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: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88262"; mail-complaints-to="usenet@blaine.gmane.org" Cc: jidanni@jidanni.org, 9134@debbugs.gnu.org, monnier@iro.umontreal.ca To: Phil Sainty , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 14 16:40: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 1iK1Wn-000MjO-Dy for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Oct 2019 16:40:53 +0200 Original-Received: from localhost ([::1]:50794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iK1Wl-00083t-OV for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Oct 2019 10:40:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51158) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iK1U4-0004oo-Ey for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 10:38:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iK1U3-00056p-6f for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 10:38:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60841) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iK1U3-00056c-2S for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 10:38:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iK1U2-0005HA-Uw for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 10:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Oct 2019 14:38:02 +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.157106387520258 (code B ref 9134); Mon, 14 Oct 2019 14:38:02 +0000 Original-Received: (at 9134) by debbugs.gnu.org; 14 Oct 2019 14:37:55 +0000 Original-Received: from localhost ([127.0.0.1]:41428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iK1Tu-0005Gf-P0 for submit@debbugs.gnu.org; Mon, 14 Oct 2019 10:37:55 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:44792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iK1Tr-0005GQ-Eu for 9134@debbugs.gnu.org; Mon, 14 Oct 2019 10:37:53 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9EEIk8V079951; Mon, 14 Oct 2019 14:37:45 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-2019-08-05; bh=1wKkgPCuDZsn2gzW72BtpzAxVVJGeEhCCbLbSO1zhG4=; b=HDooia+tRVjbeCUlpr8y6jlTU1PEzOw01s9KRRazOcvHAZoqUXi12+zovca/fHlmDlCM 6Mzo5dVKkfCstN4z0aQ53afZzhgWo7zTWtM+e59BOrrWxkOBK0jpt3FvVcokWytZojHX PlPQVduDhWwMlwqa8fkrk9EVvjeoaxL9ILmlQnYFq9+K1ssQQPVN2WfUiM9hOU1iaW6x r5QvpFJPwhigEiCkc5ob5U1aT1/qmAOAYS/n7Y1c9TLzq38KOrWqzPC4AKgg4DMdUqjE +uFe3xG6batSC/JcWtrg7xiBymej9i749eaDSJIHKQdEBwihI/4c/4D47AmUJWX1FZ46 4g== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2vk68u9c9s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Oct 2019 14:37:45 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9EENPmg194412; Mon, 14 Oct 2019 14:37:44 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 2vkrbjygeu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Oct 2019 14:37:44 +0000 Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x9EEbeK9005973; Mon, 14 Oct 2019 14:37:41 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9409 signatures=668684 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-1908290000 definitions=main-1910140134 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9409 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910140134 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:169270 Archived-At: > > 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. >=20 > Well, that can go through a LOT of indirection, so tracking down > the actual source isn't that simple. Here we have: >=20 > TAB =3D> completion-at-point (command) Oh, yes, of course. I didn't realize that this was about `completion-at-point' instead of just `completing-read'. Yes, that's (ahem) a mess. Maybe a useful mess, but more or less a mess (IMHO). > 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. >=20 > 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). Indeed. Not such a self-documenting editor, in this regard. > 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.) Dunno. Maybe give a complete recipe and I'll check on older releases. > > A priori, I don't think the info should be shown via a > > transitory message or by putting an explanation in buffer > > *Completions*. >=20 > 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. I agree. I misguessed that this was only about completion from things like `completing-read' and `read-file-name'. > 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. +1