GNU logs - #9134, boring messages

Message sent to owner <at> debbugs.gnu.org, bug-gnu-emacs@HIDDEN:

Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Resent-From: jidanni@HIDDEN
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Jul 2011 00:26:01 +0000
Resent-Message-ID: <handler.9134.B.131120795918015 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 9134 <at> debbugs.gnu.org
Cc: monnier@HIDDEN
DomainKey-Signature: a=rsa-sha1; c=nofws; d=jidanni.org; h=from:to:cc:subject
	:date:message-id:mime-version:content-type; q=dns;
	s=jidanni.org
	; b=Zbg1V8t+L6ZOOjWvFgzUbT9XMlQq7x0rIwiPO7NTnwm6Br293HNeRTXfuxaL
	AkK3cRwZxf4N2SsDDgp8CKaJGbUp1s40mtNdw0nfbCloEGP6oE76rQyO841gjxRf
	YOtFp+6hREs/Zr0HntSpUMxMiiYKNOaKwC8GY/L9VTILPUc=
From: jidanni@HIDDEN
Date: Thu, 21 Jul 2011 07:49:11 +0800
Message-ID: <87fwm0zf60.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

When we hit TAB in *shell* after the word "ssh",

* there are no messages about where in the world it is getting its
  completions. Unlike dabbrev-expand.

* C-h k TAB reveals nothing good about what is going on.

(rzgrep "ssh" "*.gz" "/usr/share/emacs/24.0.50/lisp/" nil "find . <X>
-type f <F> -exec zgrep <C> -nH -e <R> {} +") reveals

./net/tramp-sh.el.gz:423:    (tramp-parse-sconfig     "~/.ssh/config")

but C-h e shows that wasn't loaded.

Same with

./pcmpl-unix.el.gz:42:This allows one method of completion of SSH host names, the other

TRY IT YOURSELF:

$ emacs -Q -f shell
$ ssh C-h TAB
to try to find out where in the world it is getting its completions.

It won't tell you but I found it is in .ssh/config at least for me.
So there should be instructions RIGHT THERE at C-h k TAB
saying how to alter/turn off this.
E.G. if one wants to add a host, how is one supposed to put it into the
comments in that file, or .emacs.

>>>>> "SM" == Stefan Monnier <monnier@HIDDEN> writes:
>> Recently in M-x shell,

SM> I guess "recently" means "using Emacs Bzr trunk".

$ apt-cache policy $@
emacs-snapshot:
  Installed: 1:20110705-1

>> after
>> $ ssh
>> completion becomes different.

SM> Right, it's done according to pcomplete/ssh.

Well all the user knows is he hits C-h k TAB and sees no obvious clue.

>> Either tell me a way to turn this bonus feature off.

SM> I think that (defun pcomplete/ssh () nil) should do the trick.

>> Or tell me a way to add my favorite hosts to a list that it is trying to
>> complete.

SM> Look at the source code of pcomplete/ssh to see how that list is built.

Gobbledygook to we the average user.

SM> Basically, adding hosts in your .ssh/config or .ssh/known_hosts should
SM> do the trick.

OK, by trial and error I found putting "empty entries" there in .ssh/config

Host jidanni.org #for emacs -f shell completion

worked. However the user hitting C-h k TAB won't figure that out and
will need to write in for help.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: jidanni@HIDDEN
Subject: bug#9134: Acknowledgement (don't force mystery on user trying to
 find out what is completing after the word "ssh" in *shell*)
Message-ID: <handler.9134.B.131120795918015.ack <at> debbugs.gnu.org>
References: <87fwm0zf60.fsf@HIDDEN>
X-Gnu-PR-Message: ack 9134
X-Gnu-PR-Package: emacs
Reply-To: 9134 <at> debbugs.gnu.org
Date: Thu, 21 Jul 2011 00:26:01 +0000

Thank you for filing a new bug report with GNU.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 9134 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
9134: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D9134
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Oct 2019 01:49:02 +0000
Resent-Message-ID: <handler.9134.B9134.157101770710725 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: jidanni@HIDDEN
Cc: 9134 <at> debbugs.gnu.org, monnier@HIDDEN
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <87fwm0zf60.fsf@HIDDEN>
Date: Mon, 14 Oct 2019 03:48:18 +0200
In-Reply-To: <87fwm0zf60.fsf@HIDDEN> (jidanni@HIDDEN's message of
 "Thu, 21 Jul 2011 07:49:11 +0800")
Message-ID: <874l0ct7vh.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

jidanni@HIDDEN writes:

> When we hit TAB in *shell* after the word "ssh",
>
> * there are no messages about where in the world it is getting its
>   completions. Unlike dabbrev-expand.

