Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

[Stefan Monnier]

>     * lisp/minibuffer.el (completion--nth-completion):
>     Let-bind `non-essential'.

Oh, no, this is wrong.  This amounts to saying that all forms of
completions are always non-essential, which is definitely incorrect.


        Stefan

Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

[Michael Albinus]

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

Hi Stefan,

>>     * lisp/minibuffer.el (completion--nth-completion):
>>     Let-bind `non-essential'.
>
> Oh, no, this is wrong.  This amounts to saying that all forms of
> completions are always non-essential, which is definitely incorrect.

The only meaning of `non-essential' is to give Tramp a hint that we're
in completion. I haven't seen any other use of this variable since it
has been introduced back in 2010.

If you believe this is wrong, then Tramp needs another variable for such
a trigger. As we did agree originally in
<http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-04/msg00371.html>. The
idea to take `non-essential' instead came later from you.

>         Stefan

Best regards, Michael.

Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

[Stefan Monnier]

> The only meaning of `non-essential' is to give Tramp a hint that we're
> in completion.

No, the meaning of it is: we're running code which is not essential
(basically, running in something equivalent to a background thread).

It's been introduced mainly for Tramp, so that Tramp can decide whether
it should try to open a new connection or not (e.g., it should open
a new connection when the user does `C-x C-f /ssh:foo:bar TAB' but it
shouldn't open a new connection when the user does
`M-x icomplete-mode RET C-x C-f /ssh:foo:bar').

The binding you added gets rid of this distinction, and indeed, now if
I do `C-x C-f /ssh:foo:bar TAB' I don't get any completion any more.


        Stefan

Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

[Michael Albinus]

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

>> The only meaning of `non-essential' is to give Tramp a hint that we're
>> in completion.
>
> No, the meaning of it is: we're running code which is not essential
> (basically, running in something equivalent to a background thread).
>
> It's been introduced mainly for Tramp, so that Tramp can decide whether
> it should try to open a new connection or not (e.g., it should open
> a new connection when the user does `C-x C-f /ssh:foo:bar TAB' but it
> shouldn't open a new connection when the user does
> `M-x icomplete-mode RET C-x C-f /ssh:foo:bar').

It is not only the password case. It is also the ambiguity of the remote
file name syntax, where "/abc:" could be already a hostname, or just a
method. Tramp must know whether it is in completion, and behave accordingly.
File name handlers are bound to the syntax of a file name; no semantics
included.

I hate this ambiguity since ever (I've entered Tramp maintenace in
2002). But we are much too late to change the syntax.

> The binding you added gets rid of this distinction, and indeed, now if
> I do `C-x C-f /ssh:foo:bar TAB' I don't get any completion any more.

A single "/" helps. Try `C-x C-f /ssh:foo:./bar TAB' for example.

>         Stefan

Best regards, Michael.

Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

[Stefan Monnier]

> I hate this ambiguity since ever (I've entered Tramp maintenace in
> 2002).  But we are much too late to change the syntax.

Of course not.  It can be changed very easily, and very few users if any
will suffer from it.  In all likelihood the only cases where this
occurs are interactive situations, and we've generally considered it OK
to break backward compatibility with "old humans" (as opposed to "old
code", where we usually try to preserve this compatibility) except for
specific cases where we think that it will inconvenience muscle memory of
too many users.

Let's get rid of this ambiguity once and for all, so we can move on,
instead of adding hacks to try and keep it alive even longer.

>> The binding you added gets rid of this distinction, and indeed, now if
>> I do `C-x C-f /ssh:foo:bar TAB' I don't get any completion any more.
> A single "/" helps. Try `C-x C-f /ssh:foo:./bar TAB' for example.

So I see another problem:

   emacs -Q
   M-x icomplete-mode RET
   C-x C-f /ssh:foo:/

and now suddenly it's signaling errors because it tries to connect to
`foo` even though I haven't requested any completion yet.
I think it should honor `non-essential' in that case and not try to open
up a new connection until I hit TAB or some similar explicit request.


        Stefan

