Re: BIKESHED: completion faces

[Dmitry Gutov]

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.