bug#4004: filename completion

bug#4004: filename completion

[Colin Williams]

In 23.1.50.1, there's a bad interaction between tab completion and
tramp filenames.  If you try to do tab completion on
"/ssh:remote-host:~/~/te", where the file "test" exists on the remote
host but not locally, the completion says there's no match.

Colin

bug#4004: filename completion

[Michael Albinus]

Colin Williams <lackita@gmail.com> writes:

> In 23.1.50.1, there's a bad interaction between tab completion and
> tramp filenames.  If you try to do tab completion on
> "/ssh:remote-host:~/~/te", where the file "test" exists on the remote
> host but not locally, the completion says there's no match.

For me, it works.

What happens if you try to complete "/ssh:remote-host:~/te"?

Has the file "test" been created on the remote host outside Emacs, while
Tramp was running already?

Have you enabled partial-completion-mode, which is needed for Tramp
sometimes?

> Colin

Best regards, Michael.

bug#4004: filename completion

[Stefan Monnier]

> Have you enabled partial-completion-mode, which is needed for Tramp
> sometimes?

Note that partial-completion-mode is on the way out, so if you need
partial-completion-mode to make it work, it's important to know it.


        Stefan

bug#4004: filename completion

[Michael Albinus]

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

>> Have you enabled partial-completion-mode, which is needed for Tramp
>> sometimes?
>
> Note that partial-completion-mode is on the way out, so if you need
> partial-completion-mode to make it work, it's important to know it.

I must check the code, but IIRC partial-completion-mode is just an
indication for Tramp whether some file name completion functionality
shall be enabled, before Tramp is fully loaded. There were people who
disliked Tramp's file name completion.

If partial-completion-mode will be kicked off, Tramp might need another
indication. Just tell me when it happens, that I can change Tramp.

Just now?

>         Stefan

Best regards, Michael.

bug#4004: filename completion

[Stefan Monnier]

>>> Have you enabled partial-completion-mode, which is needed for Tramp
>>> sometimes?
>> 
>> Note that partial-completion-mode is on the way out, so if you need
>> partial-completion-mode to make it work, it's important to know it.

> I must check the code, but IIRC partial-completion-mode is just an
> indication for Tramp whether some file name completion functionality
> shall be enabled, before Tramp is fully loaded. There were people who
> disliked Tramp's file name completion.

Then this needs to be fixed.  Looking at the code, I can't quite
understand what it does: it seems that Tramp's method/user/host
completion is only activated for people you use either
partial-completion-mode, ido, icycle, or XEmacs.  I'm not sure what's
the logic behind it, but I'd rather just activate it based on a specific
configuration variable (or just always activate it, as you do in
XEmacs).  In Emacs-23, the functionality that was previous offered by
partial-completion-mode is enabled by default (tho implemented
differently and activated differently as well).


        Stefan

bug#4004: filename completion

[Michael Albinus]

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

[added emacs-devel, we shall continue to discuss there]

>> I must check the code, but IIRC partial-completion-mode is just an
>> indication for Tramp whether some file name completion functionality
>> shall be enabled, before Tramp is fully loaded. There were people who
>> disliked Tramp's file name completion.
>
> Then this needs to be fixed.  Looking at the code, I can't quite
> understand what it does: it seems that Tramp's method/user/host
> completion is only activated for people you use either
> partial-completion-mode, ido, icycle, or XEmacs.  I'm not sure what's
> the logic behind it, but I'd rather just activate it based on a specific
> configuration variable (or just always activate it, as you do in
> XEmacs).  In Emacs-23, the functionality that was previous offered by
> partial-completion-mode is enabled by default (tho implemented
> differently and activated differently as well).

There was a discussion about some years ago, when I did add Tramp's
autoloads. People were annoyed, that even after typing something like
"/a" in the minibuffer, Tramp was already loaded, which raised some
delays. So it was suggested to make Tramp's autoloading optional. It was
even requested that this "optionality" should not be something, which
the user has to disnable herself; users should not be bashed by a new
feature they are not interested in.

