Closed minad closed 2 years ago
jdtsmith
commented
2 years ago One real issue is it won't be obvious how these combinators will interact with the existing caching happening inside (some) CAPFs. I guess a Wiki table of suggested combinator combinations might help with that.
minad
commented
2 years ago One real issue is it won't be obvious how these combinators will interact with the existing caching happening inside (some) CAPFs. I guess a Wiki table of suggested combinator combinations might help with that.
I am sure we will end up with a list of good combinations.
The most problematic combinator is probably cape-super-capf, since this combinator can only combine static (benign) completion tables (dabbrev+ispell+dict+keyword etc). But combining (file+dabbrev) won't work. Company has the same problem with its backend grouping mechanism.
I would argue that the caching behavior is not significantly complicated by the combinators. The cache buster retains the underlying capf table as long as the input does not change according to the VALID argument. If the table is dropped of course all its caches will be dropped too. If you want to ensure that the table is dropped every time, use VALID=never. This should result in the Company behavior. A potential cape-capf-with-cache will add caching of candidates on top of the existing caching of the capf table which may or may not be present. This could lead to more problems - but so far this combinator is only hypothetical. I am not sure if there are use cases.
jdtsmith
commented
2 years ago But combining (file+dabbrev) won't work.
Why? Why can't you just call the completion table for each in succession and merge the results?
If you want to ensure that the table is dropped every time, use VALID=never. This should result in the Company behavior.
This is a good point. Company has already thoroughly tested this side of parameter space. The other side (adding supplementary caching) is less well tested.
A potential
cape-capf-with-cachewill add caching of candidates on top of the existing caching of the capf table which may or may not be present. This could lead to more problems - but so far this combinator is only hypothetical. I am not sure if there are use cases.
Right, that's the real area of concern. I mean there is already completion-table-with-cache which you have convinced me is broken, so "correcting" this function by replacing it is possibly sensible. Might even make its way upstream.
One question: do you intend this to be used only by (motivated) end users, or do you see it becoming a "convenience library" for the development of CAPFs? Stuff like with-cache may fall more naturally in the latter category.
minad
commented
2 years ago Why? Why can't you just call the completion table for each in succession and merge the results?
The reason is that the file completion table is a dynamic completion table which relies on completion boundaries. When merging the candidates, I am simply compiling the list of candidates from all sources. We lose the dynamism of the underlying tables on the way. Maybe this can be implemented in a better way, but in full generality merging dynamic/programmable completion tables is not possible.
Right, that's the real area of concern. I mean there is already completion-table-with-cache which you have convinced me is broken, so "correcting" this function by replacing it is possibly sensible. Might even make its way upstream.
Let's say it is half-broken. It is supposed to work only with basic, and in that case it works well.
One question: do you intend this to be used only by (motivated) end users, or do you see it becoming a "convenience library" for the development of CAPFs? Stuff like with-cache may fall more naturally in the latter category.
We will see how it turns out. But so far it looks as if it will provide a bunch of basic capfs/completion commands (cape-file, cape-dabbrev, ...). You may have noted that the capfs can also be called interactively, similar to company backends.
Then it will provide a set of combinators as part of a convenience library for other libraries or motivated end users. However for other libraries it may not make that much sense to depend on the small combinators if you can easily implement the desired caching etc yourself. In this case cape is still a good reference.
jdtsmith
commented
2 years ago The reason is that the file completion table is a dynamic completion table which relies on completion boundaries. When merging the candidates,
So really just "there's no clean way to merge boundaries when different CAPFs disagree on them"? I can see that could be an issue. I still don't see why super-capf completion couldn't call out to two different lsp servers for example, and compile their results in one candidate list. So not just static in-process tables, or am I still missing something?
I guess if one server says "complete the text >a fine frog< to one of these options", and another server says "complete the text >this is a fine frog< to one of these options" you'd have an issue.
minad
commented
2 years ago Yes, the boundaries are the main issue for the general solution, see the FIXME in completion-table-in-turn. In practice there are not that many tables which make use of boundaries. The most important one is the file completion table obviously.
However in the current implementation not even basic dynamic tables work correctly. I should probably fix this by using completion-table-merge, however I have to figure out first how to keep all the other metadata intact. The problem is that recomputing the hashtable every time is very expensive, but with a cache based on the STR argument it may work well.
(EDIT: Improved in https://github.com/minad/cape/commit/c57b01e982ae3fccba8ea4701ef6d909853d7cf4)
minad
commented
2 years ago It seems we are sufficiently covered. New adapters or issues can be discussed in separate issues. Closing.
See the discussion in https://github.com/minad/cape/issues/9.
Implemented:
cape-super-capf: Merges multiple capfscape-company-to-capf: Transforms company to capfcape-capf-buster: Dumps the capf cache if the input changes.cape-interactive-capf: Creates a capf which can be called interactively.cape-silent-capf: Silences a chatty capf.cape-capf-with-properties: Adds extra properties to a capf.cape-noninterruptible-capf: Protect capf which is not interruptible.cape-capf-with-predicate: Filters the completion candidates of a capf.cape-capf-with-case-fold: Create a Capf which is case insensitive.Ideas:
cape-capf-with-prefix-predicate: Checks if the prefix text satisfies a predicate.cape-capf-with-early-predicate: Checks the predicate before calling the capf, triviallifted-and.cape-capf-with-cache: Caches the candidates more aggressively as long as the input does not change.cape-capf-dispatcher: Calls a dispatcher function to chose from multiple capfs (https://github.com/minad/cape/issues/12).