bug#47711: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting

[Dmitry Gutov]

On 27/10/2023 19:19, Stefan Monnier wrote:
> > We could, for example, have a period when we warn about returned
> > non-matches. string-match-p is not free, but it's not very expensive either.
>
> The problem is that I dislike `completion-regexp-list` :-)

When we do use it, we can avoid copying all the strings to a new list. 
Skipping consing this way can really move the needle at the level of 
optimization we're discussing now.

> More seriously, since it's a dynbound variable it can have unwanted
> effects in nested calls to `all/try-completions`, so it's safer to
> ignore that variable because its binding is not always "meant for us" :-(

I guess it would be more precise if it was a function argument, e.g. the 
first argument to 'fancy-all-completions' or somesuch that all 
completion tables are supposed to use inside. OTOH, I suppose that might 
hinder those that use external programs.