Re: find-file-project

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Indeed, the kind of completions you're suggesting will require
>> such tweaks.
> It brings up a related issue: `category' is a metadata element.  Do we
> really want to require every project-file-completion-table
> implementation to include that piece of metadata?
> Being able to assign it to the returned table in find-file-in-project
> would be handy.

Right.

Of course, project-find-file could wrap the backend's completion table
so as to add its own `category' info to the meatadata, but
it's cumbersome.

We should try and unify the metadata returned by the completion-tables
and the metadata returned by the completion-at-point-functions (or
provided via completion-extra-properties).

>>> You'll be able input "/file", and it'll match "foo/bar/file.el".
>> I don't see how `partial-completion' would do that.
> The same way as "-firefox" expands to "browse-url-firefox"?

Ah, I see.  But that means all the files are returned as one flat list
(without using completion-boundaries).  Might be a good idea.

>> [ I did have some earlier version of partial completion match "**/file"
>> to "foo/bar/file.el", but the current code doesn't have that, and even
>> less so without a "**".  ]
> Why not?

Couldn't find that 25th hour!

>> - Same thing but where the order doesn't matter: bar/foo should also
>> find "tv/football/field/barberis.txt".  This one should probably
>> automatically recurse, even if there is a match in the current directory.
> I rather leave that for a separate style, too permissive for my taste.

Agreed, but occasionally I need such things, and that's where the *
globs come in handy ;-)


        Stefan