Change Tramp syntax (was: [Emacs-diffs] master 37b88d7: Fix bug#23006)

[Michael Albinus]

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

>> I hate this ambiguity since ever (I've entered Tramp maintenace in
>> 2002).  But we are much too late to change the syntax.
>
> Of course not.  It can be changed very easily, and very few users if any
> will suffer from it.  In all likelihood the only cases where this
> occurs are interactive situations, and we've generally considered it OK
> to break backward compatibility with "old humans" (as opposed to "old
> code", where we usually try to preserve this compatibility) except for
> specific cases where we think that it will inconvenience muscle memory of
> too many users.

IIRC, the main reason to declare the method part optional was to still
support ange-ftp syntax. Now it's 15 years later, and the number of
ange-ftp users might have decreased.

> Let's get rid of this ambiguity once and for all, so we can move on,
> instead of adding hacks to try and keep it alive even longer.

Maybe we shall start a poll, in emacs-devel, emacs-help and
tramp-devel. We should not ask what a user prefers (many of them will
prefer not to type a method). They question must be what will be broken
if we stop support for ange-ftp syntax "/host:/path/to/file".

This would also mean, that we cannot support default methods anymore. A
file name with a default method would look like "/:host:/path/to/file",
which is already the quoted file name syntax.

John? Eli?

> So I see another problem:
>
>    emacs -Q
>    M-x icomplete-mode RET
>    C-x C-f /ssh:foo:/
>
> and now suddenly it's signaling errors because it tries to connect to
> `foo` even though I haven't requested any completion yet.
> I think it should honor `non-essential' in that case and not try to open
> up a new connection until I hit TAB or some similar explicit request.

I'll check.

>         Stefan

Best regards, Michael.

Re: Change Tramp syntax (was: [Emacs-diffs] master 37b88d7: Fix bug#23006)

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Fri, 10 Mar 2017 15:14:21 +0100
> Cc: emacs-devel@gnu.org
> 
> Maybe we shall start a poll, in emacs-devel, emacs-help and
> tramp-devel. We should not ask what a user prefers (many of them will
> prefer not to type a method). They question must be what will be broken
> if we stop support for ange-ftp syntax "/host:/path/to/file".
> 
> This would also mean, that we cannot support default methods anymore. A
> file name with a default method would look like "/:host:/path/to/file",
> which is already the quoted file name syntax.
> 
> John? Eli?

I didn't use ange-ftp syntax in a decade.  Not sure what others do,
but my impression is that Tramp methods are the only game in town.

Re: Change Tramp syntax

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> I didn't use ange-ftp syntax in a decade. Not sure what others do, but my
EZ> impression is that Tramp methods are the only game in town.

I use the ange-ftp syntax multiple times a day, for years now.  It's how I
edit files on remote hosts.

Changing from "/host:file" to "/-:host:file" seems like an unnecessary change
in syntax -- when the first form is so easy to use -- but only because I don't
understand the difficulties it causes. However, I imagine many users, who like
me are long-familiar with the first form, will wonder why we had to move to a
more complex syntax *when the first one has been working for years and years*.

How are people using the new Tramp to learn that "/-:" is replaced by "/"?
Will "/host:file" just be broken for them, and they have to understand both
(1) that it's a Tramp-related issue, and (2) how to find the answer in the
Tramp manual or NEWS file?

If there are more people like me out there, relying on this syntax as heavily,
I have a sense this is going to feel like a concession that does not benefit
the user. Unless I'm mistaken, the user gains nothing from the change, but now
has to remember to add "-:" to path names long since burned into finger
memory.

- Is there *any way* to retain ange-ftp syntax, maybe even as a hack that
  rewrites /foo:bar into /-:foo:bar, and can be required from a compat module?

- What is the user experience when ange-ftp paths are used, after this change
  is made?

Thanks,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Change Tramp syntax

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

Hi John,

> Changing from "/host:file" to "/-:host:file" seems like an unnecessary change
> in syntax -- when the first form is so easy to use -- but only because I don't
> understand the difficulties it causes. However, I imagine many users, who like
> me are long-familiar with the first form, will wonder why we had to move to a
> more complex syntax *when the first one has been working for years and years*.

It didn't work ever. User and host name completion was based on a
terrible heuristic. There have been bug reports, plus a many years long
dissense between Stefan and me about `non-essential'.

Enough reasons that I decided to solve it once and forever.

> How are people using the new Tramp to learn that "/-:" is replaced by "/"?
> Will "/host:file" just be broken for them, and they have to understand both
> (1) that it's a Tramp-related issue, and (2) how to find the answer in the
> Tramp manual or NEWS file?

There's no need to use "-". You could always use "ssh" instead, if this
annoys your eyes.

> If there are more people like me out there, relying on this syntax as heavily,
> I have a sense this is going to feel like a concession that does not benefit
> the user. Unless I'm mistaken, the user gains nothing from the change, but now
> has to remember to add "-:" to path names long since burned into finger
> memory.
>
> - Is there *any way* to retain ange-ftp syntax, maybe even as a hack that
>   rewrites /foo:bar into /-:foo:bar, and can be required from a compat module?

See the Tramp manual, Frequently Asked Questions section. It explains
several possibilities how to shorten the filename. Maybe it shall be
documented more prominently.

The other way back to the ange-ftp syntax I've mentioned in my
announcement: You are invited to implement a solution in Tramp :-)

I failed.

> - What is the user experience when ange-ftp paths are used, after this change
>   is made?
>
> Thanks,

Best regards, Michael.

Re: Change Tramp syntax

[John Wiegley]

>>>>> "MA" == Michael Albinus <michael.albinus@gmx.de> writes:

MA> It didn't work ever. User and host name completion was based on a terrible
MA> heuristic. There have been bug reports, plus a many years long dissense
MA> between Stefan and me about `non-essential'.

Personally I don't care to ever complete host names (they're always short, as
I use ssh/config to manage them), so I'd rather have /host:file than an
unambiguous way to complete host names I never complete. I could be in the
minority, though.

MA> Enough reasons that I decided to solve it once and forever.

This is the essence of my question: Does it solve the problem for some, at a
cost to others? What is the new user experience if they fail to use "ssh:"? Is
it obvious what they've done wrong and how to fix it? You're modifying some
seriously ancient behavior with this change.

MA> There's no need to use "-". You could always use "ssh" instead, if this
MA> annoys your eyes.

Well.... by adding 4 characters to every remote pathname I type, for no
benefit *I* can perceive.

MA> The other way back to the ange-ftp syntax I've mentioned in my
MA> announcement: You are invited to implement a solution in Tramp :-)

Since you know the code well, do you think it's easy to add my own
file-name-handler that will insert the missing "ssh:" and resubmit to Tramp?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

RE: Change Tramp syntax

[Drew Adams]

> MA> It didn't work ever. User and host name completion was based on
> a terrible
> MA> heuristic. There have been bug reports, plus a many years long
> dissense
> MA> between Stefan and me about `non-essential'.
> 
> Personally I don't care to ever complete host names (they're always
> short, as
> I use ssh/config to manage them), so I'd rather have /host:file than
> an
> unambiguous way to complete host names I never complete. I could be
> in the
> minority, though.
> 
> MA> Enough reasons that I decided to solve it once and forever.
> 
> This is the essence of my question: Does it solve the problem for
> some, at a
> cost to others? What is the new user experience if they fail to use
> "ssh:"? Is
> it obvious what they've done wrong and how to fix it? You're
> modifying some
> seriously ancient behavior with this change.
> 
> MA> There's no need to use "-". You could always use "ssh" instead,
> if this
> MA> annoys your eyes.
> 
> Well.... by adding 4 characters to every remote pathname I type, for
> no
> benefit *I* can perceive.
> 
> MA> The other way back to the ange-ftp syntax I've mentioned in my
> MA> announcement: You are invited to implement a solution in Tramp
> :-)
> 
> Since you know the code well, do you think it's easy to add my own
> file-name-handler that will insert the missing "ssh:" and resubmit
> to Tramp?

FWIW, and without wanting to argue for it, I'll mention
that I too use FTP and the /host:file/ syntax.  I don't
use ssh - I use only ange-ftp.  And I don't really care
about file-name completion for remote names, if that helps.

Not trying to persuade anyone; just letting you know
there is one more ange-ftp user.

Re: Change Tramp syntax

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

Hi John,

> Since you know the code well, do you think it's easy to add my own
> file-name-handler that will insert the missing "ssh:" and resubmit to Tramp?

Adding another file name handler would be complicate, because Tramp
plays with inhibit-file-name-{handlers, operation} internally. And other
packages call Tramp functions directly, which might cause also problems.

