[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BIKESHED: completion faces

From: Dmitry Gutov
Subject: Re: BIKESHED: completion faces
Date: Wed, 6 Nov 2019 10:18:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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'.


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

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
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]