[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
State and caching in completion tables
|
From: |
Spencer Baugh |
|
Subject: |
State and caching in completion tables |
|
Date: |
Wed, 22 Nov 2023 14:36:30 -0500 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
If I have a completion table which wants to store internal state - in my
case, for caching data used to generate completions - is there a good
place to do that?
Ideally, the state (in my case, a cache) would only be preserved for a
given call to completing-read. If a new call to completing-read starts,
I'd like the state to be reset.
Usually, I would do this by having a function which creates a fresh
completion table with fresh state, and call that each time to generate
the completion table to pass to completing-read. So state would
naturally be preserved only for a given completing-read, because each
completing-read would use a new completion table.
But more specifically, I'm adding a new file-name-handler. As a
file-name-handler, I don't get the chance to return a fresh completion
table for each read-file-name invocation; I only get to handle
file-name-all-completions and file-name-completion. Given that, I don't
know where my file-name-all-completions and file-name-completion
functions could store some state which is specific to a read-file-name
call.
I want to store state for a read-file-name call to avoid making
duplicate network requests each time file-name-all-completions and
file-name-completion are called; instead I'd like to store the result I
got the first time. I'm happy with any way of achieving that.
Is there a natural place for a completion table to store state which is
specific to a given invocation of completing-read?
Or failing that more general solution, a way for a file-name-handler to
save state for a given read-file-name call?
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- State and caching in completion tables,
Spencer Baugh <=