But Tramp supports already two different syntaxes, the well known
"/method:user@host:" syntax, and the XEmacs style "/[method/user@host]"
syntax. You can select which syntax to use by changing `tramp-syntax'.

It shouldn't be too hard to add a third variant "/user@host:". Give me
some days to play with.

Best regards, Michael.

Re: Change Tramp syntax

[John Wiegley]

>>>>> "MA" == Michael Albinus <michael.albinus@gmx.de> writes:

MA> It shouldn't be too hard to add a third variant "/user@host:". Give me
MA> some days to play with.

Thanks! Would the "user@" be required in that case? Is there any way at all to
retain the behavior of "/host:"? :)

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Change Tramp syntax

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> "MA" == Michael Albinus <michael.albinus@gmx.de> writes:
>
> MA> It shouldn't be too hard to add a third variant "/user@host:". Give me
> MA> some days to play with.
>
> Thanks! Would the "user@" be required in that case? Is there any way at all to
> retain the behavior of "/host:"? :)

"user@" would still be optional. So yes, "/host:" is valid in this
special syntax.

Best regards, Michael.

Re: Change Tramp syntax

[John Wiegley]

>>>>> "MA" == Michael Albinus <michael.albinus@gmx.de> writes:

MA> "user@" would still be optional. So yes, "/host:" is valid in this special
MA> syntax.

If that can be the case, all my objections go away. Let me know if I can help
with testing.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Change Tramp syntax

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

Hi John,

> MA> "user@" would still be optional. So yes, "/host:" is valid in this special
> MA> syntax.
>
> If that can be the case, all my objections go away. Let me know if I can help
> with testing.

I've pushed a patch to master which shall allow you to change your Tramp
syntax. Put something like this in your .emacs:

(tramp-change-syntax 'ftp)

That's it, you have ange-ftp syntax "/user@host:/path/to/file". Other
possible values are 'def (the default), which changes the syntax to
"/method:user@host:/path/to/file"; and 'sep (the XEmacs syntax), which
is "/[method/user@host]/path/to/file". In all cases, the "user@" part is
optional.

You could also call interactively "M-x tramp-change-syntax" at any
time. It is autoloaded, no need to load tramp.el before.

Note, that this function kills all existing buffers with a remote
default-directory, because these buffers cannot be used anymore. Maybe I
should give the user a warning in the interactive case.

Please give it a testing. I know, at least Drew will test it as well.

There's still something to do, documentation, new test cases; but I've
pushed the code already in order to get early feedback.

Best regards, Michael.

Re: Change Tramp syntax

[John Wiegley]

>>>>> "MA" == Michael Albinus <michael.albinus@gmx.de> writes:

MA> I've pushed a patch to master which shall allow you to change your Tramp
MA> syntax. Put something like this in your .emacs:

MA> (tramp-change-syntax 'ftp)

Thanks, Michael! I'll give it a try next week.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Change Tramp syntax

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> "MA" == Michael Albinus <michael.albinus@gmx.de> writes:
>
> MA> I've pushed a patch to master which shall allow you to change your Tramp
> MA> syntax. Put something like this in your .emacs:
>
> MA> (tramp-change-syntax 'ftp)
>
> Thanks, Michael! I'll give it a try next week.

It's (tramp-change-syntax 'simplified) now.

Best regards, Michael.

Re: Change Tramp syntax

[John Wiegley]

>>>>> "MA" == Michael Albinus <michael.albinus@gmx.de> writes:

MA> It's (tramp-change-syntax 'simplified) now.

This is excellent, Michael, thank you for being so responsive on this issue. I
look forward to many more years of using Tramp. In fact, I was just using it
not 10 minutes ago to edit logwatch.conf file on my VPS...

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Change Tramp syntax

[Filipp Gunbin]

Hi Michael,

'def and 'sep seem a bit obscure.  Maybe 'default and 'xemacs?

Filipp

Re: Change Tramp syntax

[Michael Albinus]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> Hi Michael,

Hi Filipp,

> 'def and 'sep seem a bit obscure.  Maybe 'default and 'xemacs?

I know that. But tramp-syntax exists since ever, offering the values
'ftp and 'sep. So I have a compatibility problem.

There is also the other problem, that 'ftp was used in the past for what
'def is today. Achhhh ...

I will think about.

> Filipp

Best regards.

Re: Change Tramp syntax

[Michael Albinus]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> Hi Michael,

Hi Filipp,

> 'def and 'sep seem a bit obscure.  Maybe 'default and 'xemacs?

I've changed possible values now to 'default, 'simplified and 'separate.

> Filipp

Best regards, Michael.

Talking about Lisp symbols

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Please don't write a quote before a symbol to say it's a constant symbol.
That goes against GNU conventions.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Change Tramp syntax

[Filipp Gunbin]

Thanks!

Filipp

Re: Change Tramp syntax

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

Michael Albinus [2017-04-08 18:41:54+02] wrote:

> I've changed possible values now to 'default, 'simplified and
> 'separate.

I think "default" shouldn't be a name itself. Better use meaningful
names and choose one as the default. See variable Man-notify-method for
a good example.

(Just a random comment from a user.)

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: Change Tramp syntax

[Michael Albinus]

Teemu Likonen <tlikonen@iki.fi> writes:

> Better use meaningful names

That's definitely not my expertise ...

Proposals welcome

Best regards, Michael.

Re: Change Tramp syntax

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

Michael Albinus [2017-04-10 18:45:49+02] wrote:

> Teemu Likonen <tlikonen@iki.fi> writes:
>> Better use meaningful names

> Proposals welcome

My Emacs 25.2 does not have the Tramp changes in question but if there's
a syntax option that uses only /method: prefix then maybe symbol named
"method" would fit. I understand too little about the details. Just
trying to suggest using more descriptive name than "default". I think it
makes user interface better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: Change Tramp syntax

[John Wiegley]

>>>>> John Wiegley <johnw@gnu.org> writes:

> This is the essence of my question: Does it solve the problem for some, at a
> cost to others? What is the new user experience if they fail to use "ssh:"?
> Is it obvious what they've done wrong and how to fix it?

Michael, I'd still like an answer to these questions, please. I'm concerned
about how this change is going to affect users who aren't as aware of Tramp
and its workings. Thanks! Alternatively, if we implement a compat translation
that is on by default for at least a few versions, it would resolve these
questions as well.

Thanks,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Change Tramp syntax

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

Hi John,

>> This is the essence of my question: Does it solve the problem for some, at a
>> cost to others? What is the new user experience if they fail to use "ssh:"?
>> Is it obvious what they've done wrong and how to fix it?
>
> Michael, I'd still like an answer to these questions, please. I'm concerned
> about how this change is going to affect users who aren't as aware of Tramp
> and its workings. Thanks! Alternatively, if we implement a compat translation
> that is on by default for at least a few versions, it would resolve these
> questions as well.

If people do a simple "C-x C-f /localhost:" from an Emacs started with
-Q, they get an error "File not found and directory
write-protected". Tramp cannot do anything else, because it is not
involved.

If there is a file name completion package active (ido, icomplete,
whatever), they get a guidance while typing the filename, latest when
the trailing ":" has been typed.

If a user tries to complete a filename, even if only plain Emacs is
called with -Q, she gets a guidance. Typing "/ l o c <TAB>" does not
complete to anything.

Well, this decision is a trade-off between my permanent frustration of
not working parts of Tramp (and being blamed for this when I tried to
find a solution), and limiting users with a changed syntax. If you call
me guilty, then I'm guilty for not doing this change 15 years ago.

I believe it won't be too much bad feedback after people have understood
the change. Some years ago, the obscure /multi:ssh:host1:ssh:host2:
syntax was removed, even w/o an alternative. Later, the alternative
/ssh:host1|ssh:host2: was introduced. People did accept.

Of course, I'm biased, and there might have been a lot of frustration
from people because of that change. But then it didn't reach me.

Adding pure ange-ftp like syntax, as I have offered, seems to be a good
compromise for all of us.

And please take also into account, that I mean it seriously: if you
insist in keeping the syntax as it was, I will insist in seeing other
people working on Tramp. I'm the lonely maintainer since 2004, and there
are no remarkable contributions from somebody else except tramp-adb.el,
written by Juergen Hoetzel.

> Thanks,

Best regards, Michael.

Re: Change Tramp syntax

[John Wiegley]

>>>>> "MA" == Michael Albinus <michael.albinus@gmx.de> writes:

MA> I believe it won't be too much bad feedback after people have understood
MA> the change. Some years ago, the obscure /multi:ssh:host1:ssh:host2: syntax
MA> was removed, even w/o an alternative. Later, the alternative
MA> /ssh:host1|ssh:host2: was introduced. People did accept.

MA> Of course, I'm biased, and there might have been a lot of frustration from
MA> people because of that change. But then it didn't reach me.

I was one of those people, I just didn't complain when multihost was changed.
I'd never even heard about host1|host2 until today! I assumed multihost was
forever borked and had been using .ssh/config to manage multihops. It's great
to hear there's a way to use one-off multihops again. You just gave me a new
feature. :)

MA> Adding pure ange-ftp like syntax, as I have offered, seems to be a good
MA> compromise for all of us.

Yes, indeed!

MA> And please take also into account, that I mean it seriously: if you insist
MA> in keeping the syntax as it was, I will insist in seeing other people
MA> working on Tramp. I'm the lonely maintainer since 2004, and there are no
MA> remarkable contributions from somebody else except tramp-adb.el, written
MA> by Juergen Hoetzel.

I hear you, and I appreciate where you're coming from. On the flip side, I
also have to take all Emacs users into account. Not everyone knows whats going
on, or understands Tramp; and they want Emacs to just "continue working" as
much as possible, even while we improve things and right old wrongs.

Your proposed syntax fits this bill. In the meantime, I'll keep an eye out for
people who might be willing to contribute to Tramp. It's an essential package.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Change Tramp syntax

[Andreas Schwab]

On Apr 03 2017, Michael Albinus <michael.albinus@gmx.de> wrote:

> There's no need to use "-". You could always use "ssh" instead, if this
> annoys your eyes.

But that's not the same, "-" uses tramp-default-method.  Another problem
is that the new syntax is not backward compatible.  There is no way to
write a tramp file name that uses the default method and works with all
versions.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Change Tramp syntax

[Stefan Monnier]

> Maybe we shall start a poll, in emacs-devel, emacs-help and
> tramp-devel. We should not ask what a user prefers (many of them will
> prefer not to type a method). They question must be what will be broken
> if we stop support for ange-ftp syntax "/host:/path/to/file".

Actually, there are several options, for example:
1- Get rid of ange-ftp syntax altogether, like you propose.
2- Keep the syntax, but only when it doesn't collide with the
   Tramp syntax.  I.e. /fencepost:foo will still be allowed, but
   if you want to access a host named "ssh" you'll need something like
   /ftp:ssh:foo or /ssh:ssh:foo or /ssh.domain:foo or /user@ssh:foo.
   I.e. /foo: will only be considered ange-ftp syntax if `foo` is not a method.
3- Like 2 but treat /foo:./bar and /foo:/bar as an ange-ftp syntax even if
   `foo` is a method.

I never use ange-ftp syntax (although I only ever use the `ssh` method),
so I could live with 1 (and it sure would simplify the code), but I'm in
favor of option 2 because I think it is the simplest option that still
preserves the main benefit of the ange-ftp syntax (i.e. the default
method).

> This would also mean, that we cannot support default methods anymore. A
> file name with a default method would look like "/:host:/path/to/file",
> which is already the quoted file name syntax.

If really needed we could use something like `/-:host:`.


        Stefan

Re: Change Tramp syntax

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

Hi Stefan,

>> Maybe we shall start a poll, in emacs-devel, emacs-help and
>> tramp-devel. We should not ask what a user prefers (many of them will
>> prefer not to type a method). They question must be what will be broken
>> if we stop support for ange-ftp syntax "/host:/path/to/file".
>
> Actually, there are several options, for example:
> 1- Get rid of ange-ftp syntax altogether, like you propose.
> 2- Keep the syntax, but only when it doesn't collide with the
>    Tramp syntax.  I.e. /fencepost:foo will still be allowed, but
>    if you want to access a host named "ssh" you'll need something like
>    /ftp:ssh:foo or /ssh:ssh:foo or /ssh.domain:foo or /user@ssh:foo.
>    I.e. /foo: will only be considered ange-ftp syntax if `foo` is not a method.
> 3- Like 2 but treat /foo:./bar and /foo:/bar as an ange-ftp syntax even if
>    `foo` is a method.

Currently, we have implemented option 2. But the check, whether the host
name in /ssh:foo collides with a method, happens too late, because file
name handlers are fired by parsing the file name, and not by additional
checks (like a function call).

If we want to go this way, it must be option 1. Or must we allow file
name handlers to be activated by a function call, instead of merely
checking a regexp.

> I never use ange-ftp syntax (although I only ever use the `ssh` method),
> so I could live with 1 (and it sure would simplify the code), but I'm in
> favor of option 2 because I think it is the simplest option that still
> preserves the main benefit of the ange-ftp syntax (i.e. the default
> method).
>
>> This would also mean, that we cannot support default methods anymore. A
>> file name with a default method would look like "/:host:/path/to/file",
>> which is already the quoted file name syntax.
>
> If really needed we could use something like `/-:host:`.

Agreed. This preserves the default method, by the cost of additional
typing "- :". Let's see how much head wind there will be due to cutting
default method, and in case of we might offer this as compromise.

>         Stefan

Best regards, Michael.

Re: Change Tramp syntax

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sat, 11 Mar 2017 20:44:15 +0100
> Cc: emacs-devel@gnu.org
> 
> > 1- Get rid of ange-ftp syntax altogether, like you propose.
> > 2- Keep the syntax, but only when it doesn't collide with the
> >    Tramp syntax.  I.e. /fencepost:foo will still be allowed, but
> >    if you want to access a host named "ssh" you'll need something like
> >    /ftp:ssh:foo or /ssh:ssh:foo or /ssh.domain:foo or /user@ssh:foo.
> >    I.e. /foo: will only be considered ange-ftp syntax if `foo` is not a method.
> > 3- Like 2 but treat /foo:./bar and /foo:/bar as an ange-ftp syntax even if
> >    `foo` is a method.
> 
> Currently, we have implemented option 2. But the check, whether the host
> name in /ssh:foo collides with a method, happens too late, because file
> name handlers are fired by parsing the file name, and not by additional
> checks (like a function call).

Are the recent changes the reason that typing "C-x C-f ~/da" is now
followed by a perceptible delay, due to Tramp being auto-loaded?  This
used not to be the case.

Re: Change Tramp syntax

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Currently, we have implemented option 2. But the check, whether the host
>> name in /ssh:foo collides with a method, happens too late, because file
>> name handlers are fired by parsing the file name, and not by additional
>> checks (like a function call).
>
> Are the recent changes the reason that typing "C-x C-f ~/da" is now
> followed by a perceptible delay, due to Tramp being auto-loaded?  This
> used not to be the case.

"~/da" shall not invoke Tramp. But it does, indeed. If I call "emacs -Q"
and eval "M-x debug-on-entry RET load", then Tramp is already loaded
after typing "~/d". The reason is

  substitute-in-file-name("/d")
  rfn-eshadow-update-overlay()
  read-from-minibuffer("Find file: " "~/" (keymap (keymap (32)) keymap (10 . minibuffer-complete-and-exit) (13 . minibuffer-complete-and-exit) keymap (menu-bar keymap (minibuf "Minibuf" keymap (tab menu-item "Complete" minibuffer-complete :help "Complete as far as possible") (space menu-item "Complete Word" minibuffer-complete-word :help "Complete at most one word") (63 menu-item "List Completions" minibuffer-completion-help :help "Display all possible completions") "Minibuf")) (27 keymap (118 . switch-to-completions)) (prior . switch-to-completions) (63 . minibuffer-completion-help) (32 . minibuffer-complete-word) (9 . minibuffer-complete) keymap (menu-bar keymap (minibuf "Minibuf" keymap (previous menu-item "Previous History Item" previous-history-element :help "Put previous minibuffer history element in the minibuffer") (next menu-item "Next History Item" next-history-element :help "Put next minibuffer history element in the minibuffer") (isearch-backward menu-item "Isearch History Backward" isearch-backward :help "Incrementally search minibuffer history backward") (isearch-forward menu-item "Isearch History Forward" isearch-forward :help "Incrementally search minibuffer history forward") (return menu-item "Enter" exit-minibuffer :key-sequence "" :help "Terminate input and exit minibuffer") (quit menu-item "Quit" abort-recursive-edit :help "Abort input and exit minibuffer") "Minibuf")) (10 . exit-minibuffer) (13 . exit-minibuffer) (7 . abort-recursive-edit) (C-tab . file-cache-minibuffer-complete) (9 . self-insert-command) (XF86Back . previous-history-element) (up . previous-line-or-history-element) (prior . previous-history-element) (XF86Forward . next-history-element) (down . next-line-or-history-element) (next . next-history-element) (27 keymap (114 . previous-matching-history-element) (115 . next-matching-history-element) (112 . previous-history-element) (110 . next-history-element))) nil file-name-history "~/" nil)

The delay is not serious on my 7-years old T500 (less than half a
second). I don't know whether this counts as "perceptible".

Best regards, Michael.

Re: Change Tramp syntax

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Sat, 11 Mar 2017 21:31:00 +0100
> 
> > Are the recent changes the reason that typing "C-x C-f ~/da" is now
> > followed by a perceptible delay, due to Tramp being auto-loaded?  This
> > used not to be the case.
> 
> "~/da" shall not invoke Tramp. But it does, indeed. If I call "emacs -Q"
> and eval "M-x debug-on-entry RET load", then Tramp is already loaded
> after typing "~/d". The reason is
> 
>   substitute-in-file-name("/d")
>   rfn-eshadow-update-overlay()
>   read-from-minibuffer("Find file: " "~/" (keymap (keymap (32)) keymap (10 . m

Can we get rid of this somehow?  It used to be possible to avoid
loading Tramp when specifying local file names.

> The delay is not serious on my 7-years old T500 (less than half a
> second). I don't know whether this counts as "perceptible".

Well, if it wasn't perceptible, I wouldn't have paid attention...

Re: Change Tramp syntax

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> "~/da" shall not invoke Tramp. But it does, indeed. If I call "emacs -Q"
>> and eval "M-x debug-on-entry RET load", then Tramp is already loaded
>> after typing "~/d". The reason is
>> 
>>   substitute-in-file-name("/d")
>>   rfn-eshadow-update-overlay()
>>   read-from-minibuffer("Find file: " "~/" (keymap (keymap (32)) keymap (10 . m
>
> Can we get rid of this somehow?  It used to be possible to avoid
> loading Tramp when specifying local file names.

I'm just working on changing Tramp to require always a method. After
that, I'll check whether we could optimize the autoloads.

Best regards, Michael.

Re: Change Tramp syntax

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Sun, 12 Mar 2017 19:30:18 +0100
> 
> >>   substitute-in-file-name("/d")
> >>   rfn-eshadow-update-overlay()
> >>   read-from-minibuffer("Find file: " "~/" (keymap (keymap (32)) keymap (10 . m
> >
> > Can we get rid of this somehow?  It used to be possible to avoid
> > loading Tramp when specifying local file names.
> 
> I'm just working on changing Tramp to require always a method. After
> that, I'll check whether we could optimize the autoloads.

Thanks, looking forward for that.

Re: Change Tramp syntax

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Eli,

>>> "~/da" shall not invoke Tramp. But it does, indeed. If I call "emacs -Q"
>>> and eval "M-x debug-on-entry RET load", then Tramp is already loaded
>>> after typing "~/d". The reason is
>>> 
>>>   substitute-in-file-name("/d")
>>>   rfn-eshadow-update-overlay()
>>>   read-from-minibuffer("Find file: " "~/" (keymap (keymap (32))
>>> keymap (10 . m
>>
>> Can we get rid of this somehow?  It used to be possible to avoid
>> loading Tramp when specifying local file names.
>
> I'm just working on changing Tramp to require always a method. After
> that, I'll check whether we could optimize the autoloads.

Pls check; according to my tests, Tramp is loaded much later now.

A local file name should not cause Tramp being loaded except in case of
file name completion, when Tramp expects a file name "/foo" could be
extended to a remote file name.

Best regards, Michael.

Re: Change Tramp syntax

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Mon, 13 Mar 2017 18:23:45 +0100
> 
> >>> "~/da" shall not invoke Tramp. But it does, indeed. If I call "emacs -Q"
> >>> and eval "M-x debug-on-entry RET load", then Tramp is already loaded
> >>> after typing "~/d". The reason is
> >>> 
> >>>   substitute-in-file-name("/d")
> >>>   rfn-eshadow-update-overlay()
> >>>   read-from-minibuffer("Find file: " "~/" (keymap (keymap (32))
> >>> keymap (10 . m
> >>
> >> Can we get rid of this somehow?  It used to be possible to avoid
> >> loading Tramp when specifying local file names.
> >
> > I'm just working on changing Tramp to require always a method. After
> > that, I'll check whether we could optimize the autoloads.
> 
> Pls check; according to my tests, Tramp is loaded much later now.

What I see here is that it's loaded whenever file-name completion is
invoked by pressing TAB or RET.  Before that, it doesn't get loaded.
That's good progress, thanks.

> A local file name should not cause Tramp being loaded except in case of
> file name completion, when Tramp expects a file name "/foo" could be
> extended to a remote file name.

I have a directory ~/data.  Is it expected that typing "C-x C-f ~/dat TAB"
should load Tramp?  If that's expected, why is Tramp interested in
completions of such file names?

Thanks.

Re: Change Tramp syntax

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> A local file name should not cause Tramp being loaded except in case of
>> file name completion, when Tramp expects a file name "/foo" could be
>> extended to a remote file name.
>
> I have a directory ~/data.  Is it expected that typing "C-x C-f ~/dat TAB"
> should load Tramp?  If that's expected, why is Tramp interested in
> completions of such file names?

Tramp shouldn't be interested. "~" is in the way. I wrote "/foo".

> Thanks.

Best regards, Michael.

Re: Change Tramp syntax

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Mon, 13 Mar 2017 18:35:07 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> A local file name should not cause Tramp being loaded except in case of
> >> file name completion, when Tramp expects a file name "/foo" could be
> >> extended to a remote file name.
> >
> > I have a directory ~/data.  Is it expected that typing "C-x C-f ~/dat TAB"
> > should load Tramp?  If that's expected, why is Tramp interested in
> > completions of such file names?
> 
> Tramp shouldn't be interested. "~" is in the way. I wrote "/foo".

Sorry, I don't think I understand what you meant.  Does this mean you
think loading Tramp in the above case is unexpected, and will look
into this?  Or does this mean the presence of "~" somehow explains why
Tramp is loaded upon completion?  In the latter case, could you please
elaborate?

Thanks.

Re: Change Tramp syntax

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> > I have a directory ~/data.  Is it expected that typing "C-x C-f ~/dat TAB"
>> > should load Tramp?  If that's expected, why is Tramp interested in
>> > completions of such file names?
>> 
>> Tramp shouldn't be interested. "~" is in the way. I wrote "/foo".
>
> Sorry, I don't think I understand what you meant.  Does this mean you
> think loading Tramp in the above case is unexpected, and will look
> into this?  Or does this mean the presence of "~" somehow explains why
> Tramp is loaded upon completion?  In the latter case, could you please
> elaborate?

I meant that Tramp shall not be loaded in that case. I tried to
reproduce, starting emacs -Q, being in ~/, and typing "C-x C-f d a <TAB>".

And indeed, Tramp is loaded. Backtrace:

--8<---------------cut here---------------start------------->8---
  tramp-completion-file-name-handler(file-name-completion "da" "/home/albinmic/" file-exists-p)
  file-name-completion("da" "~/" file-exists-p)
  completion-file-name-table("~/da" file-exists-p nil)
  try-completion("~/da" completion-file-name-table file-exists-p)
--8<---------------cut here---------------end--------------->8---

Neither "da" nor "/home/albinmic/" shall trigger this. I'll check.

> Thanks.

Best regards, Michael.

Re: Change Tramp syntax

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Eli,

> Neither "da" nor "/home/albinmic/" shall trigger this. I'll check.

Should be better now with my latest patch. Could you pls check? It
requires to regenerate the autoload files.

>> Thanks.

Best regards, Michael.

Re: Change Tramp syntax

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Tue, 14 Mar 2017 15:13:37 +0100
> 
> > Neither "da" nor "/home/albinmic/" shall trigger this. I'll check.
> 
> Should be better now with my latest patch. Could you pls check?

Yes, the problem is gone now.  Thanks!

> It requires to regenerate the autoload files.

Happened automagically for me.

Re: Change Tramp syntax

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Tue, 14 Mar 2017 10:06:59 +0100
> 
> I meant that Tramp shall not be loaded in that case. I tried to
> reproduce, starting emacs -Q, being in ~/, and typing "C-x C-f d a <TAB>".
> 
> And indeed, Tramp is loaded. Backtrace:
> 
> --8<---------------cut here---------------start------------->8---
>   tramp-completion-file-name-handler(file-name-completion "da" "/home/albinmic/" file-exists-p)
>   file-name-completion("da" "~/" file-exists-p)
>   completion-file-name-table("~/da" file-exists-p nil)
>   try-completion("~/da" completion-file-name-table file-exists-p)
> --8<---------------cut here---------------end--------------->8---
> 
> Neither "da" nor "/home/albinmic/" shall trigger this. I'll check.

Thank you.

Re: Change Tramp syntax

[Stefan Monnier]

>>> Maybe we shall start a poll, in emacs-devel, emacs-help and
>>> tramp-devel. We should not ask what a user prefers (many of them will
>>> prefer not to type a method). They question must be what will be broken
>>> if we stop support for ange-ftp syntax "/host:/path/to/file".
>> Actually, there are several options, for example:
>> 1- Get rid of ange-ftp syntax altogether, like you propose.
>> 2- Keep the syntax, but only when it doesn't collide with the
>> Tramp syntax.  I.e. /fencepost:foo will still be allowed, but
>> if you want to access a host named "ssh" you'll need something like
>> /ftp:ssh:foo or /ssh:ssh:foo or /ssh.domain:foo or /user@ssh:foo.
>> I.e. /foo: will only be considered ange-ftp syntax if `foo` is not a method.
>> 3- Like 2 but treat /foo:./bar and /foo:/bar as an ange-ftp syntax even if
>> `foo` is a method.
> Currently, we have implemented option 2.

Hmm... then I don't understand why you need to handle completion differently
from non-completion.  Which cases currently misbehave if
tramp-completion-mode-p returns nil?

> But the check, whether the host name in /ssh:foo collides with
> a method, happens too late, because file name handlers are fired by
> parsing the file name, and not by additional checks (like a function
> call).

I don't understand this either.  Currently I see two Tramp entries in
f-n-h-alist:

 ("\\`/[^/]*\\'" . tramp-completion-file-name-handler)
 ("^/\\(\\(?:\\(?:\\([a-zA-Z_0-9-]+\\):\\)?\\(?:\\([^/|: 	]+\\)@\\)?\\(\\(?:[a-zA-Z0-9_.-]+\\|\\[\\(?:\\(?:\\(?:[a-zA-Z0-9]+\\)?:\\)+[a-zA-Z0-9.]+\\)?]\\)\\(?:#[0-9]+\\)?\\)?|\\)+\\)?\\(?:\\([a-zA-Z_0-9-]+\\):\\)?\\(?:\\([^/|: 	]+\\)@\\)?\\(\\(?:[a-zA-Z0-9_.-]+\\|\\[\\(?:\\(?:\\(?:[a-zA-Z0-9]+\\)?:\\)+[a-zA-Z0-9.]+\\)?]\\)\\(?:#[0-9]+\\)?\\)?:\\(.*$\\)" . tramp-file-name-handler)

