Re: Turning completion table lambdas into symbols

[Spencer Baugh]

Dmitry Gutov <dmitry@gutov.dev> writes:
> On 29/11/2023 01:36, Spencer Baugh wrote:
>> If there was a canonical way for a completion table to maintain some
>> state which*doesn't*  require the completion table to be a lambda, I
>> think most completion tables could become defuns instead of lambdas.
>> (And then they could be customized based on the function symbol)
>
> Maybe take a look at how company-capf caches the results of calling a
> CAPF function?
>
> Depending on the data, the cache key is either
> buffer/point/chars-modified-tick tuple, or the "completion session"
> (but in a company-mode specific way).

Hm, I think I more want to support state/caching inside the completion
table itself.  Not just caching the output of the completions.  That
allows a lot more flexibility.

For example, project-prompt-project-name could be changed to use a new
completion table defun named project--project-name-completion-table.
project--project-name-completion-table would internally maintain a map
between project directories and project names, which it adds to whenever
completion is requested (instead of creating that map up front in
project-prompt-project-name, as we currently do).  If there was no
support for state between completion table invocations,
project--project-name-completion-table would have to call
project--find-in-directory and project-name for each project on each
completion table invocation, which would be slow.

> For CAPF and Company, we also discussed the idea of a "session object"
> some time ago, but that's not in the current API so far.

Right, I think I'd much rather some kind of "session object" at the
level of completing-read/the programmed completion API.

Do you have a link to the previous discussion?

I haven't thought too much about it, but maybe some new dynamic variable
which is bound to nil at the top level of completing-read-default, so
the completion table can change it over time and preserve state through
the course of the completion.  Works fine with nested completing-reads.

Alternatively, if today a completion table is always invoked with the
same current buffer (probably the case?), we could formalize that and
just let a completion table store state in buffer-local variables.
Maybe with some new 'initialize operation in completion tables which is
called when a new completing-read starts, or maybe the completion table
can just detect that somehow and initialize the variables itself.  That
is nicer than having a single variable which all completion tables
share.  However, completion table writers would need to be careful not
to break when doing nested completing-reads on the same table.