Gregory Heytings writes: Hi, > Apparently my previous last note was not the last one ;-) > > I still don't know how this bug should be fixed (except by using (setq > completion-at-point-functions '(pcomplete t))), but here is a more > detailed explanation of what is happening, at least how I understand > it: > > 1. TAB calls completion-at-point > 2. completion-at-point calls pcomplete-completions-at-point, which > calls pcomplete/cd; this completes the directory name > 3. completion-at-point let-binds completion-in-region-mode-predicate > to a lambda, which contains pcomplete-completion-at-point > 4. completion-at-point calls completion-in-region, which adds > completion-in-region--postch to post-command-hook > 5. post-command-hook calls completion-in-region--postch > 6. completion-in-region--postch funcalls completion-in-region-mode-predicate > 7. this calls pcomplete-completions-at-point a second time, which > again calls pcomplete/cd (and adds a '/' after the directory name (?)) > 8. RET is pressed > 9. post-command-hook still contains completion-in-region--postch: it > is called again > 10. completion-in-region--postch funcalls > completion-in-region-mode-predicate again > 11. this calls pcomplete-completions-at-point a third (!) time > 12. at this point pcomplete-completions-at-point considers (for some > reason, possibly because the last character of the input is '/' (?)) > that it is a command that it must now complete > 13. therefore instead of calling pcomplete/cd a third time, > pcomplete-completions-at-point now calls eshell-complete-commands-list > 14. this loops through all possible command names (on the local or remote host) > 15. if all command names had had a common prefix, that prefix would > have been inserted now, but this is not the case, so the effect of > this loop (apart from a waste of time) is nil > > The fact that default-directory is remote is not important here, the > exact same steps take place when it is local, except that step 15 is > executed much faster. > > At step 15 it is possible to interrupt the loop with C-g. At step 8 > it is possible to remove completion-in-region--postch from > post-command-hook for example by switching buffers with C-x C-b. > > Why such a overly complicated mechanism is used, or what should be > done to avoid this behavior, is beyond my understanding. I don't know the completion machinery, so I'm adding Stefan who might know better. However, the remote case could be improved. Tramp uses caches. They expire after a while (10 seconds per default), but this might be improved. The appended patch disables Tramp cache expiry while being in eshell-complete-commands-list, so completion might be faster once the cache has been filled. Could you pls check? Best regards, Michael.