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

[Stefan Monnier]

>> so it'd be OK.  Two issues, tho:
>> 1- first, I'd like to know why Tramp doesn't just signal an error,
>> rather than mess with windows and stuff.

> As I said, Tramp's syntax is ambigous. It tries to expand "/sudo:",
> which is a valid remote file name. Due to the syntax ambiguity, Tramp
> does not understand, that "sudo" is not a hostname in this case, and it
> fails with an error. What you see is the usual Tramp behaviour in case
> of an error, where it tries to give you some more information in case a
> connection does not work.

And the question above is really talking about "signal an error"
(ie.. call just `signal' or `error') vs "the usual Tramp behaviour in
case of an error, where it tries to give you some more information in
case a connection does not work".  This "usual Tramp behavior" is quite
problematic since it can't be silenced in the usual condition-case way.

> The amount of information can be reduced by lowering `tramp-verbose'.

Maybe the verbosity should be reduced by default.  Or maybe it should be
provided differently: we could make it so that the top-level exception
handler (the one that outputs the message in the minibuffer if an error
is not otherwise caught) can be programmed, so Tramp could call `signal'
in the normal way and do the messy window-pop-up in the top-level
exception handler instead (so it doesn't do it if the error gets
caught).
That could save us from a `completion-only' kind of hack.

>> 2- if we have to go this route it'll have to use a name that's not
>> specific to tramp.  Maybe `completion-only' or something like that.

> D'accord. I had always a bad feeling spreading Tramp internal names to
> the outside; when we have introduced that variable back in 2005 and
> 2007, Emacs was in a kind of feature freeze (IIRC), so I didn't ask for
> such a variable.

> `completion-*' symbols are spread over several *.el files.

AFAIK they're in completion.el (a historical accident), simple.el (a
historical accident since most of the completion code was in C back
then), and minibuffer.el (which I couldn't call completion.el because
of the previous historical accient).

> Where shall `completion-only' belong to? minibuffer.el?

Yes.


        Stefan