[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: find-file-project

From: Dmitry Gutov
Subject: Re: find-file-project
Date: Wed, 20 Jan 2016 03:51:02 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

On 01/19/2016 05:20 PM, Stefan Monnier wrote:

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? And simply iterating between the suggestions fits it better?

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

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

Too late how?

- If you have to wait too long after typing a few chars, you can lower company-idle-delay. - If you have to type too many chars for completion to kick in, lower company-minimum-prefix-length? 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.

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

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.

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

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.

lists/arrays/hash-tables could be handled by the default methods. Maybe functions, too (or use a different method for them, with a specializer using functionp?). "New" completion tables could be conses tag+function, or cl-structs.

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.

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.


Thank you. Although you've omitted the part about generics, so I'm unsure where to continue that part of the discussion.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]