GNU bug report logs -
#9134
don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*
Previous Next
To reply to this bug, email your comments to 9134 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#9134; Package
emacs.
(Thu, 21 Jul 2011 00:26:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jidanni <at> jidanni.org:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 21 Jul 2011 00:26:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> iro.umontreal.ca> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9134; Package
emacs.
(Mon, 14 Oct 2019 01:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 9134 <at> debbugs.gnu.org (full text, mbox):
jidanni <at> jidanni.org 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9134; Package
emacs.
(Mon, 14 Oct 2019 03:33:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 9134 <at> debbugs.gnu.org (full text, mbox):
On 2019-10-14 14:48, Lars Ingebrigtsen wrote:
> jidanni <at> jidanni.org 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9134; Package
emacs.
(Mon, 14 Oct 2019 04:47:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 9134 <at> debbugs.gnu.org (full text, mbox):
> >> 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?
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9134; Package
emacs.
(Mon, 14 Oct 2019 04:51:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 9134 <at> debbugs.gnu.org (full text, mbox):
Phil Sainty <psainty <at> orcon.net.nz> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9134; Package
emacs.
(Mon, 14 Oct 2019 05:09:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 9134 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9134; Package
emacs.
(Mon, 14 Oct 2019 10:51:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 9134 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9134; Package
emacs.
(Mon, 14 Oct 2019 12:27:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 9134 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9134; Package
emacs.
(Mon, 14 Oct 2019 14:38:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 9134 <at> debbugs.gnu.org (full text, mbox):
> > 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)
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.
>
> 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*.
>
> 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
This bug report was last modified 5 years and 243 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.