Re: BIKESHED: completion faces

[Dmitry Gutov <dgutov@yandex.ru>]

On 06.11.2019 1:11, João Távora wrote:

>>> Best solutions arise when we can understand exactly what it is that
>>> people like about current defaults, and can accomodate that specific
>>> preference in a new system, so that they barely notice it.
>>
>> That sounds like a change in defaults, though.
> 
> Yes, but much more controlled.  This particular change in defaults so is
> done so that the explanatory part that people (presumably) like about
> the current 'basic' match highlighting is still preserved.

I might have missed what you are referring to here exactly.

>> Your proposal would add a different styling for different completion
>> styles. That would require some code as well, likely a similar amount.
> 
> No, we are not talking about the same thing.  In my latest proposal, two
> faces are renamed, obsolete alias are created, and
> completion-pcm--hilit-commonality is trivially changed to use
> 'completions-emphasis' instead of 'completions-common'.

OK.

Renames aside, you'll have completions-common use bold, right? And hide 
first-difference.

The first one will result in long annoying columns with prefix-only 
completion (this won't happen in other editors because a) they use flex, 
b) popup is limited in height), the second one will remove a bit of 
extra information.

>>>   > > The former part can be improved in flex, the latter can't: it's
>>>   > > intrinsic to the technique.
>>>   > All can be improved, just with varying degrees of difficulty.
>>> Sure, a pig and a large enough rocket...
>>
>> Is that because the current completion system is not optimal for flex?
> 
> No, no. I just lightheartedly commented that in response to your "all
> can be improved".  Like "all animals can fly, even pigs, provided you
> attach a large enough rocket".

That kind of discounts the valid and useful avenues for improvement we 
still have.

>> algorithm itself, but any subsequent bottlenecks would not be triggered.
>>
>> This approach really relies on good and fast scoring, though.
> 
> If we're going to do extensive changes in the name of performance, isn't
> it better to use Daniel's generator.el library?  It sounds like just the
> thing.

Last I checked, it's not very relevant. Or if it is, it'll just be a 
minor implementation detail.

>>>   > One just has to make sure not to cache the result improperly.
>>> Cache invalidation, one of the "hard" problems in computing.  Buying
>>> trouble, I say.
>> Let us not forget that we're competing with other editors who
>> routinely show off flex matching and somehow deal with accompanying
>> performance problems.
> 
> Possibly/probably by using delayed evaluation techniques.

My limiting the number of completions, most likely. And/or doing it all 
in C++/Java.

>>>   > As you can imagine, IMHO this part "making sense" is less important than
>>>   > the consistency in highlighting.
>>> It's only "inconsistent" if you you refuse to accept that concepts
>>> such
>>> as "relevance" or "emphasis" are more important the specifics of the
>>> matching technique implemented.
>> I'm more interested in highlighting being consistent and relevant to
>> whatever the next action the user should perform.
> 
> And that's cool, I maintain that this isn't broken at all by my
> proposal.  Can you explain how it would be?

Hiding first-difference will lose some info when suffix is non-empty.