From: Michael Albinus <michael.albinus@gmx.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 9793@debbugs.gnu.org, Thierry Volpiatto <thierry.volpiatto@gmail.com>
Subject: bug#9793: 24.0.90; Unwanted tramp connection on eshell completion.
Date: Tue, 25 Oct 2011 12:41:01 +0200 [thread overview]
Message-ID: <87fwihgxqa.fsf@gmx.de> (raw)
In-Reply-To: <jwvobx64jvk.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 24 Oct 2011 10:20:36 -0400")
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Both use pretty much the same pcomplete code.
>
> I think I finally figured out what is the difference between the two
> cases: if you set pcomplete-file-ignore and pcomplete-dir-ignore
> in shell-mode like it is set in eshell, the same problem shows up.
>
> So what happens is:
> - in eshell-mode
> - file-name-all-completions returns '("tic:" "tequila:" "tmp/")
> - completion-file-name-table then checks the predicate (which combines
> file-directory-p with regexp matching to avoid CVS and a few other
> directories).
> - this calls (file-directory-p "tequila:") in the "/" dir, which
> triggers Tramp.
> - in shell-mode
> - file-name-all-completions returns '("tic:" "tequila:" "tmp/")
> - completion-file-name-table then checks the predicate (file-directory-p)
> - file-directory-p is *not* called because completion-file-name-table
> handles it specially (just checks the presence of a terminating "/").
Thanks for the explanation. I start to understand (honestly, all this
programmable completion is out of my understanding).
> I still don't understand why in eshell, tramp-maybe-open-connection is
> called within the following backtrace:
> tramp-completion-file-name-handler(file-directory-p "/tequila:")
> file-directory-p("tequila:")
> whereas when I manually call
> (let ((default-directory "/")) (file-directory-p "tequila:"))
> tramp-maybe-open-connection is called within the following backtrace:
> tramp-completion-file-name-handler(expand-file-name "tequila:" "/")
> file-directory-p("tequila:")
Tramp has some code to guess whether it is in completion mode. Check of
`non-essential' is one proof, checking the last keyboard input (being
TAB, or not) is another one.
If Tramp finds out that it is in completion mode, it suppresses some
remote actions, like expand-file-name. Since your code
(let ((default-directory "/")) (file-directory-p "tequila:"))
does not show an evidence of the completion mode, all remote actions are
performed.
The actions for `file-directory-p' are never been suppressed, that's why
Tramp performs them also when being in completion mode.
>> In eshell, all file names are good for completion, also remote
>> ones. This is valid, because "cd /sudo::" is a valid command in
>> eshell.
>
> In shell-mode completion also understands Tramp file names (yup, that's
> a bug, we should probably default comint-file-name-prefix to "/:/"), so
> that's not the problem.
Better not. There are still needed checks in shell.el, which are applied
to remote files. `comint-file-name-prefix keeps the remote part of those
files.
See for example Bug#6764.
>> But this makes the trouble with the completion predicate
>> `file-directory-p'.
>
> Yup, I think we should somehow make it so Tramp can say
> (file-directory-p "/tequila:") => t
> without trying to connect to tequila (after all, even if we can't
> connect to tequila, this is still a "directory", just one we currently
> can't access).
That was the intention of my patch :-)
Return t in case of remote files.
Inside Tramp it could be behave such a way when it detects it is in
completion mode. That means, when `non-essential' is set to t. Shall I
do it this way?
> Stefan
Best regards, Michael.
next prev parent reply other threads:[~2011-10-25 10:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-19 4:53 bug#9793: 24.0.90; Unwanted tramp connection on eshell completion Thierry Volpiatto
2011-10-20 2:31 ` Stefan Monnier
2011-10-20 18:46 ` Thierry Volpiatto
2011-10-20 20:43 ` Stefan Monnier
2011-10-20 21:17 ` Thierry Volpiatto
2011-10-22 9:39 ` Michael Albinus
2011-10-22 10:39 ` Thierry Volpiatto
2011-10-23 17:47 ` Stefan Monnier
2011-10-24 12:25 ` Michael Albinus
2011-10-24 14:20 ` Stefan Monnier
2011-10-25 10:41 ` Michael Albinus [this message]
2011-10-25 12:16 ` Stefan Monnier
2011-10-25 12:56 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fwihgxqa.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=9793@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=thierry.volpiatto@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.