bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

[jidanni]

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

bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

[Lars Ingebrigtsen]

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

bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

[Phil Sainty]

On 2019-10-14 14:48, Lars Ingebrigtsen wrote:
> jidanni@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

bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

[Drew Adams]

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

bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

[Lars Ingebrigtsen]

Phil Sainty <psainty@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

bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

[Phil Sainty]

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

bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

[Stefan Monnier]

> 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

bug#9134: don't force mystery on user trying to find out what is completing after the word "ssh" in *shell*

[Drew Adams]

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