Neither of those regexps seems to handle an /ssh: prefix differently
from a /host: prefix.


        Stefan

Re: Change Tramp syntax

[Michael Albinus]

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

Hi Stefan,

> I don't understand this either.  Currently I see two Tramp entries in
> f-n-h-alist:
>
>  ("\\`/[^/]*\\'" . tramp-completion-file-name-handler)
>  ("^/\\(\\(?:\\(?:\\([a-zA-Z_0-9-]+\\):\\)?\\(?:\\([^/|: 	]+\\)@\\)?\\(\\(?:[a-zA-Z0-9_.-]+\\|\\[\\(?:\\(?:\\(?:[a-zA-Z0-9]+\\)?:\\)+[a-zA-Z0-9.]+\\)?]\\)\\(?:#[0-9]+\\)?\\)?|\\)+\\)?\\(?:\\([a-zA-Z_0-9-]+\\):\\)?\\(?:\\([^/|: 	]+\\)@\\)?\\(\\(?:[a-zA-Z0-9_.-]+\\|\\[\\(?:\\(?:\\(?:[a-zA-Z0-9]+\\)?:\\)+[a-zA-Z0-9.]+\\)?]\\)\\(?:#[0-9]+\\)?\\)?:\\(.*$\\)" . tramp-file-name-handler)
>
> Neither of those regexps seems to handle an /ssh: prefix differently
> from a /host: prefix.