The compromise was to find indications, were it could be expected that
the user would appreciate Tramp. partial-completion-mode was the first
candidate, ido and icycle were added later. The XEmacs case is
different, because there is another syntax for Tramp.

If partial-completion-mode is discarded in Emacs, we should either find
a replacement for this "indication", or we shall decide, that Tramp *is*
always loaded as soon as somebody writes an absolute filename in the
minibuffer.

The check for partial-completion-mode shall remain in tramp.el, for
backward compatibility.

>         Stefan

Best regards, Michael.

Re: bug#4004: filename completion

[Michael Albinus]

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

[added emacs-devel, we shall continue to discuss there]

>> I must check the code, but IIRC partial-completion-mode is just an
>> indication for Tramp whether some file name completion functionality
>> shall be enabled, before Tramp is fully loaded. There were people who
>> disliked Tramp's file name completion.
>
> Then this needs to be fixed.  Looking at the code, I can't quite
> understand what it does: it seems that Tramp's method/user/host
> completion is only activated for people you use either
> partial-completion-mode, ido, icycle, or XEmacs.  I'm not sure what's
> the logic behind it, but I'd rather just activate it based on a specific
> configuration variable (or just always activate it, as you do in
> XEmacs).  In Emacs-23, the functionality that was previous offered by
> partial-completion-mode is enabled by default (tho implemented
> differently and activated differently as well).

There was a discussion about some years ago, when I did add Tramp's
autoloads. People were annoyed, that even after typing something like
"/a" in the minibuffer, Tramp was already loaded, which raised some
delays. So it was suggested to make Tramp's autoloading optional. It was
even requested that this "optionality" should not be something, which
the user has to disnable herself; users should not be bashed by a new
feature they are not interested in.

The compromise was to find indications, were it could be expected that
the user would appreciate Tramp. partial-completion-mode was the first
candidate, ido and icycle were added later. The XEmacs case is
different, because there is another syntax for Tramp.

If partial-completion-mode is discarded in Emacs, we should either find
a replacement for this "indication", or we shall decide, that Tramp *is*
always loaded as soon as somebody writes an absolute filename in the
minibuffer.

The check for partial-completion-mode shall remain in tramp.el, for
backward compatibility.

>         Stefan

Best regards, Michael.

bug#4004: filename completion

[Stefan Monnier]

> There was a discussion about some years ago, when I did add Tramp's
> autoloads. People were annoyed, that even after typing something like
> "/a" in the minibuffer, Tramp was already loaded, which raised some
> delays. So it was suggested to make Tramp's autoloading optional. It was
> even requested that this "optionality" should not be something, which
> the user has to disnable herself; users should not be bashed by a new
> feature they are not interested in.

That's beginning to make more sense.  But I just tried the following:

   emacs -Q
   C-x C-f /a TAB :

and then

   emacs -Q
   M-: (setq partial-completion-mode t)
   C-x C-f /a TAB :

and I don't see any difference (Tramp gets loaded when I hit : and no
earlier).  Could you show me another example where I can see
the difference, so I can better understand the tradeoffs?


        Stefan

Re: bug#4004: filename completion

[Stefan Monnier]

> There was a discussion about some years ago, when I did add Tramp's
> autoloads. People were annoyed, that even after typing something like
> "/a" in the minibuffer, Tramp was already loaded, which raised some
> delays. So it was suggested to make Tramp's autoloading optional. It was
> even requested that this "optionality" should not be something, which
> the user has to disnable herself; users should not be bashed by a new
> feature they are not interested in.

That's beginning to make more sense.  But I just tried the following:

   emacs -Q
   C-x C-f /a TAB :

and then

   emacs -Q
   M-: (setq partial-completion-mode t)
   C-x C-f /a TAB :

and I don't see any difference (Tramp gets loaded when I hit : and no
earlier).  Could you show me another example where I can see
the difference, so I can better understand the tradeoffs?


        Stefan

bug#4004: filename completion

[Lennart Borgman]

> and I don't see any difference (Tramp gets loaded when I hit : and no
> earlier).  Could you show me another example where I can see
> the difference, so I can better understand the tradeoffs?

When : is hit? That or something close to it might explain a bug I see
sometimes on w32. Tramp gets loaded when doing local file name
completion. Though it has something to do with my customization too,
it does not happen for "emacs -Q". I have not had time  to track it
down.

Re: bug#4004: filename completion

[Lennart Borgman]

> and I don't see any difference (Tramp gets loaded when I hit : and no
> earlier).  Could you show me another example where I can see
> the difference, so I can better understand the tradeoffs?

When : is hit? That or something close to it might explain a bug I see
sometimes on w32. Tramp gets loaded when doing local file name
completion. Though it has something to do with my customization too,
it does not happen for "emacs -Q". I have not had time  to track it
down.

Re: filename completion

[Michael Albinus]

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

>> There was a discussion about some years ago, when I did add Tramp's
>> autoloads. People were annoyed, that even after typing something like
>> "/a" in the minibuffer, Tramp was already loaded, which raised some
>> delays. So it was suggested to make Tramp's autoloading optional. It was
>> even requested that this "optionality" should not be something, which
>> the user has to disnable herself; users should not be bashed by a new
>> feature they are not interested in.
>
> That's beginning to make more sense.  But I just tried the following:
>
>    emacs -Q
>    C-x C-f /a TAB :
>
> and then
>
>    emacs -Q
>    M-: (setq partial-completion-mode t)
>    C-x C-f /a TAB :
>
> and I don't see any difference (Tramp gets loaded when I hit : and no
> earlier).  Could you show me another example where I can see
> the difference, so I can better understand the tradeoffs?

You are right, partial-completion-mode is out of the game. No idea why.
You can see the effect with

   emacs -Q
   M-x ido-mode
   C-x C-f /s

Tramp is loaded after typing s, and you see all possible methods for
expanding.

>         Stefan

Best regards, Michael.

Re: bug#4004: filename completion

[Michael Albinus]

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

>> There was a discussion about some years ago, when I did add Tramp's
>> autoloads. People were annoyed, that even after typing something like
>> "/a" in the minibuffer, Tramp was already loaded, which raised some
>> delays. So it was suggested to make Tramp's autoloading optional. It was
>> even requested that this "optionality" should not be something, which
>> the user has to disnable herself; users should not be bashed by a new
>> feature they are not interested in.
>
> That's beginning to make more sense.

Would it be OK to add the check 

  (and (boundp 'completion-styles)
       (member 'partial-completion (symbol-value 'completion-styles)))

as indication to enable method, user, hostname completion?

>         Stefan

Best regards, Michael.

Re: bug#4004: filename completion

[Stefan Monnier]

>>> There was a discussion about some years ago, when I did add Tramp's
>>> autoloads. People were annoyed, that even after typing something like
>>> "/a" in the minibuffer, Tramp was already loaded, which raised some
>>> delays. So it was suggested to make Tramp's autoloading optional. It was
>>> even requested that this "optionality" should not be something, which
>>> the user has to disnable herself; users should not be bashed by a new
>>> feature they are not interested in.
>> That's beginning to make more sense.
> Would it be OK to add the check 
>   (and (boundp 'completion-styles)
>        (member 'partial-completion (symbol-value 'completion-styles)))

