Jim Porter writes: Hi Jim & Stefan, >>> Yes. However, there is already another problem in shell-mode. My patch >>> completes only incomplete Tramp file names, like "/ss". Complete Tramp >>> file names are handled by pcomplete-dirs already. So we see in a *shell* >>> buffer, w/o my patch: >> Good point. >> Still, we have the problem that `pcomplete/` should be used >> only >> for external commands (because they are independent from the language >> used to write the command, a.k.a the shell), but for things like `cd` we >> should be more precise to distinguish the completion rules for Eshell's >> `cd` from those of bash's `cd`. > > That should be possible by defining 'pcomplete/eshell-mode/CMD', but > that runs into two issues: 1) it's annoying to manually write all of > these, and 2) there may be other contexts in Eshell we want to > tab-complete remote directories that aren't covered by the > command-specific Pcomplete functions like that. > > (#1 should be fixable with a new version of > 'eshell-eval-using-options', but I haven't looked at that in much > detail yet.) I gave it another try. There is a new user option pcomplete-remote-ignore. When nil (the default), pcomplete expands remote file names, including method, user name and host name. The corresponding let-bindings in pcomplete--entries are short. In shell-completion-vars, I set it buffer-local to t. This prevents remote file name completion in *shell* buffers, fixing also the bug mentioned above. In eshell I haven't set anything, so by default remote file names are expanded. It should be easy to set pcomplete-remote-ignore, depending on whether the command is a built-in (keep it nil), or an external command (set it to t). The patch is appended. Please note, that this has effect only when Tramp is loaded, so you might need to test with "emacs -Q -l tramp". People, who never use Tramp, won't see a difference. For testing you need a recent checkout of Emacs master, because I have added another function to tramp.el. This is already pushed to master. Comments? Best regards, Michael.