The first file name handler is intended to perform method, user name and
host name completion. It offers only handlers for `expand-file-name',
`file-name-all-completions' and `file-name-completion', everything else
will be handled either by `tramp-file-name-handler' (if the regexp
matches that handler), or by the native file name operation. In
`tramp-completion-handle-file-name-all-completions' it checks for both
possibilities, "/ssh:" and "/host:".

The second file name handler is intended to handle everything else. It
also performs a check, that a host name is not a method. But this is not
part of the regexp; this check is performed in
`tramp-maybe-open-connection', when a remote connection is being opened.

It would be preferable to extend the second regexp such a way, that
remote file names like "/ssh:whatever" are not allowed. But this is not
possible, because the method names to be excluded as host names are not
known at the time this file name handler is installed in
`file-name-handler-alist'.

If we discard ange-ftp syntax, the two entries would look like

("\\`/\\(-:\\)?[^:]*\\'" . tramp-completion-file-name-handler)

("\\`/[a-zA-Z_0-9-]+:\\([^/|: \t]+@\\)?[a-zA-Z0-9_.-]+:"
;;    method            user name      host name
 . tramp-file-name-handler)

The two regexps don't overlap any longer, which is the key.

Of course, the second regexp must be more complex, due to the multi-hop
syntax, due to Samba domains, due to IPv6 addresses, and due to port
numbers. But you see the idea.

