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

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 16.08.2021 21:25, João Távora wrote:
>> I've made it faster, now very close to the string-propertizing approach,
>> itself very close to the theoretical best (which is no copy, no
>> highlight).  See the tip of the
>> scratch/icomplete-lazy-highlight-no-string-props branch, which I had to
>> rewrite (some Git flub-up).  All benchmarks after sig.
>
> Thanks. I've read it now.
>
> This implementation style (quick exfiltration via a dynamic var with
> some special-cased logic) reminds me of the recent changes to eldoc,
> really not my cup of tea.

I'm sorry, but I'm not drinking from your herbarium.  Googling for
"exfiltration" brings up "malware" and data security.  Why is mine
"quick" at that?  Is this some kind of metaphor?  And what does "some
special-cased logic" refer to exactly?  I see as much similarity to
Eldoc and I do to the Sistine chapel.

The only thing I understand, I think, is "dynamic var".  If you mean the
variable 'completion-lazy-hilit', notice it is not necessarily used as
dynamic var (in fact in icomplete.el it's just a buffer-local var).  As
I explained elsewhere, if the completion machinery had a realiable
abstraction for "session" I would use that.  

I don't think it does, does it?  Currently, it's the frontend who holds
that knowledge.  It will either have an object representing it (maybe a
fancy CLOS thing); or a stack frame with some kind of command loop; or, in
the case of icomplete, a minibuffer session delineated by
kill-all-local-variables.

So, for icomplete.el, setting that variable buffer-locally is the
appropriate thing.  For the command-loopy frontend, dynamically binding
it will be.  The the objecty frontend, the object itself it proabably a
good value for complation-lazy.hilit.

For completion-capf, if you cared to optimize it with this stuff, it
will likely be ... something something.

Anyway, the "implementation style" I went for is speed, brevity and a
decent docstring.

And it'd be a bit shorter if it used string properties...

> At the very least, though, you have done the work of proving that the
> no-string-propertization approach can be just as fast. Thank you for
> that.

You're welcome.  Not really just as fast, but in the big-O ballpark, of
course.

I had hoped to show also that the particular choice of global structure
for string/symbol/whatever association is irrelevant.

I'm still missing the imminent catastrophe (that is so clear to you) of
the put-text-property approach.  I'd like these slower and more complex
techniques to appease more than superstition.

> A hash table with :test 'eq is a good choice. I'd be happy to try to
> tweak it further, but it also seems that at this point we can
> transition to the discussion about what kind of implementation style
> we want, since the performance is proven to be more or less on par.
>
> Though of course that should start with an alternative patch which
> adds icomplete support as well (either Daniel does it, or I'll give it
> a try).

I'm curious to see those, yes.  But Eli pointed out on, two different
APIs will need to cohabitate since the new API won't kill off the old.

To be very clear, I'm interested in the performance of Daniel's patch,
not really in insufferable claims of its beauty and virginity.

minibuffer.el is a great big mess, I'll leave it to the Great Designers
of the Big Redesign, godspeed to them.

Currently, I just want changes to not assassinate, in speed or form,
icomplete.el or the flex completion style, two fundamental daily drivers
to my work, and other's work.  So if/when Daniel's patch doesn't do any
of that (it seems that it currently does), I'll be all for it.

João