bug#5840: 24.0.50; wrong tramp-file-name-regexp

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> with these settings:
>>> 
>>> ,----
>>> | (add-hook 'minibuffer-setup-hook
>>> |           (lambda () (add-hook 'post-command-hook
>>> |                                'minibuffer-completion-help nil t)))
>>> `----
>>> 
>>> If you do:
>>> C-x C-f ==> /su:
>>> 
>>> You have not the time to type the second ":" and tramp fail.
>>> (same for ssh/ftp)
>
> While I do get a Tramp failure, indeed, this does not prevent me from
> typing the second :.  I think the problem is more that the Tramp error
> is very loud and makes you think it's the end of the world, whereas in
> reality Emacs is still there waiting for you keep on typing.
>
>>> This could be fixed by modifying tramp-file-name-regexp like this:
>>> (tramp-file-name-regexp "\\`/\\([^[/:]+\\|[^/]+]\\):.*:")
>> This would be wrong. "/hostname:/path" is a valid remote file name, which
>> would not be catched by your regexp.

I didn't know and never use /hostname:, i always prefix it with method
(e.g ssh).

So i end up to this problem in anything by systematically translating
path like /su:: /sudo:: or /hostname: by:

/su:hostname:
/sudo:hostname:
/ssh:hostname:

To achieve that i use (in a let) to avoid connecting before the second
":":

(tramp-file-name-regexp "\\`/\\([^[/:]+\\|[^/]+]\\):.*:?")

And i translate the matched string in the path with:

,----
| (defun anything-create-tramp-name (fname)
|   "Build filename for `anything-pattern' \
| like /su::, /sudo:: or /hostname:."
|   (apply #'tramp-make-tramp-file-name
|          (loop
|             with v = (tramp-dissect-file-name fname)
|             for i across v collect i)))
`----



>> (For the records, I also dislike Tramp's syntactic ambiguity. But this is
>> history, I guess we cannot change it anymore.)
>
> Everything can be changed.
>
>> In order to fix this problem, one could tweak
>> `minibuffer-completion-predicate' in `minibuffer-completion-help',
>> which is `file-exists-p' in the given case.
>
> I think we somehow need to make the error a bit more quiet.
> Most of it needs to be done on Tramp's side, but maybe we can help it by
> having the completion code warn Tramp that this is only used
> for completion.  Or maybe the completion code can catch the error and
> just display it calmly.

And/Or always translate like above to avoid as much as possible errors.

> I wonder, tho: why is Tramp so loud?  Shouldn't it just call `signal'
> with appropriate parameters to indicate an error, without popping up
> any window?
>
>
>         Stefan
>
>
>
>
>
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/