>         Stefan

Best regards, Michael.

Re: Change Tramp syntax

[Stefan Monnier]

> The first file name handler is intended to perform method, user name and
> host name completion. It offers only handlers for `expand-file-name',
> `file-name-all-completions' and `file-name-completion', everything else
> will be handled either by `tramp-file-name-handler' (if the regexp
> matches that handler), or by the native file name operation.  In
> `tramp-completion-handle-file-name-all-completions' it checks for both
> possibilities, "/ssh:" and "/host:".
> The second file name handler is intended to handle everything else.  It
> also performs a check, that a host name is not a method.  But this is not
> part of the regexp; this check is performed in
> `tramp-maybe-open-connection', when a remote connection is being opened.

Right, so clearly the "is it a method name, or a host name" check is
performed in Elisp code, not in a regexp.  So what did you mean by:

    But the check, whether the host name in /ssh:foo collides with
    a method, happens too late, because file name handlers are fired by
    parsing the file name, and not by additional checks (like a function
    call).

?

> It would be preferable to extend the second regexp such a way, that
> remote file names like "/ssh:whatever" are not allowed.

Why?

Also, I'm still curious about:
What currently breaks if tramp-completion-mode-p always returns nil?


        Stefan

Re: Change Tramp syntax

[Michael Albinus]

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

Hi Stefan,

> Right, so clearly the "is it a method name, or a host name" check is
> performed in Elisp code, not in a regexp.  So what did you mean by:
>
>     But the check, whether the host name in /ssh:foo collides with
>     a method, happens too late, because file name handlers are fired by
>     parsing the file name, and not by additional checks (like a function
>     call).
>
> ?

When the Tramp file name handler is invoked, it is not clear whether
"ssh" is a method or a host name. "foo" could be part of a host name or
a local name.

>> It would be preferable to extend the second regexp such a way, that
>> remote file names like "/ssh:whatever" are not allowed.
>
> Why?
>
> Also, I'm still curious about:
> What currently breaks if tramp-completion-mode-p always returns nil?

Well, I have decided today to solve this for now and ever. I'm changing
Tramp that a method name is mandatory. A remote file name is now always

  /method:user@host:

"method" could be "-". The "user@" and "host" parts are optional.

Whoever wants to keep ange-ftp style syntax, is obliged to enter the
Tramp maintenance team ...

>         Stefan

Best regards, Michael.

Re: Change Tramp syntax

[Stefan Monnier]

>> What currently breaks if tramp-completion-mode-p always returns nil?
> Well, I have decided today to solve this for now and ever. I'm changing
> Tramp that a method name is mandatory.

Does it mean that tramp-completion-mode-p will disappear?


        Stefan

Re: Change Tramp syntax

[Michael Albinus]

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

>> Well, I have decided today to solve this for now and ever. I'm changing
>> Tramp that a method name is mandatory.
>
> Does it mean that tramp-completion-mode-p will disappear?

The function remains, but returns just the value of `non-essential'. Its
main use is to suppress opening an otherwise not established connection
in `tramp-maybe-open-connection'. Most of the other calls will be
removed.

Tramp won't use any heuristic anymore in order to decide, whether a new
connection could be opened, or not. It is up to the completion packages
to use this variable properly.

(In my ongoing tests I have reverted already setting `non-essential' in
`completion--nth-completion').

>         Stefan

Best regards, Michael.

Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

[Dmitry Gutov]

On 10.03.2017 12:00, Michael Albinus wrote:

> The only meaning of `non-essential' is to give Tramp a hint that we're
> in completion.

