From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: BIKESHED: completion faces Date: Wed, 6 Nov 2019 08:53:02 +0000 Message-ID: References: <4c5631d4-9dfd-04c6-c573-b83c67fcc2fa@yandex.ru> <87pni7p83l.fsf@gmail.com> <87h83ipoi0.fsf@gmail.com> <3f7afc8e-b3d1-07a4-9350-3bfc5775ba21@yandex.ru> <87sgn1yl4b.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ef177b0596a9ad8d" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="10553"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Stefan Monnier , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 06 09:53:50 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iSH4W-0002bA-I3 for ged-emacs-devel@m.gmane.org; Wed, 06 Nov 2019 09:53:48 +0100 Original-Received: from localhost ([::1]:54032 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSH4V-0008KW-Dy for ged-emacs-devel@m.gmane.org; Wed, 06 Nov 2019 03:53:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47876) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSH42-0008K9-5P for emacs-devel@gnu.org; Wed, 06 Nov 2019 03:53:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSH40-0005ep-IE for emacs-devel@gnu.org; Wed, 06 Nov 2019 03:53:18 -0500 Original-Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]:44316) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iSH40-0005eF-Bb for emacs-devel@gnu.org; Wed, 06 Nov 2019 03:53:16 -0500 Original-Received: by mail-io1-xd2a.google.com with SMTP id w12so26113868iol.11 for ; Wed, 06 Nov 2019 00:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=owf4CYlsamGOLrtQbnnJBKFqpM2VhRUBeRq2OgWFbNQ=; b=cPX9kFWyz7L2+wjXeKvngd+0W4EuqH1KVvzjNKjVSQ8CbGiVM632Kn2yKyigufyIPG YBp8D0zK6USO9PL62L+/rjXPG8xCxa/SR5aSQSg75SrLW4lwL4fdcHYdznDkr6LLW9jY 85XBa4pJYVlBq+Hs0gDmVNY5uCZwz0H1drjn7O9kMsDIGqz4243UPcpOvp66s1lzsQ0D IkLSYYML2dgTQaneZgYUovr0MuFeK9pkOCb+LJi581IzwKMQ1oYP7l5g16/3jQUWLGNA T17HQYtxcBSWIkOoUYZdSVl5RJsvZPdfG64qx9tVIHX5lDg3QTxhvX5XIgvde+nICP2M M4wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=owf4CYlsamGOLrtQbnnJBKFqpM2VhRUBeRq2OgWFbNQ=; b=e8HtbWFyxpSSoC9XppIcr7G6RqyQzUz49s+4+4A7O5kSBMQnf8CUqNpmWtOxpl2Zpz w3TQVDXTh3g5A4XW9amHOTdgc+B97f6uSajB5bgqo/ETOLE9qKYCbp3QVNKQO0ffZxlM x/L1Oib6SLYWE35jXkJR7DfPLX/4v0aky+lIRqfPnYVHDevW/eMpCEnoqhxU4MlP1Vs4 8wf/1iy44dAQlK9N5xQqxnz0r/7w5LhZr1o+MqBtk+ds1uVVYheAjZtdmuEmdbZxUzwF shXMVhJzlcSCaBl6FrFQWDgAxrg0XGJhv+dRGzKnblSsAjy/3j0zm5UfR7PnODGf43MD +y4A== X-Gm-Message-State: APjAAAU/Pye+Y2Ons7hqYhAm6aqVH6FCH98dRLKoLzD7YXLt9UnI4FpW uy/9VSsbh43NgxwAP0CKp8qpc3x93D7OFJm/v4E= X-Google-Smtp-Source: APXvYqxjBhL4VpoJh3+nmMxRkGoSABykjCqHZF62ntHC4x4I9fYTlgs2p0NMcTHX7oSMOYkGOqQUQBJdbph83nj0LWM= X-Received: by 2002:a5d:8b85:: with SMTP id p5mr11540925iol.9.1573030395318; Wed, 06 Nov 2019 00:53:15 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d2a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:241845 Archived-At: --000000000000ef177b0596a9ad8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 6, 2019 at 8:18 AM Dmitry Gutov 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 th= e > > 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=C3=A3o T=C3=A1vora --000000000000ef177b0596a9ad8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2019 at 8:18 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
> OK.
&g= t;
> Renames aside, you'll have completions-common use bold, righ= t? And hide
> first-difference.

No. Com= pletions-first-difference is renamed completion-emphasis and
completions-common is renamed completion-shadow or
completions-s= econdary-emphasis. Then aliases are made. Then
completion-pc= m-hilit-commonality starts using completion-emphasis
for the matc= hing parts.

> The first one will result in long annoying co= lumns with prefix-only
> completion (this won't happen in other e= ditors because a) they use flex,
> b) popup is limited in height), th= e 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.

> >>= > =C2=A0 > > The former part can be improved in flex, the latter c= an't: it's
> >>> =C2=A0 > > intrinsic to the t= echnique.
> >>> =C2=A0 > All can be improved, just with v= arying degrees of difficulty.
> >>> Sure, a pig and a large = enough rocket...
> >>
> >> Is that because the curr= ent completion system is not optimal for flex?
> >
> > No= , no. I just lightheartedly commented that in response to your "all> > can be improved".=C2=A0 Like "all animals can fly, eve= n pigs, provided you
> > attach a large enough rocket".
&g= t;
> That kind of discounts the valid and useful avenues for improvem= ent we
> still have.

Sure, it was light= hearted.=C2=A0 I was just making a point before that making
flex = match "less" isn't possible.=C2=A0 But feel free to make fast= er lists
and such to improve it from the "outside".

> > If we're going to do extensive changes in th= e name of performance, isn't
> > it better to use Daniel's= generator.el library?=C2=A0 It sounds like just the
> > thing.> Last I checked, it's not very relevant. Or if it is, it'll ju= st be a
> minor implementation detail.

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

&= gt; > Possibly/probably by using delayed evaluation techniques.
><= br>
> 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.=C2=A0 We should
optimize the hotspots.=C2=A0 A= nd we can do that in Emacs, too.

BTW Java has gene= rators too. And so does recent C++.

> >>> =C2=A0 &= gt; As you can imagine, IMHO this part "making sense" is less imp= ortant than
> >>> =C2=A0 > the consistency in highlightin= g.
> >>> It's only "inconsistent" if you you r= efuse to accept that concepts
> >>> such
> >>>= ; as "relevance" or "emphasis" are more important the s= pecifics of the
> >>> matching technique implemented.
>= ; >> I'm more interested in highlighting being consistent and rel= evant to
> >> whatever the next action the user should perform.=
> >
> > And that's cool, I maintain that this isn= 9;t broken at all by my
> > proposal.=C2=A0 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
<= div>'completion-emphasis' for the common part and my
completion-secondary-emphasis for those
situations.

--
Jo=C3=A3o T=C3=A1vora
--000000000000ef177b0596a9ad8d--