bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9134: don't force mystery on user trying to find out what is complet


From: Phil Sainty
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]