...which is non-essential.

> I haven't seen any other use of this variable since it
> has been introduced back in 2010.

We've been over this many times, and the "other use of this variable" is 
now present in company-mode and Ido.

Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

Hi Dmitry,

> On 10.03.2017 12:00, Michael Albinus wrote:
>
>> The only meaning of `non-essential' is to give Tramp a hint that we're
>> in completion.
>
> ...which is non-essential.

I don't understand. What do you mean?

>> I haven't seen any other use of this variable since it
>> has been introduced back in 2010.
>
> We've been over this many times,

Yes, and nobody has contributed an alternative solution to what I have
proposed.

> and the "other use of this variable"
> is now present in company-mode and Ido.

In ido? What else but giving a hint for Tramp do you mean there?

I cannot speak for company-mode, but I would be surprised if it changes
its behaviour depending on the value of `non-essential'.

Best regards, Michael.

Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

[Dmitry Gutov]

On 10.03.2017 12:36, Michael Albinus wrote:

>> ...which is non-essential.
> 
> I don't understand. What do you mean?

Like Stefan said, non-essential completion is one that happens "like in 
a background thread", or on idle timer, etc.

Which normally means "don't ask for password", but could also mean 
"don't try too hard generate completions too hard", e.g. in case there 
are multiple available algorithms, with different precision/time tradeoffs.

