Filename completion for the 'file widget

Filename completion for the 'file widget

[Suraj Acharya]

Completion for the 'file widget exhibits some slightly inconsistent 
behavior when using relative paths. widget-file-complete tries to expand 
  any relative paths using expand-file-name, but does so only when it 
can complete (partially or fully) the text in the widget.

So if at a file widget I type "./" and hit the completion key, I get a 
*Completions* buffer. Now if the current directory has a file called 
"aaa" and if I type the letter "a" into the file widget and hit the 
completion key again, instead of "./aaa" I get /home/foo/aaa".

While this can be fixed by calling expand-file-name even when listing 
completions in widget-file-complete, I think a customizable option to 
not expand relative paths in the file widget while still doing the 
completion would also be useful. The JDE mode for Java for example, uses 
a list of 'file widgets to customize its source and class path settings. 
It allows relative paths to permit easy portability of JDE projects 
across the file system.

Since I prefer this second non-expanding behavior I managed to get it to 
work on my local machine by using (concat directory completion) in place 
of (expand-file-name completion directory) in widget-file-complete.


Suraj

Re: Filename completion for the 'file widget

[Kevin Rodgers]

Suraj Acharya wrote:
 > Since I prefer this second non-expanding behavior I managed to get it to
 > work on my local machine by using (concat directory completion) in place
 > of (expand-file-name completion directory) in widget-file-complete.

That doesn't seem right.  I was going to suggest something like

	(file-relative-name (expand-file-name completion directory) directory)

but I realized that's equivalent to just completion, so I took a look
at the code in wid-edit.el.  But it's not clear to me (1) why
widget-file-complete expands the pattern nor (2) why it can safely
assume the pattern has a non-nil directory that can be passed as the
second arg to file-name-completion.

-- 
Kevin Rodgers

Re: Filename completion for the 'file widget

[Suraj Acharya]

Kevin Rodgers wrote:
> Suraj Acharya wrote:
>  > Since I prefer this second non-expanding behavior I managed to get it to
>  > work on my local machine by using (concat directory completion) in place
>  > of (expand-file-name completion directory) in widget-file-complete.
> 
> That doesn't seem right.  I was going to suggest something like

Why do you say it's not right? It gives me the behavior I expect, ie 
relative paths stay relative and I still get completion for them. It 
uses default-directory for the current buffer as the base for the 
relative path completion.

> 
>     (file-relative-name (expand-file-name completion directory) directory)
> 
> but I realized that's equivalent to just completion, so I took a look
> at the code in wid-edit.el.  But it's not clear to me (1) why
> widget-file-complete expands the pattern nor (2) why it can safely
> assume the pattern has a non-nil directory that can be passed as the
> second arg to file-name-completion.
> 

(2) is definitely a bug. Asking for completion in a blank 'file widget 
gives "let*: Wrong type argument: stringp, nil" in the minibuffer.

Re: Filename completion for the 'file widget

[Stefan]

>> work on my local machine by using (concat directory completion) in place
>> of (expand-file-name completion directory) in widget-file-complete.
> That doesn't seem right.

But I think it's the only good way.  The normal completion coe uses `concat'
as well.  It should really be something like
(concat (file-name-as-directory dir) completion) to be sure there's a / in
there, and I would argue that it should be made into a function.  Or maybe
change expand-file-name such that you can do something like
(expand-file-name file dir 'relativ)e to prevent `dir' from being
made absolute.

Many pieces of code use concat instead of expand-file-name.  90% of them
should use expand-file-name instead, but the rest can't because it's
important to keep the result non-absolute.  I myself remember settling for
`concat' in pcl-cvs, uniquify, and completion.


        Stefan

Re: Filename completion for the 'file widget

[Kevin Rodgers]

Suraj Acharya wrote:
 > Kevin Rodgers wrote:
 >> That doesn't seem right.  I was going to suggest something like
 >
 > Why do you say it's not right? It gives me the behavior I expect, ie
 > relative paths stay relative and I still get completion for them. It
 > uses default-directory for the current buffer as the base for the
 > relative path completion.

I was confusing the necessity of file-name-as-directory (which Stefan
correctly pointed out in his response) with the functionality of
expand-file-name.  Sorry!

...

 >> But it's not clear to me (1) why widget-file-complete expands the
 >> pattern nor (2) why it can safely assume the pattern has a non-nil
 >> directory that can be passed as the second arg to
 >> file-name-completion.
 >
 > (2) is definitely a bug. Asking for completion in a blank 'file widget
 > gives "let*: Wrong type argument: stringp, nil" in the minibuffer.

It looks to me like it would fail any time the widget doesn't contain
a directory separator, since e.g. (file-name-directory "foo") returns
nil.  (And isn't it file-name-completion that signals the error, not
let*?)

-- 
Kevin Rodgers

Re: Filename completion for the 'file widget

[Richard Stallman]

    Many pieces of code use concat instead of expand-file-name.  90% of them
    should use expand-file-name instead, but the rest can't because it's
    important to keep the result non-absolute.

It would be good to add explicit comments at the places that need to
keep the result non-absolute (and to change the others to use
expand-file-name).

Re: Filename completion for the 'file widget

[Suraj Acharya]

Kevin Rodgers wrote:

> Suraj Acharya wrote:
>  > Kevin Rodgers wrote:
>  >> That doesn't seem right.  I was going to suggest something like
>  >
>  > Why do you say it's not right? It gives me the behavior I expect, ie
>  > relative paths stay relative and I still get completion for them. It
>  > uses default-directory for the current buffer as the base for the
>  > relative path completion.
> 
> I was confusing the necessity of file-name-as-directory (which Stefan
> correctly pointed out in his response) with the functionality of
> expand-file-name.  Sorry!
> 
> ...

In this particular case I think file-name-as-directory isn't required 
because the directory name comes from file-name-directory which the docs 
hint might always add a file separator character at the end.


> 
>  >> But it's not clear to me (1) why widget-file-complete expands the
>  >> pattern nor (2) why it can safely assume the pattern has a non-nil
>  >> directory that can be passed as the second arg to
>  >> file-name-completion.
>  >
>  > (2) is definitely a bug. Asking for completion in a blank 'file widget
>  > gives "let*: Wrong type argument: stringp, nil" in the minibuffer.
> 
> It looks to me like it would fail any time the widget doesn't contain
> a directory separator, since e.g. (file-name-directory "foo") returns
> nil.  (And isn't it file-name-completion that signals the error, not
> let*?)

Yes, I was just indicating that there's at least one case where the code 
throws an error and so is buggy.

Suraj