João Távora <joaotavora@gmail.com> writes:

>>  and then get rid of the hash-table altogether?
>
> Stefan, again we think alike, I'm taking care of that, the hash table
> and the gensym aren't needed at all.

Here's a revised patch without the hash table (actually a patch on top
of the other one, but I send the two of them again).

completion-lazy-hilit is simply bound in icomplete.el's
icomplete-exhibit.

I don't recall exactly why I used to set it in the hook to a gensym in
2021.  I think it was because I was setting face properties on reused
strings (not just score) and that caused problems when switching
completion styles.  But I don't think that can happen anymore, so no
need for that.

>> Hmm... in order to get the right result you need to call
>> `completion-lazy-hilit` sometime after calling
>> `completion-all-completions` and before the next call to
>> `completion-all-completions` done with the same value of
>> `completion-lazy-hilit`, right?

Right, it used to be something like that, but not anymore I think.  Now
the semantics, could be described informally as

   "called by the frontend in the hopes that the style got the hint,
    which will speed things up significantly -- but if the hint wasn't
    caught that's OK too".

>> How much more expensive is it to replace the 

>>     (mapc (lambda (str)
>>             (put-text-property 0 1 'completion-score (funcall score str) str))
>>           completions))

>> with something like

>>     (let ((tail `(completion-lazy-hilit (completion--hilit-from-re ,re))))
>>       (mapc (lambda (str)
>>               (add-text-properties
>>                0 1 `(completion-score ,(funcall score str) ,@tail) str))
>>             completions))


I get the idea, I think but I think it would be somewhat more expensive,
at it is similar to my earlier patch which stored more stuff in every
string which Dmitry (and then I) measured to be slower.  But feel free
to experiment, of course.

João