On Wed, Nov 6, 2019 at 8:18 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
> OK.
>
> Renames aside, you'll have completions-common use bold, right? And hide
> first-difference.

No. Completions-first-difference is renamed completion-emphasis and
completions-common is renamed completion-shadow or
completions-secondary-emphasis. Then aliases are made. Then
completion-pcm-hilit-commonality starts using completion-emphasis
for the matching parts.

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

I don't understand this part but I think this doesn't apply
since you misunderstood.

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

Sure, it was lighthearted.  I was just making a point before that making
flex match "less" isn't possible.  But feel free to make faster lists
and such to improve it from the "outside".

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

It's a good approach at delayed evaluation.  You could hand-code it, but
the patterns and the accessors you need are already solidly there.
It doesn't magically code the generator for you, if that's what you were
expeecting. :-)

> > Possibly/probably by using delayed evaluation techniques.
>
> My limiting the number of completions, most likely.

Really? Then they suck. But hey, that's easy to do in Emacs, too :-)

> And/or doing it all in C++/Java.

We've seen elsewhere those speedups are relevant, but not mind-blowing.
Even if the speedup is 10x it's easy to switch to a project
that has 100x the symbols.

And "doing it all" is a a poor approach at optimization.  We should
optimize the hotspots.  And we can do that in Emacs, too.

BTW Java has generators too. And so does recent C++.

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

That's only if you don't (also trivially) change 'basic/prefix' to use
'completion-emphasis' for the common part and my
completion-secondary-emphasis for those
situations.

--
João Távora