That is pretty mysterious behaviour; yes.  Would flashing a message
saying "Looking for host names in ~/.ssh/known_hosts and ~/.ssh/config"
be helpful?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Resent-From: Phil Sainty <psainty@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Oct 2019 03:33:01 +0000
Resent-Message-ID: <handler.9134.B9134.15710239313275 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 9134 <at> debbugs.gnu.org, monnier@HIDDEN, jidanni@HIDDEN
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 14 Oct 2019 16:32:03 +1300
From: Phil Sainty <psainty@HIDDEN>
In-Reply-To: <874l0ct7vh.fsf@HIDDEN>
References: <87fwm0zf60.fsf@HIDDEN> <874l0ct7vh.fsf@HIDDEN>
Message-ID: <0449ae1f85bbc0076cbfde9b61996660@HIDDEN>
User-Agent: Orcon Webmail
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

On 2019-10-14 14:48, Lars Ingebrigtsen wrote:
> jidanni@HIDDEN writes:
> 
>> When we hit TAB in *shell* after the word "ssh",
>> 
>> * there are no messages about where in the world it is getting its
>>   completions. Unlike dabbrev-expand.
> 
> That is pretty mysterious behaviour; yes.  Would flashing a message
> saying "Looking for host names in ~/.ssh/known_hosts and ~/.ssh/config"
> be helpful?

I think it would be nicer if the *Completions* buffer text explained it.

i.e. additional information added to this:

"Click on a completion to select it.
In this buffer, type RET to select the completion near point.

Possible completions are:"

That's mostly from `completion-setup-function'.  Perhaps that could be
made to incorporate text from a new var, which could then be bound
dynamically in cases where extra context was desirable?


-Phil

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Resent-From: Drew Adams <drew.adams@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Oct 2019 04:47:02 +0000
Resent-Message-ID: <handler.9134.B9134.157102841826505 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 9134
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Phil Sainty <psainty@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 9134 <at> debbugs.gnu.org, monnier@HIDDEN, jidanni@HIDDEN
Received: via spool by 9134-submit <at> debbugs.gnu.org id=B9134.157102841826505
          (code B ref 9134); Mon, 14 Oct 2019 04:47:02 +0000
Received: (at 9134) by debbugs.gnu.org; 14 Oct 2019 04:46:58 +0000
Received: from localhost ([127.0.0.1]:37486 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iJsG1-0006tR-Oa
	for submit <at> debbugs.gnu.org; Mon, 14 Oct 2019 00:46:58 -0400
Received: from userp2120.oracle.com ([156.151.31.85]:52244)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1iJsG0-0006tE-3o
 for 9134 <at> debbugs.gnu.org; Mon, 14 Oct 2019 00:46:56 -0400
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9E4cvNN106244;
 Mon, 14 Oct 2019 04:46:49 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=GAN46TP/lpaKIQgYPIWD1z1eiO/eViWL75JAzYPFT50=;
 b=i+XDuQB37kcOta0XGcziHZwleDjH8g+Ihz51RLj/Ns5AAPju5k2VTqV8HQ/fUCfrs7lJ
 /tY7PRhRHV60IIgIACKE1kq8JhZQYATR/i3nlyHmJNB6tasws0cvjqCE5d4ybEoOGBUW
 aKnooyaB6pBJhPepjwpjpmMCTQUYDn2So3ansAyTzeiClDlo+hPvVgx5gRpqPnFz6f9d
 IHnRtsJNlTKhhdTL5aeH/EcRwYJbJKfK+a30EdV+JMIkh869yQ+rYmWYoTc72y/cSMnq
 PjgGUxGcAGg+mMz1tJqt6ITJBArQwl+1EPQBu46szzfwwWnclqWKsu5smxYA4oATy+DK Qg== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by userp2120.oracle.com with ESMTP id 2vk7fqwx5d-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 14 Oct 2019 04:46:49 +0000
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 x9E4hNgW109506;
 Mon, 14 Oct 2019 04:46:48 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])
 by aserp3020.oracle.com with ESMTP id 2vkrbj1kta-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 14 Oct 2019 04:46:48 +0000
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13])
 by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x9E4kjOd000667;
 Mon, 14 Oct 2019 04:46:46 GMT
MIME-Version: 1.0
Message-ID: <d2ca6941-d59d-48b6-9fa5-28453c028764@default>
Date: Mon, 14 Oct 2019 04:46:44 +0000 (UTC)
From: Drew Adams <drew.adams@HIDDEN>
References: <87fwm0zf60.fsf@HIDDEN> <874l0ct7vh.fsf@HIDDEN>
 <0449ae1f85bbc0076cbfde9b61996660@HIDDEN>
