Matt McClure <[email protected]> writes:
Hi Matt,
> Here's the backtrace the first time it stops:
[...]
> tramp-dissect-file-name("/ssh:" t)
> tramp-find-foreign-file-name-handler("/ssh:")
> tramp-file-name-handler(substitute-in-file-name "/ssh:")
> substitute-in-file-name("/ssh:")
> apply(substitute-in-file-name "/ssh:")
> tramp-completion-run-real-handler(substitute-in-file-name ("/ssh:"))
> tramp-completion-file-name-handler(substitute-in-file-name "/ssh:")
> substitute-in-file-name("/ssh:")
[...]
> rfn-eshadow-update-overlay()
Strange. The user error in `tramp-dissect-file-name' is raised only when
`tramp-completion-mode-p' returns nil. That function checks (beside
other things) the variable `non-essential', which is bound to t inside
`rfn-eshadow-update-overlay'. So there shouldn't be any problem.
Could you, please, check whether you might have shadow lisp files? Try
"M-x list-load-path-shadows".
In the debugger, you might also check the value of `non-essential', when
you pass `rfn-eshadow-update-overlay' and the break point.
> C-x C-f /ssh:[email protected]:/ RET
>
> This time the backtrace looks different. I notice these two stack
> frames that look suspicious:
>
> substitute-in-file-name("/ssh:[email protected].")
> completion--sifn-requote(27 "/ssh:[email protected]:/")
Here I don't see exactly what happens; I'm not so familiar with the
completion code in minibuffer.el. But maybe this is caused by the same
reason as the first break, let's see.
Best regards, Michael.
_______________________________________________
Tramp-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/tramp-devel
