Re: Recommendation for CAPF setup when you don't know completion string in advance

[JD Smith]

On Apr 3, 2021, at 7:49 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

So it’s a quandary: I won’t yet know `beg’ and `end’ until _after_
interacting with iPython.  Is there any way to “revise” ‘beg’ and ‘end’ in
a collection function returned from a CAPF?

Make your CAPF function return a beg..end that covers "the whole line"
and which returns a completion table in the form of a function.
That function will then defer to the iPython code for the grunt of its
work and will return the "real" boundaries via the
`completion-boundaries` method.  This will probably require some caching
in the completion table so we don't call iPython too many times for
a single completion (like once for `completion-boundaries`, once for
`try-completion`, once for `all-completions`, etc…).

Thank you, that sounds quite promising.  I’ve started sketching out a mash-up of `completion-table-with-cache’ and `python-shell-completion-at-point’ and it seems it should work out.  

There’s one thing I’m unclear on: how long does the completion engine in Emacs hold on to a collection aka "completion table" function?  I’d expect this function to live only throughout a single “event" of completion (M-tab or what have you).  But if that is indeed the case, I’m confused by why `completion-table-with-cache’ needs to test:

(string-prefix-p last-arg arg ignore-case)

Won’t this _always_ be true for the custom-wrapped closure which `completion-table-with-cache’ constructs?  In other words, I can see two possibilities:

1. The cache is there simply to prevent the multiple subsequent collection function calls with the various action flags '(lambda, t, nil, boundaries, metadata) from repeating the expensive completion results lookup.
2. The cache must guard against _future_ calls of the collection function providing yet other not-yet-conceived-of completion strings.  

If #1 is true, wouldn’t all of these calls provide the same completion string? And if #2 is true, why does the completion engine “hold on” to a bespoke completion table function beyond the initial completion event which created it?  

Probably I’m missing the real #3.  This is relevant here for deciding when to re-consult IPython for new completion data.