In-Reply-To: <0449ae1f85bbc0076cbfde9b61996660@HIDDEN>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1  (1003210) [OL
 16.0.4900.0 (x86)]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
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=951
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.0.1-1908290000 definitions=main-1910140045
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=1011
 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-1910140045
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> >> When we hit TAB in *shell* after the word "ssh",
> >>
> >> * there are no messages about where in the world it is getting its
> >>   completions. Unlike dabbrev-expand.
> >
> > That is pretty mysterious behaviour; yes.  Would flashing a message
> > saying "Looking for host names in ~/.ssh/known_hosts and
> ~/.ssh/config"
> > be helpful?
>=20
> I think it would be nicer if the *Completions* buffer text explained
> it.  i.e. additional information added to this:
>=20
> "Click on a completion to select it.
> In this buffer, type RET to select the completion near point.
>=20
> Possible completions are:"
>=20
> That's mostly from `completion-setup-function'.  Perhaps that could be
> made to incorporate text from a new var, which could then be bound
> dynamically in cases where extra context was desirable?

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.

A priori, I don't think the info should be shown via
a transitory message or by putting an explanation in
buffer *Completions*.

A priori, I think the proper place to explain/describe
the completion behavior (what it does, including what
the possible completions are) is the command's doc.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Oct 2019 04:51:02 +0000
Resent-Message-ID: <handler.9134.B9134.157102863226894 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 9134
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Phil Sainty <psainty@HIDDEN>
Cc: 9134 <at> debbugs.gnu.org, monnier@HIDDEN, jidanni@HIDDEN
Received: via spool by 9134-submit <at> debbugs.gnu.org id=B9134.157102863226894
          (code B ref 9134); Mon, 14 Oct 2019 04:51:02 +0000
Received: (at 9134) by debbugs.gnu.org; 14 Oct 2019 04:50:32 +0000
Received: from localhost ([127.0.0.1]:37500 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iJsJU-0006zi-23
	for submit <at> debbugs.gnu.org; Mon, 14 Oct 2019 00:50:32 -0400
Received: from [80.91.231.51] (port=48398 helo=quimby.gnus.org)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1iJsJR-0006za-UN
 for 9134 <at> debbugs.gnu.org; Mon, 14 Oct 2019 00:50:30 -0400
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie)
 by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <larsi@HIDDEN>)
 id 1iJsJM-0001d1-LV; Mon, 14 Oct 2019 06:50:27 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <87fwm0zf60.fsf@HIDDEN> <874l0ct7vh.fsf@HIDDEN>
 <0449ae1f85bbc0076cbfde9b61996660@HIDDEN>
