[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18891: Doesn't handle pwd = /C: very well
From: |
Michael Albinus |
Subject: |
bug#18891: Doesn't handle pwd = /C: very well |
Date: |
Tue, 04 Nov 2014 13:48:58 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Glenn Morris <rgm@gnu.org> writes:
> On a GNU/Linux system:
>
> mkdir -p /C:
> cd /C:
> emacs-24.4 -Q
>
> ->
>
> Tramp: Opening connection for C using scp...
> Opening connection for C using scp... \
> Tramp: Sending command `exec ssh -e none C'
> Tramp: Waiting for prompts from remote shell...
> Waiting for prompts from remote shell... \
> Tramp failed to connect. If this happens repeatedly, try
> `M-x tramp-cleanup-this-connection'
> [waits for ~ 30 seconds]
> Wrote /home/rgm/.emacs.d/tramp
>
> and Emacs never actually starts.
1. The Lisp backtrace reads like this:
...
apply(tramp-sh-file-name-handler expand-file-name ("/C:./." nil))
tramp-file-name-handler(expand-file-name "/C:./." nil)
file-attributes("/C:./.")
normal-top-level()
"/C:" as default directory is wrong. It triggers Tramp to start,
which fails. Maybe one could prevent this problem by giving the
default directory the prefix "/:".
2. If I wrap the call of `file-attributes' in `normal-top-level' with
`ignore-errors', Emacs starts up after claiming the Tramp
error. However, the docstring of `file-attributes' says "Value is nil
if specified file cannot be opened.". Therefore, `file-attributes'
itself must suppress errors even in such calls like
dired.c:912: filename = Fexpand_file_name (filename, Qnil);
3. The 30 sec delay is caused by Tramp, which tries to show the
connection buffer in order to give the user the possibility to know
what's up. This is not useful in this case, because Emacs hasn't
started yet. I would like to suppress this pause at this stage;
however I didn't find a way, how I could check whether Emacs is able
to show a buffer to the user (startup finished). A hint for this kind
of check would be helpful for me.
> cf: http://lists.gnu.org/archive/html/bug-gnu-emacs/2001-09/msg00154.html
13 years old ... it's time to fix it.
Best regards, Michael.