Handling of dynamic minibuffer-completion-table

[clemera]

When minibuffer-completion-table is a function the candidates might be created dynamically. Currently selectrum--normalize-collection gets the candidates from the table only once but this fails if the candidates are computed dynamically. On the other hand it is slow and unnecessary to recompute big tables like help--symbol-completion-table on each input change.

[raxod502]

Hmmm... how often are dynamic completion tables used? There was one in find-file, which I worked around by implementing a custom selectrum-read-file-name. After all, if the completion table is dynamic, there's a good chance that it's doing something fancy and specific to the default completing-read paradigm, and really needs to be ported. Perhaps this is rare enough that we can simply implement all of them individually and be done with it?

[clemera]

how often are dynamic completion tables used?

I don't know, I stumbled across this issue when someone on reddit shared a command for locate.

Perhaps this is rare enough that we can simply implement all of them individually and be done with it?

It is probably rare but I think it's kind of bad/annoying if commands using default completing-read don't work as expected. Maybe recomputation could be done with an idle timer and use while-no-input, which could be smooth enough.

An other easier workaround would be to provide a command similar the recently introduced selectrum-exhibit function. This could be used to trigger the recomputation of the candidates manually via a keybinding.

[raxod502]

Your suggestions are good. Any of that would be fine. Another option would be to simply recompute the table on every input change, but have a customizable list of table symbols that are known to be static.

[clemera]

I have experimented and while the timer approach works I don't like that the filtering behaves like helm (the output is noticeable delayed). It feels much more snappy with the current approach. I think dynamic minibuffer tables where the candidates can change with input are to rare to justify this decline in UI experience. I would prefer to default to the current behaviour and then maybe having the option to declare some special tables as needing to use the timer approach. But maybe having a command to recompute the current table on demand would suffice already (this is also how those tables where designed to be used because with default completion they are only recomputed on TAB press, too).

When a candidates function gets passed to selectrum-read we currently compute it on every input. This isn't problematic as long those dynamic functions are fast enough. When we decide to have a variable which declares completion tables to be computed with a timer this option should probably also affect the computation of dynamic candidate functions so we have a single way to configure timer based computation.

[raxod502]

Ok, good to know about the timer approach. I agree we don't want to go the Helm way. There are a couple of good options, as you point out -- it's a balance between making things work out of the box / without extra keystrokes being required, allowing extensibility for people to deal with cases not supported properly, and not having more options than are really needed. I think you've got more context than me about what the right thing to do is.

[minad]

What is needed to support completing-read with a dynamic generation function in selectrum? I cannot implement consult-buffer based on completing-read it seems, since the generation function is only called once.

Independent of that, you discuss timer based solutions - I would prefer not to do such a thing on the level of the selection framework. I think rather the generating function should take care of caching. But I don't know of current uses of generation functions, are they all fast or should the completion system handle potential slowness of the generation function?

[clemera]

What is needed to support completing-read with a dynamic generation function in selectrum? I cannot implement consult-buffer based on completing-read it seems, since the generation function is only called once.

Essentially the dynamic function needs to be called on each input change. This is what we do when you pass a function to selectrum-read. It works when the completion function doesn't require a lot of computation but otherwise this will make things stutter. The idea with the timer is that you wait for a time slice where the users stops typing and then do the computation. Are you able to make consult-buffer work with helm (using regular completing-read)?

But I don't know of current uses of generation functions, are they all fast or should the completion system handle potential slowness of the generation function?

Some built-in tables like help--symbol-completion-table used by C-h f can get quite big/slow, a timer solution would work around that but would also introduce a delay before candidates are displayed as in helm.

[minad]

I haven't tried helm for a long time. But slowness was certainly a big issue. For now I am not concentrating on consult-buffer.

[clemera]

I suggested it as it should work with all dynamic completion tables AFAIK. But I probably should have suggested icomplete which is probably be the most API compliant incremental narrowing framework as of today.