* Filename completion for the 'file widget
@ 2004-08-24 0:59 Suraj Acharya
2004-08-25 0:04 ` Kevin Rodgers
0 siblings, 1 reply; 7+ messages in thread
From: Suraj Acharya @ 2004-08-24 0:59 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Filename completion for the 'file widget
2004-08-24 0:59 Filename completion for the 'file widget Suraj Acharya
@ 2004-08-25 0:04 ` Kevin Rodgers
2004-08-25 0:35 ` Suraj Acharya
2004-08-25 2:31 ` Stefan
0 siblings, 2 replies; 7+ messages in thread
From: Kevin Rodgers @ 2004-08-25 0:04 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Filename completion for the 'file widget
2004-08-25 0:04 ` Kevin Rodgers
@ 2004-08-25 0:35 ` Suraj Acharya
2004-08-25 16:33 ` Kevin Rodgers
2004-08-25 2:31 ` Stefan
1 sibling, 1 reply; 7+ messages in thread
From: Suraj Acharya @ 2004-08-25 0:35 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Filename completion for the 'file widget
2004-08-25 0:35 ` Suraj Acharya
@ 2004-08-25 16:33 ` Kevin Rodgers
2004-08-25 22:34 ` Suraj Acharya
0 siblings, 1 reply; 7+ messages in thread
From: Kevin Rodgers @ 2004-08-25 16:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Filename completion for the 'file widget
2004-08-25 16:33 ` Kevin Rodgers
@ 2004-08-25 22:34 ` Suraj Acharya
0 siblings, 0 replies; 7+ messages in thread
From: Suraj Acharya @ 2004-08-25 22:34 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Filename completion for the 'file widget
2004-08-25 0:04 ` Kevin Rodgers
2004-08-25 0:35 ` Suraj Acharya
@ 2004-08-25 2:31 ` Stefan
2004-08-25 20:35 ` Richard Stallman
1 sibling, 1 reply; 7+ messages in thread
From: Stefan @ 2004-08-25 2:31 UTC (permalink / raw)
Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Filename completion for the 'file widget
2004-08-25 2:31 ` Stefan
@ 2004-08-25 20:35 ` Richard Stallman
0 siblings, 0 replies; 7+ messages in thread
From: Richard Stallman @ 2004-08-25 20:35 UTC (permalink / raw)
Cc: ihs_4664, emacs-devel
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).
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-08-25 22:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-24 0:59 Filename completion for the 'file widget Suraj Acharya
2004-08-25 0:04 ` Kevin Rodgers
2004-08-25 0:35 ` Suraj Acharya
2004-08-25 16:33 ` Kevin Rodgers
2004-08-25 22:34 ` Suraj Acharya
2004-08-25 2:31 ` Stefan
2004-08-25 20:35 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).