You mean

   (and (boundp 'completion-styles)
        (member 'partial-completion completion-styles))

?

Yes, I guess it'd be OK, tho I think you might as well enable
it unconditionally, since AFAICT it doesn't impact the autoloading
behavior, only the completion behavior (i.e. after C-x C-f /s TAB you
don't get "ssh:" before Tramp is loaded, but you do after Tramp has
been loaded).


        Stefan

Re: bug#4004: filename completion

[Michael Albinus]

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

>> Would it be OK to add the check 
>>   (and (boundp 'completion-styles)
>>        (member 'partial-completion (symbol-value 'completion-styles)))
>
> You mean
>
>    (and (boundp 'completion-styles)
>         (member 'partial-completion completion-styles))
>
> ?

Yes, I mean that. My version avoids compiler warnings for unknown
symbol completion-styles, when Tramp runs outside GNU Emacs 23.

> Yes, I guess it'd be OK, tho I think you might as well enable
> it unconditionally, since AFAICT it doesn't impact the autoloading
> behavior, only the completion behavior (i.e. after C-x C-f /s TAB you
> don't get "ssh:" before Tramp is loaded, but you do after Tramp has
> been loaded).

I'll do so. Wrt autoloading: for some people it makes a difference,
whether Tramp is loaded after typing "/ssh:", or already after typing "/s".

Since partial-completion is enabled by default in completion-styles,
Tramp will always be autoloaded after typing "/s". But people have a
chance to disable this behaviour.

>         Stefan

Best regards, Michael.

Re: bug#4004: filename completion

[Chong Yidong]

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

>>> Would it be OK to add the check
>>>   (and (boundp 'completion-styles)
>>>        (member 'partial-completion (symbol-value 'completion-styles)))
>>
>> You mean
>>
>>    (and (boundp 'completion-styles)
>>         (member 'partial-completion completion-styles))
>>
>> ?
>
> Yes, I mean that. My version avoids compiler warnings for unknown
> symbol completion-styles, when Tramp runs outside GNU Emacs 23.

The byte-compiler is smart enough to recognize this situation and avoid
warning about it.

RE: bug#4004: filename completion

[Drew Adams]

> > Yes, I mean that. My version avoids compiler warnings for unknown
> > symbol completion-styles, when Tramp runs outside GNU Emacs 23.
> 
> The byte-compiler is smart enough to recognize this situation 
> and avoid warning about it.

I think Michael was speaking about byte-compiling using other that GNU Emacs 23.

Here's what GNU Emacs 20 says, for instance:

(defun foo ()
  (and (boundp 'completion-styles)
       (member 'partial-completion completion-styles)))
(byte-compile 'foo)

** reference to free variable completion-styles

Re: bug#4004: filename completion

[Stefan Monnier]

> Yes, I mean that.  My version avoids compiler warnings for unknown
> symbol completion-styles, when Tramp runs outside GNU Emacs 23.

I know and I hate such code: fix the compiler, or live with the warning,
but don't botch your code to work around the "problem".

>> Yes, I guess it'd be OK, tho I think you might as well enable
>> it unconditionally, since AFAICT it doesn't impact the autoloading
>> behavior, only the completion behavior (i.e. after C-x C-f /s TAB you
>> don't get "ssh:" before Tramp is loaded, but you do after Tramp has
>> been loaded).

> I'll do so. Wrt autoloading: for some people it makes a difference,
> whether Tramp is loaded after typing "/ssh:", or already after typing "/s".

I know.  But AFAIK, the code you suggest wouldn't make any difference in
this respect.  At least setting partial-completion-mode currently
doesn't make any difference in this respect.

> Since partial-completion is enabled by default in completion-styles,
> Tramp will always be autoloaded after typing "/s".

Would it?  If so, why isn't it when partial-completion-mode is set to
t in Emacs-23.1?


        Stefan

Re: bug#4004: filename completion

[Michael Albinus]

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

>> I'll do so. Wrt autoloading: for some people it makes a difference,
>> whether Tramp is loaded after typing "/ssh:", or already after typing "/s".
>
> I know.  But AFAIK, the code you suggest wouldn't make any difference in
> this respect.  At least setting partial-completion-mode currently
> doesn't make any difference in this respect.
>
>> Since partial-completion is enabled by default in completion-styles,
>> Tramp will always be autoloaded after typing "/s".
>
> Would it?  If so, why isn't it when partial-completion-mode is set to
> t in Emacs-23.1?

See loaddefs.el:

(add-hook
 'after-init-hook
 'tramp-register-completion-file-name-handler)

So you must put (partial-completion-mode 1) in your .emacs. But now,
since `partial-completion' is set in `completion-styles' by default, you
don't need to do this anymore, you'll see early Tramp loading already
when starting emacs -Q.

>         Stefan

Best regards, Michael.

Re: bug#4004: filename completion

[Stefan Monnier]

> So you must put (partial-completion-mode 1) in your .emacs. But now,
> since `partial-completion' is set in `completion-styles' by default, you
> don't need to do this anymore, you'll see early Tramp loading already
> when starting emacs -Q.

Ah, I see, so it's not a good idea: we're back with the problem that in
a vanilla Emacs, "/s" is enough to cause tramp to be autoloaded.


        Stefan

Re: bug#4004: filename completion

[Michael Albinus]

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

>> So you must put (partial-completion-mode 1) in your .emacs. But now,
>> since `partial-completion' is set in `completion-styles' by default, you
>> don't need to do this anymore, you'll see early Tramp loading already
>> when starting emacs -Q.
>
> Ah, I see, so it's not a good idea: we're back with the problem that in
> a vanilla Emacs, "/s" is enough to cause tramp to be autoloaded.

Yes. But it is a little bit different: since Emacs 22 we have said (and
documented), that Tramp's host name completion is bound with partial
completion. The difference is that partial completion is enabled now by
default (with a different mean, completion-styles).

So it is not *exactly* the same problem. But it looks like :-(

From my point of view, we could let it as it is. People who dislike
partial completion need to disable it now anyway.

>         Stefan

Best regards, Michael.

Re: bug#4004: filename completion

[David Kastrup]

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

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> So you must put (partial-completion-mode 1) in your .emacs. But now,
>>> since `partial-completion' is set in `completion-styles' by default, you
>>> don't need to do this anymore, you'll see early Tramp loading already
>>> when starting emacs -Q.
>>
>> Ah, I see, so it's not a good idea: we're back with the problem that in
>> a vanilla Emacs, "/s" is enough to cause tramp to be autoloaded.
>
> Yes. But it is a little bit different: since Emacs 22 we have said (and
> documented), that Tramp's host name completion is bound with partial
> completion. The difference is that partial completion is enabled now by
> default (with a different mean, completion-styles).
>
> So it is not *exactly* the same problem. But it looks like :-(
>
> From my point of view, we could let it as it is. People who dislike
> partial completion need to disable it now anyway.

Partial completion completes word constituents.  I find it acceptable if
method completion works only after :, so that we have

/s: TAB

offer completion for the method first, filenames afterwards.  The
details are left for the reader...

-- 
David Kastrup

Re: bug#4004: filename completion

[Stefan Monnier]

>> Yes. But it is a little bit different: since Emacs 22 we have said (and
>> documented), that Tramp's host name completion is bound with partial
>> completion. The difference is that partial completion is enabled now by
>> default (with a different mean, completion-styles).

Yes, but the reason we did that was that we did not want a vanilla Emacs
to load Tramp so eagerly.

>> From my point of view, we could let it as it is.  People who dislike
>> partial completion need to disable it now anyway.

Very few people will disable it (it's been tamed specifically to that end).

> Partial completion completes word constituents.  I find it acceptable if
> method completion works only after :, so that we have

> /s: TAB

> offer completion for the method first, filenames afterwards.  The
> details are left for the reader...

Sadly my reader is out for lunch, can you help me understand how that
would work?  What kind of interaction do you expect?

I was originally thinking that we could use partial-completion here.
Basically, just like "/u/ TAB" can try to complete to /usr/ (after
checking that there's no /u), we could have "/s: TAB" try to complete to
/ssh:, but there's a problem: we'd need to "check that there's no /s",
which in our case means check that there's no host named "s" (since
/s:filename would refer to a filename on host s).  If we get rid of
ange-ftp's /host: syntax and force the use of something like /ftp:, then
maybe we can get something working.


        Stefan

Re: bug#4004: filename completion

[Michael Albinus]

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

> I was originally thinking that we could use partial-completion here.
> Basically, just like "/u/ TAB" can try to complete to /usr/ (after
> checking that there's no /u), we could have "/s: TAB" try to complete to
> /ssh:, but there's a problem: we'd need to "check that there's no /s",
> which in our case means check that there's no host named "s" (since
> /s:filename would refer to a filename on host s).  If we get rid of
> ange-ftp's /host: syntax and force the use of something like /ftp:, then
> maybe we can get something working.

Tramp does something similar already. If you type "/s TAB", you get
offered "/sbin", "/ssh:" (a method), "/stefan@" (a user) and "/somehost:"
(a hostname).

David's proposal is just more consequent in working partial completion
like partial completion ought to do. Interesting idea.

"/s TAB" and "/s/ TAB" would only complete to "/sbin". "/s: TAB" would
complete to "/ssh:" and "/somehost:". And "/s@ TAB" would complete to
"/stefan@".

Nice idea.

>         Stefan

Best regards, Michael.

Re: bug#4004: filename completion

[Stefan Monnier]

> "/s TAB" and "/s/ TAB" would only complete to "/sbin". "/s: TAB" would
> complete to "/ssh:" and "/somehost:". And "/s@ TAB" would complete to
> "/stefan@".

That's pretty much what I was talking about, yes.
But how do you decide whether "/s: TAB" should complete to "/ssh:" or to
the list of files available on host "s"?


        Stefan

Re: bug#4004: filename completion

[David Kastrup]

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

>> "/s TAB" and "/s/ TAB" would only complete to "/sbin". "/s: TAB" would
>> complete to "/ssh:" and "/somehost:". And "/s@ TAB" would complete to
>> "/stefan@".
>
> That's pretty much what I was talking about, yes.
> But how do you decide whether "/s: TAB" should complete to "/ssh:" or to
> the list of files available on host "s"?

The list of files on Drive S:...

-- 
David Kastrup

bug#4004: marked as done (filename completion)

[Emacs bug Tracking System]

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


Your message dated Mon, 03 Aug 2009 10:29:49 +0200
with message-id <nqvdl5e1vm.fsf@alcatel-lucent.de>
and subject line Re: bug#4004: filename completion
has caused the Emacs bug report #4004,
regarding filename completion
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
4004: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4004
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3076 bytes --]

From: Colin Williams <lackita@gmail.com>
To: bug-gnu-emacs@gnu.org
Subject: filename completion
Date: Sat, 1 Aug 2009 12:36:44 -0400
Message-ID: <1b97198a0908010936o1f0b2015w8405a82648a5f869@mail.gmail.com>

In 23.1.50.1, there's a bad interaction between tab completion and
tramp filenames.  If you try to do tab completion on
"/ssh:remote-host:~/~/te", where the file "test" exists on the remote
host but not locally, the completion says there's no match.

Colin



[-- Attachment #3: Type: message/rfc822, Size: 2439 bytes --]

From: Michael Albinus <michael.albinus@gmx.de>
To: Colin Williams <lackita@gmail.com>
Cc: <4004-done@emacsbugs.donarmstrong.com>
Subject: Re: bug#4004: filename completion
Date: Mon, 03 Aug 2009 10:29:49 +0200
Message-ID: <nqvdl5e1vm.fsf@alcatel-lucent.de>

Colin Williams <lackita@gmail.com> writes:

> So partial completion mode seems to fix the problem.  I thought
> graying out the irrelevant parts of the path was a handy feature, but
> I don't really mind doing without it.

I don't completely understand what you mean with your remark about
"graying out the irrelevant parts", but there was an error, indeed (it
didn't mark parts starting with tilde). I've committed a fix to the
trunk.

Besides this, I believe there is no problem anymore, so I have set this
bug to resolved.

> Cheers,
> Colin

Best regards, Michael.