On Wed, Nov 6, 2019 at 8:18 AM Dmitry Gutov <
address@hidden> 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