|
From: | Suraj Acharya |
Subject: | Re: Filename completion for the 'file widget |
Date: | Wed, 25 Aug 2004 15:34:08 -0700 |
User-agent: | Mozilla Thunderbird 0.7.1 (Windows/20040626) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |