Re: BIKESHED: completion faces

[Dmitry Gutov]

On 06.11.2019 10:53, João Távora wrote:

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

I think it applies after you second step. And after just the first one, 
we'll have inconsistency between the styles.

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

I'm saying writing a generator is largely irrelevant (especially if 
completions come over the network). And all completion frontends do some 
sort of sorting, which usually means they will try to realize the whole 
lazy sequence up front.

>  > > 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 :-)

Easy in a way that would minimally hinder the user?

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

I don't think this puts the right emphasis on things.

Every approach has a limit. But with a 10x more performant/compact 
system, one could handle projects 10x the size.