Bug in file name completion

Bug in file name completion

[Lennart Borgman]

I have this file folder structure:

     c:/temp/eclean/
     c:/temp/ecvs/

When I do

    C-x C-f c:/temp/, TAB

it just completes to "c:/temp/eclean" instead of showing the 
alternatives. Testing a bit more it seems like the counting is wrong. 
Two alternatives completes immediately.

This is on w32, CVS Emacs from 2005-11-15.

Re: Bug in file name completion

[Richard M. Stallman]

	 c:/temp/eclean/
	 c:/temp/ecvs/

    When I do

	C-x C-f c:/temp/, TAB

    it just completes to "c:/temp/eclean" instead of showing the 
    alternatives.

I wonder if that is due to spuriously matching the "CVS/" element of
completion-ignored-extensions.  Maybe we need to change that to "/CVS/".

Re: Bug in file name completion

[Lennart Borgman]

Richard M. Stallman wrote:

>	 c:/temp/eclean/
>	 c:/temp/ecvs/
>
>    When I do
>
>	C-x C-f c:/temp/, TAB
>
>    it just completes to "c:/temp/eclean" instead of showing the 
>    alternatives.
>
>I wonder if that is due to spuriously matching the "CVS/" element of
>completion-ignored-extensions.  Maybe we need to change that to "/CVS/".
>  
>
The documentation says that

    Directories are ignored if they match any string in this list which
    ends in a slash.

It does not say that directories ending in any of those strings are 
ignored. However the code in file_name_completion (in dired.c) looks too 
me like it ignores directories ending in those strings.

Which is the intended behaviour?

Re: Bug in file name completion

[Eli Zaretskii]

> Date: Wed, 16 Nov 2005 23:45:44 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: emacs-devel@gnu.org
> 
> Richard M. Stallman wrote:
> 
> >	 c:/temp/eclean/
> >	 c:/temp/ecvs/
> >
> >    When I do
> >
> >	C-x C-f c:/temp/, TAB
> >
> >    it just completes to "c:/temp/eclean" instead of showing the 
> >    alternatives.
> >
> >I wonder if that is due to spuriously matching the "CVS/" element of
> >completion-ignored-extensions.  Maybe we need to change that to "/CVS/".
> >  
> >
> The documentation says that
> 
>     Directories are ignored if they match any string in this list which
>     ends in a slash.
> 
> It does not say that directories ending in any of those strings are 
> ignored. However the code in file_name_completion (in dired.c) looks too 
> me like it ignores directories ending in those strings.
> 
> Which is the intended behaviour?

Wed had a thread about this in the past.  It started in the end of
December 2003 and continued in January 2004.  The subject was "CVS
directories in completion-ignored-extensions".  The "/CVS/" solution
was proposed then, but Richard proposed a different solution that he
liked better.

I suggest we read that thread before deciding what to do with this.

Re: Bug in file name completion

[Lennart Borgman]

Eli Zaretskii wrote:

>>>	 c:/temp/eclean/
>>>	 c:/temp/ecvs/
>>>
>>>   When I do
>>>
>>>	C-x C-f c:/temp/, TAB
>>>
>>>   it just completes to "c:/temp/eclean" instead of showing the 
>>>   alternatives.
>>>
>>>I wonder if that is due to spuriously matching the "CVS/" element of
>>>completion-ignored-extensions.  Maybe we need to change that to "/CVS/".
>>> 
>>>
>>>      
>>>
>>The documentation says that
>>
>>    Directories are ignored if they match any string in this list which
>>    ends in a slash.
>>
>>It does not say that directories ending in any of those strings are 
>>ignored. However the code in file_name_completion (in dired.c) looks too 
>>me like it ignores directories ending in those strings.
>>
>>Which is the intended behaviour?
>>    
>>
>
>Wed had a thread about this in the past.  It started in the end of
>December 2003 and continued in January 2004.  The subject was "CVS
>directories in completion-ignored-extensions".  The "/CVS/" solution
>was proposed then, but Richard proposed a different solution that he
>liked better.
>  
>
Reading the thread it seems to me that everyone liked Miles suggestion: 
http://lists.gnu.org/archive/html/emacs-devel/2004-01/msg00093.html

However a better name for the function were needed according to Richard. 
Maybe string-match-any?

Handa said that maybe this needed to be implemented in C.

Re: Bug in file name completion

[Miles Bader]

2005/11/17, Lennart Borgman <lennart.borgman.073@student.lu.se>:
> Reading the thread it seems to me that everyone liked Miles suggestion:
> http://lists.gnu.org/archive/html/emacs-devel/2004-01/msg00093.html
>
> However a better name for the function were needed according to Richard.
> Maybe string-match-any?

"string-match-pattern"?

"string-match-list"?

[The term "pattern" may already be taken though:  In the recent
changes to apropos, Richard used the term "pattern" to refer to the
new "regexp if it's a string, list of constant strings-to-match if
it's a list" datatype.

The two concepts aren't really incompatible; maybe they could even be
unified, but that's arguably forcing things too much.]

-miles
--
Do not taunt Happy Fun Ball.

Re: Bug in file name completion

[Miles Bader]

Actually, now that I think about it, I've decided I prefer Lennart's
suggestion to the two I made -- I had been thinking about the
"pattern" argument to the function as a "thing" to be matched, but
Lennart's name emphasizes that it's really a bunch of alternatives.

I think it would read well in source code too:

   (when (string-match-any name possible-names)
      ... do something ...)

-miles
--
Do not taunt Happy Fun Ball.

Re: Bug in file name completion

[Richard M. Stallman]

    It does not say that directories ending in any of those strings are 
    ignored. However the code in file_name_completion (in dired.c) looks too 
    me like it ignores directories ending in those strings.

    Which is the intended behaviour?

The intended behavior is the current behavior.  Every element of
completion-ignored-extensions does a suffix match.

We could consider changing that behavior, but that is what was intended.

If this is always matched against absolute file names, then we don't
need to change the way the variable's value is used.  We only need to change
the default value.  But if it is sometimes matched against file names
without directory parts, we need to change the way the name is interpreted,
somehow.

Re: Bug in file name completion

[Richard M. Stallman]

    Wed had a thread about this in the past.  It started in the end of
    December 2003 and continued in January 2004.  The subject was "CVS
    directories in completion-ignored-extensions".  The "/CVS/" solution
    was proposed then, but Richard proposed a different solution that he
    liked better.

I think the other solution was this:

    I've always thought it would be nice, instead of having multiple variables
    each of which contain a different types of entry, to have something like
    `completion-ignored-names', where each element could be either: a string
    (which is matched using just `equal'), or a list like (regexp REGEXP),
    which the matcher would treat accordingly.

I still think that is a good idea.

    Reading the thread it seems to me that everyone liked Miles suggestion: 
    http://lists.gnu.org/archive/html/emacs-devel/2004-01/msg00093.html

    However a better name for the function were needed according to Richard. 
    Maybe string-match-any?

I think string-match-extended is a better name for it.
It probably should be implemented in C, for use by completion.