Re: find-file-project

[Stefan Monnier]

>> I'm not sure if you'd count filecache.el as "goes through
>> read-file-name", but it seems relevant.
> Indeed, it does seem relevant.  But it doesn't define a completion table in
> the standard way, so the question is moot.

Ah, indeed, I have a local hack which turns it into a "standard
completion table" but I never pushed it (and I'm not sure it should be
either, because it's not very pretty: the behavior doesn't fit very well).

> It's also one of the blockers for deprecating company-mode's
> own backends.

[ Side note: I recently changed nxml-mode to provide a proper capf, so
  it now "works" with company-mode, but company mode usually kicks in
  too late in my opinion.  If you have time to spare, I'd appreciate if
  you could try to fine-tune it a bit.  ]

>> IOW instead of providing ad-hoc implementations for try-completion,
>> all-completions, completion-boundaries, etc... you'd provide ad-hoc
>> implementations of minibuffer-try-completion and
>> minibuffer-all-completions, which have the advantage of allowing more
>> flexibility in its output (e.g. the input doesn't need to be a prefix
>> of the output).
> I think you mean completion-try-completion and
> completion-all-completions.

Right.

> How will this happen? Will these functions become generics?

I was thinking of adding a new method to completion tables (beside the
existing try, all, test, boundaries, and metadata), but maybe making
them generics would work as well.

Actually, all the completion-table methods could be turned into
generics, but that requires figuring out on what to dispatch since
currently all completion tables are either functions, lists, arrays or
hash-tables and the "new table types" are sub-cases of function.

> It would be great if you could file a bug and describe your current views on
> this subject there, so it's not buried in this discussion.

Done,


        Stefan