Re: find-file-project

[Stefan Monnier]

>> 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).
> Standard completion doesn't fit?

Hmm... can't remember exactly what were the problems.  I think it had to
do with my desire to reproduce the exact same behavior as the old
filecache.el.

FWIW, see the current diff I have.

> What's the main difference between the list provided by filecache.el and the
> list of files used by project-find-file?

Probably nothing very significant.  But filecache.el uses a particular
completion scheme that I wanted to try and preserve.

> Too late how?

In that by the time (not sure if measured in seconds or in chars)
company kicks in, there's only a single completion left, and it's just
a couple extra chars.

> - If you have to type too many chars for completion to kick in, lower
> company-minimum-prefix-length?

Yes, I think that's what's going on.  E.g. after typing "<", I think we
can pretty much immediately pop up the completion menu.  Or at most
after one more char.

> Alternatively, a "native" company backend can
> return a cons value with a fake "length" to compare against the latter
> variable's value (or t, to mean that the check will succeed). I've recently
> accepted a patch adding a similar capability to company-capf, on github:
> https://github.com/company-mode/company-mode/pull/450.

Good, so we should be able to do it within nxml's capf.

> If nxml-mode completion always uses a limited set of tags/attributes/values,
> maybe it could always return t as the "prefix length". (I don't really know
> if that's true or not.)

Not sure in general (e.g. for attributes), but for tag names at least,
I think that's pretty much the case.

> It seems to me the functional completion tables could be complex
> enough already.

Not sure what you mean by "complex enough": do you mean "flexible enough
that we don't need a new mechanism", or "so complex that adding yet
another method would make them really unbearable"?

> But that's a bit of a separate concern: since completion-try-completion and
> completion-all-completions are on a higher level, I think *they* could be
> generics, whereas the all-completions/etc could stay as they are.

But the only argument they receive is the completion-table, so we need
them to be "dispatchable".
[ Side note: I've been toying with the idea of "callable objects", by
which I mean thingies which have slots and dispatchable types (like
cl-structs or eieio objects) but which can also be passed to funcall.
We could use them for the advice objects of nadvice.el, for the stream
objects of stream.el, and potentially here as well.  ]


        Stefan