[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10457: (Broken?) programmable completion in shell buffers
From: |
Stefan Monnier |
Subject: |
bug#10457: (Broken?) programmable completion in shell buffers |
Date: |
Sun, 08 Jan 2012 20:26:40 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
> First, I'm unable to complete options to commands. Take, for example,
> "ssh". If I'm in my home directory, type "ssh -", and hit TAB, the
> command line changes to "ssh .-", and when I hit TAB again, a
> completions buffer pops up showing only the file and directory names
> starting with a dot and containing a dash. I assume that instead of
> offering the options available for ssh, Emacs performs some sort of
> "fuzzy" matching against file and directory names.
It's partial-completion at work: "a-b" matches "a*-b*" and "-" just
matches "*-*". Apparently all your file names that contained "-"
started with ".", hence the ".-".
> Is this the intended behavior, and if so, how can I disable this
> fuzzy matching?
You can remove partial-completion from completion-styles.
> TAB. When I am in a directory that doesn't contain files with a dash
> in the name, typing "ssh -" and hitting TAB produces only "No match"
> message in the minibuffer.
Indeed, pcomplete doesn't seem to provide any completion for ssh's "-"
options, currently, even though the code does do something for it:
(defun pcomplete/ssh ()
"Completion rules for the `ssh' command."
(pcomplete-opt "1246AaCfgKkMNnqsTtVvXxYbcDeFiLlmOopRSw")
(pcomplete-here (pcmpl-ssh-hosts)))
I don't think completion of "-" is very useful for ssh since there's no
long options, and most ascii letters are valid options, but still it
seems we have a bug that prevents pcomplete-opt from doing its job.
> Second, more disturbingly, trying to complete options to "tar" locks Emacs.
> Here is how to reproduce it:
> emacs -Q
> M-x shell
> cd <some directory without dashes in file and directory names>
> tar - TAB SPC
I believe I've fixed this bug "recently". If you can try the code in
the trunk to confirm that it's fixed, it would be wonderful.
> I've had high hopes for `pcomplete', but I am put off by its
> weirdness.
There's a lot more to it than "turning it on", so yes, it's been
a source of many bug reports. Thank you for trying it out to help track
down the various problems.
> I have just checked: the issues I've described happen only in shell,
> not in eshell (in eshell everything seems to work as expected).
For ssh, eshell actually overwrites pcomplete/ssh with an alias for
pcomplete/rsh so it doesn't use the same code (I suspect that using
eshell and then doing M-x shell will similarly "work as expected").
Stefan