[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 17:16:19 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
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.
- Re: VOTE: Changing completions-common-part face's default, (continued)
- Re: VOTE: Changing completions-common-part face's default, Dmitry Gutov, 2019/11/08
- Re: VOTE: Changing completions-common-part face's default, João Távora, 2019/11/08
- Re: VOTE: Changing completions-common-part face's default, Stefan Monnier, 2019/11/06
- Re: BIKESHED: completion faces, João Távora, 2019/11/05
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/05
- Re: BIKESHED: completion faces, João Távora, 2019/11/05
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/06
- Re: BIKESHED: completion faces, João Távora, 2019/11/06
- Re: BIKESHED: completion faces,
Dmitry Gutov <=
- Re: BIKESHED: completion faces, João Távora, 2019/11/06
- Re: BIKESHED: completion faces, João Távora, 2019/11/06
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/06
- Re: BIKESHED: completion faces, João Távora, 2019/11/06
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/06
- Re: BIKESHED: completion faces, João Távora, 2019/11/06
- Re: BIKESHED: completion faces, Dmitry Gutov, 2019/11/06
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/06
- Re: BIKESHED: completion faces, Juri Linkov, 2019/11/06
- Re: BIKESHED: completion faces, Eli Zaretskii, 2019/11/07