>> We've been over this many times,
> 
> Yes, and nobody has contributed an alternative solution to what I have
> proposed.

You are solving a problem which I don't really understand and probably 
never encountered (the syntax ambiguity of some sort).

On the other hand, the issue in company-mode which you visited and 
commented on discussed a problem that concerns actual users.

>> and the "other use of this variable"
>> is now present in company-mode and Ido.
> 
> In ido? What else but giving a hint for Tramp do you mean there?

It does just that.

> I cannot speak for company-mode, but I would be surprised if it changes
> its behaviour depending on the value of `non-essential'.

No, it binds the variable, according to the particular documented 
meaning of `non-essential', expecting corresponding behavior from Tramp.

Ignoring that and never asking for password during completion is not 
what we discussed there.

Re: [Emacs-diffs] master 37b88d7: Fix bug#23006

[Stefan Monnier]

> If you believe this is wrong, then Tramp needs another variable for such
> a trigger.  As we did agree originally in
> <http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-04/msg00371.html>.
> The idea to take `non-essential' instead came later from you.

IIUC the problem comes from the following:

1- in the process of performing completion, the completion code will end
   up using "subparts" of a filename.  More specifically, the user may
   write something like "/ssh:foo:bar" but the completion code somehow
   ends up invoking file functions (and hence Tramp) on "/ssh:foo".

2- For historical reasons, Tramp wants to allow users to write
   "/ssh:foo" to access files on the "ssh" host.

So in order for Tramp to figure out where the "/ssh:foo" that it
received should be treated as "foo on ssh" or as "incomplete host foo
via ssh", you need to try and figure out where we're in case 1 or case
2, and you try to do that using some heuristic, part of which is to look
at `non-essential'.

Sadly, `non-essential' is not there for that purpose, so it is only
somewhat correlated with the info you want, but is not a reliable
indicator (neither sufficient nor necessary).

I see 2 ways out of this problem:
- Introduce a new variable which indicates we're performing completion.
  I'm not sure exactly what "performing completion" means precisely,
  but maybe binding it in completion-file-name-table would be sufficient
  for Tramp's needs.
- Get rid of this historical syntax.  We could still accept "/ssh:./foo"
  (or maybe even "/ssh:foo/bar", tho this one looks more risky) to
  access the "ssh" host, which seems like a very minor annoyance.

I'm strongly in favor of the second option: while the ambiguity of
"/ssh:foo" is only known to bite us in the case of completion, I'd be
surprised if there aren't other cases where it hurts.  Also the way
Tramp currently behaves subtly differently while completing than in
other contexts is a source of complexity of bugs which I'd rather
eliminate (I remember some problems linked to such discrepancies around
file-name-directory).


        Stefan