Re: find-file-project

[Dmitry Gutov]

On 09/17/2015 04:26 AM, Stefan Monnier wrote:

> 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.

> > 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"?

It doesn't work with 'find-file', but maybe only because 
completion-file-name-table doesn't interpret "//" as "/**/". It doesn't 
interpret "/**/" properly either (only treats it as "/*/").

> [ 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? Anyway, I was talking about implementing a new completion 
table, nor necessarily reusing completion-file-name-table.

> Suggestions:
>
> - combine substring and partial-completion,
>    e.g. "a*l/b" can find "cable/rob.el".

If globs weren't trivial to implement here, honestly, I would leave the 
support for them altogether.

> - foo/bar should be able to find "tv/football/field/barberis.txt".
>    I.e. like `partial-completion' but if "foo" doesn't match anything,
>    look for it recursively.

Yes.

> - 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.

> - maybe "bar/foo" should also find "tv/myfootball/field/umbertobarberis.txt".

Why not. Although maybe I'd rather only match 'foo/bar', but not 
'bar/foo'. We might want a knob here.