Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations

[Dmitry Gutov <dgutov@yandex.ru>]

On 27.05.2021 02:17, João Távora wrote:
> On Wed, May 26, 2021 at 11:20 PM Dmitry Gutov<dgutov@yandex.ru>  wrote:
>> On 27.05.2021 00:45, Juri Linkov wrote:
>>> we could have one function
>>>
>>>     :resolution-function
>>>     (lambda (str fields)
>>>       (mapcar (lambda (field)
>>>                 (pcase field
>>>                   ('suffix (if (fboundp (intern-soft str)) " <f>"))
>>>                   ('kind (elisp--company-kind str))
>>>                   ('doc-buffer (elisp--company-doc-buffer str))
>>>                   ('docsig (elisp--company-doc-string str))
>>>                   ('location (elisp--company-location str))))
>>>               fields))
>> The downside should be obvious: you waste extra CPU and memory when you
>> only need some of these values, and not all of them.
> I don't see why, though.  Isn't the `fields` arg supposed to solve just
> that problem?  Or am I missing something?

OK, that was poor reading on my part (missed 'pcase').

What would such structure buy us, though?

My objections would be less fundamental here, but:

- Harder to mix and match different implementations for these fields 
(look how elisp-completion-at-point is implemented, using different sets 
of extra-properties in different branches of its execution).

- Harder to know whether a particular field is implemented/present. 
Currently you fetch the necessary function with 'plist-get', and you can 
test the returned value for non-nil. Without that, each function cannot 
return nil to mean something different than its absense. So you can't 
have 'true' as default value for any of those fields.

Also, the above piece of code looks awfully similar to a Company backend 
or frontend definition, which you have disparaged on multiple occasions.