Date: Mon, 14 Oct 2019 06:50:24 +0200
In-Reply-To: <0449ae1f85bbc0076cbfde9b61996660@HIDDEN> (Phil
 Sainty's message of "Mon, 14 Oct 2019 16:32:03 +1300")
Message-ID: <87wod8q6b3.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Phil Sainty <psainty@HIDDEN> writes: > I think it would
 be nicer if the *Completions* buffer text explained it. > > i.e. additional
 information added to this: > > "Click on a completion to select it. > In
 this buffer, type RET to select [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Phil Sainty <psainty@HIDDEN> writes: > I think it would
 be nicer if the *Completions* buffer text explained it. > > i.e. additional
 information added to this: > > "Click on a completion to select it. > In
 this buffer, type RET to select [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
 blocked.  See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
 for more information. [URIs: ingebrigtsen.no]
 0.0 SPF_NONE               SPF: sender does not publish an SPF Record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Phil Sainty <psainty@HIDDEN> writes:

> I think it would be nicer if the *Completions* buffer text explained it.
>
> i.e. additional information added to this:
>
> "Click on a completion to select it.
> In this buffer, type RET to select the completion near point.
>
> Possible completions are:"

If there's one or less completions, you won't get that buffer, so you
can't put the message about where it looks there, I think.

It's pretty self-evident where most completions come from, but the ssh
one is perhaps more surprising than most.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Oct 2019 05:09:02 +0000
Resent-Message-ID: <handler.9134.B9134.15710297014322 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 9134
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Phil Sainty <psainty@HIDDEN>
Cc: 9134 <at> debbugs.gnu.org, monnier@HIDDEN, jidanni@HIDDEN
Received: via spool by 9134-submit <at> debbugs.gnu.org id=B9134.15710297014322
          (code B ref 9134); Mon, 14 Oct 2019 05:09:02 +0000
Received: (at 9134) by debbugs.gnu.org; 14 Oct 2019 05:08:21 +0000
Received: from localhost ([127.0.0.1]:37512 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iJsaj-00017e-Et
	for submit <at> debbugs.gnu.org; Mon, 14 Oct 2019 01:08:21 -0400
Received: from [80.91.231.51] (port=48706 helo=quimby.gnus.org)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1iJsah-00017W-F0
 for 9134 <at> debbugs.gnu.org; Mon, 14 Oct 2019 01:08:20 -0400
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie)
 by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <larsi@HIDDEN>)
 id 1iJsaa-0001lO-Gv; Mon, 14 Oct 2019 07:08:16 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <87fwm0zf60.fsf@HIDDEN> <874l0ct7vh.fsf@HIDDEN>
 <0449ae1f85bbc0076cbfde9b61996660@HIDDEN>
 <87wod8q6b3.fsf@HIDDEN>
Date: Mon, 14 Oct 2019 07:08:12 +0200
In-Reply-To: <87wod8q6b3.fsf@HIDDEN> (Lars Ingebrigtsen's message of "Mon,
 14 Oct 2019 06:50:24 +0200")
Message-ID: <87o8yjrk1v.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Lars Ingebrigtsen <larsi@HIDDEN> writes: > It's pretty
 self-evident
 where most completions come from, but the ssh > one is perhaps more surprising
 than most. And testing it some more, it doesn't really work very well. 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Lars Ingebrigtsen <larsi@HIDDEN> writes: > It's pretty
 self-evident
 where most completions come from, but the ssh > one is perhaps more surprising
 than most. And testing it some more, it doesn't really work very well. 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
 blocked.  See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
 for more information. [URIs: ingebrigtsen.no]
 0.0 SPF_NONE               SPF: sender does not publish an SPF Record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Lars Ingebrigtsen <larsi@HIDDEN> writes:

> It's pretty self-evident where most completions come from, but the ssh
> one is perhaps more surprising than most.

And testing it some more, it doesn't really work very well.

$ ssh TAB

gives me

$ ssh quimbies

because I have "Host quimbies" in .ssh/config.  But:

$ ssh qTAB

gives me "No match".

It also looks in ~/.ssh/known_hosts, but the default is to hash the host
names, so by default, there's nothing there to complete over.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Resent-From: Phil Sainty <psainty@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Oct 2019 10:51:01 +0000
Resent-Message-ID: <handler.9134.B9134.15710502065186 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 9134
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Drew Adams <drew.adams@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 9134 <at> debbugs.gnu.org, monnier@HIDDEN, jidanni@HIDDEN
Received: via spool by 9134-submit <at> debbugs.gnu.org id=B9134.15710502065186
          (code B ref 9134); Mon, 14 Oct 2019 10:51:01 +0000
Received: (at 9134) by debbugs.gnu.org; 14 Oct 2019 10:50:06 +0000
Received: from localhost ([127.0.0.1]:38197 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iJxvS-0001La-4D
	for submit <at> debbugs.gnu.org; Mon, 14 Oct 2019 06:50:06 -0400
Received: from smtp-2.orcon.net.nz ([60.234.4.43]:39071)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <psainty@HIDDEN>) id 1iJxvP-0001LJ-Cv
 for 9134 <at> debbugs.gnu.org; Mon, 14 Oct 2019 06:50:04 -0400
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 <psainty@HIDDEN>)
 id 1iJxvK-0006lF-L8; Mon, 14 Oct 2019 23:49:58 +1300
References: <87fwm0zf60.fsf@HIDDEN> <874l0ct7vh.fsf@HIDDEN>
 <0449ae1f85bbc0076cbfde9b61996660@HIDDEN>
 <d2ca6941-d59d-48b6-9fa5-28453c028764@default>
From: Phil Sainty <psainty@HIDDEN>
Message-ID: <d2941119-be4e-682c-275b-d9cd526f138d@HIDDEN>
Date: Mon, 14 Oct 2019 23:49:58 +1300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <d2ca6941-d59d-48b6-9fa5-28453c028764@default>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-GeoIP: NZ
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Oct 2019 12:27:02 +0000
Resent-Message-ID: <handler.9134.B9134.157105599529766 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 9134
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Phil Sainty <psainty@HIDDEN>
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 9134 <at> debbugs.gnu.org, Drew Adams <drew.adams@HIDDEN>, jidanni@HIDDEN
Received: via spool by 9134-submit <at> debbugs.gnu.org id=B9134.157105599529766
          (code B ref 9134); Mon, 14 Oct 2019 12:27:02 +0000
Received: (at 9134) by debbugs.gnu.org; 14 Oct 2019 12:26:35 +0000
Received: from localhost ([127.0.0.1]:38279 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iJzQo-0007k1-Uf
	for submit <at> debbugs.gnu.org; Mon, 14 Oct 2019 08:26:35 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29548)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1iJzQm-0007jn-JB
 for 9134 <at> debbugs.gnu.org; Mon, 14 Oct 2019 08:26:33 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 844EF10058D;
 Mon, 14 Oct 2019 08:26:26 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2933610032F;
 Mon, 14 Oct 2019 08:26:25 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1571055985;
 bh=Zfc7sCXd4Jy459Oh7+LzcNNWgrgtRytqFanTfgYa8TU=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=nMfVR8cF6E4ymaIi/cKsq8T71s18QBS0+YP7oQfSps8iHXnSFXDxxocwPdjjqKf+f
 +0SePYasNHjjbsjRqOKk3FTa0oBHBb6hP6PjLG4hzm1I+0jtZmR+BBNfI1p82sHpXe
 q07sr5+VHkCKO1boi8LUlZzT9YSez3kUHBVaaqSv+Q4ksBCq442hZB+loJKvaVpdp2
 3Ccug4naw3kRFRjZOqTEWIKyZjk3/E1Ok9WO8vP5+vF580dARqY0ycnSLs+pou5JH+
 6okhsIrqK6p8Y00LgmUbTvqNC2rQElN8PEuHZciW2ZrofD2YOewLOME784WpTQu3AE
 zBwZLnNSIxpLQ==
Received: from pastel (unknown [216.154.35.246])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D6BF11207BD;
 Mon, 14 Oct 2019 08:26:24 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwv36fvzfbu.fsf-monnier+emacs@HIDDEN>
References: <87fwm0zf60.fsf@HIDDEN> <874l0ct7vh.fsf@HIDDEN>
 <0449ae1f85bbc0076cbfde9b61996660@HIDDEN>
 <d2ca6941-d59d-48b6-9fa5-28453c028764@default>
 <d2941119-be4e-682c-275b-d9cd526f138d@HIDDEN>
Date: Mon, 14 Oct 2019 08:26:23 -0400
In-Reply-To: <d2941119-be4e-682c-275b-d9cd526f138d@HIDDEN> (Phil
 Sainty's message of "Mon, 14 Oct 2019 23:49:58 +1300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.029 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> 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)?

Yes.

> 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.

I think I agree.

> 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.

I don't think the "sequence of events" is really necessary, but maybe
just the "last bit" (i.e. pcmpl-ssh-hosts in your example), but yes,
reporting upon request after-the-fact could be good, tho it's probably
going to be hard to make it sufficiently discoverable.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Resent-From: Drew Adams <drew.adams@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Oct 2019 14:38:02 +0000
Resent-Message-ID: <handler.9134.B9134.157106387520258 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 9134
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Phil Sainty <psainty@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 9134 <at> debbugs.gnu.org, monnier@HIDDEN, jidanni@HIDDEN
Received: via spool by 9134-submit <at> debbugs.gnu.org id=B9134.157106387520258
          (code B ref 9134); Mon, 14 Oct 2019 14:38:02 +0000
Received: (at 9134) by debbugs.gnu.org; 14 Oct 2019 14:37:55 +0000
Received: from localhost ([127.0.0.1]:41428 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iK1Tu-0005Gf-P0
	for submit <at> debbugs.gnu.org; Mon, 14 Oct 2019 10:37:55 -0400
Received: from userp2130.oracle.com ([156.151.31.86]:44792)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1iK1Tr-0005GQ-Eu
 for 9134 <at> debbugs.gnu.org; Mon, 14 Oct 2019 10:37:53 -0400
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== 
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
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
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
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
MIME-Version: 1.0
Message-ID: <8e5df45f-6001-4245-a82c-75b78834ded6@default>
Date: Mon, 14 Oct 2019 14:37:39 +0000 (UTC)
From: Drew Adams <drew.adams@HIDDEN>
References: <87fwm0zf60.fsf@HIDDEN> <874l0ct7vh.fsf@HIDDEN>
 <0449ae1f85bbc0076cbfde9b61996660@HIDDEN>
 <d2ca6941-d59d-48b6-9fa5-28453c028764@default>
 <d2941119-be4e-682c-275b-d9cd526f138d@HIDDEN>
In-Reply-To: <d2941119-be4e-682c-275b-d9cd526f138d@HIDDEN>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1  (1003210) [OL
 16.0.4900.0 (x86)]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> > 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

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.