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