From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Mon, 16 Aug 2021 05:20:25 +0100 Message-ID: <87eeauhvg6.fsf@gmail.com> References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> <87sfzca0zm.fsf@gmail.com> <4cac92d2-056d-e7fb-0664-2dbccb5f980c@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9985"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 06:21:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mFU7b-0002Od-GB for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 06:21:11 +0200 Original-Received: from localhost ([::1]:43912 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFU7a-0006DG-Fc for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 00:21:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFU7S-0006Bs-LQ for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 00:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36603) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFU7S-0000Kr-Et for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 00:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFU7S-0002c9-B1 for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 00:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 04:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs Original-Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16290876379989 (code B ref 48841); Mon, 16 Aug 2021 04:21:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 04:20:37 +0000 Original-Received: from localhost ([127.0.0.1]:48148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFU73-0002ax-F8 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 00:20:37 -0400 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:43672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFU70-0002ae-HF; Mon, 16 Aug 2021 00:20:35 -0400 Original-Received: by mail-wr1-f47.google.com with SMTP id z9so21578529wrh.10; Sun, 15 Aug 2021 21:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=6ORklZy2oh7+mIpgyzo/CZybnxRFNWUtbViQ+U+jU1o=; b=YL5LwTo17TvVYrpoNbfomTr0onwcObAQEtAFYSujsdtf3kybfR4RNg/AzbmC5d788V zc5R/0Y8+ufO/IID9VNIkX2GvdpcnyOgq5kjZseX1rU+wKLKZLqGJAHroIZC052u/FCj WDQ6B/rmVuklCfE0hq+U83kfr3WOby+DUsKNQ6lvCNh0bs5wfUUwZ4Bz+r1ZZuWjsDtX CUEErG7fzFY0hLaiTmP+zp1cZVqMsoNV7Hkp/ByhGeI1jTAjYDXwvEsEVjd0AOnX8rcA tERmS+PVbO+OSntEBAcOd4w9oN2v7WEe7KASbC3pLMK57/kdKLnNlyZXHWrgYcuDSRA7 4vyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=6ORklZy2oh7+mIpgyzo/CZybnxRFNWUtbViQ+U+jU1o=; b=KJ3WsdoN2n2fLipF6wF8qJEj4G+jfR82z2Zf5RsyVrnB6vhdqXiRlzOlnCQcmo5oFZ j2v/X4x3Venyn/nfV7QoTO8nmtlTEEHwIOuezJxDxEDvY/a4CIW0ACGTkKIOe09eUI2g D9kIkPLivLeqQKoKfYZc0TFpjLqqvsaRMbD8TIztxdiTcB9oJ9NPc7z6J4WbOhRTxfWl 4ToFnMzPX0vLqViF6w9JrWOvAXpH9zIs0/Z5gRu1vdh5HFAnCk0tdPdvWXCp06QyHkQa ZW244N0vnmp8M9PxPsoz0W8S6IacO3yS82VYOqGTwbB23zmtg2wCuF3AXmV57jyGl5wJ 8QzA== X-Gm-Message-State: AOAM531ygnM6WIZS7Z2O3kRYBi7mtNGRCIjgGB63VxqfsNQdTpXMchOG U7iDVkWMWHMbo7lBlduqbhi6/NkN3cw= X-Google-Smtp-Source: ABdhPJyqbcT14E1S1SsGdjfOZya8JhfeBXkq4rBHSUaGdB+Ob/fDPByYkpxDCFR/yApduR3DU7+9dg== X-Received: by 2002:a5d:6da4:: with SMTP id u4mr16291268wrs.50.1629087628279; Sun, 15 Aug 2021 21:20:28 -0700 (PDT) Original-Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id k13sm1619589wms.33.2021.08.15.21.20.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Aug 2021 21:20:27 -0700 (PDT) In-Reply-To: <4cac92d2-056d-e7fb-0664-2dbccb5f980c@yandex.ru> (Dmitry Gutov's message of "Mon, 16 Aug 2021 06:48:32 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211964 Archived-At: Dmitry Gutov writes: > As I pointed out later in the email you're replying to, copying won't > happen N times. _Currently_, as in origin/master, it happens N times. In my patch, when a frontend adheres to the thing, it happens D times where D is the amount of strings you need to display. I guess if you do the work to adapt a frontend to work with the new API proposed in Daniel's patch it will be about the same (though likely in many more lines of Elisp). > First of all, note that scoring is only essential to the 'flex' > style. Whereas the improvements we're discussing should benefit all, > and can be more pronounced if the scoring don't need to be performed. Yep, I agree. But I don't see why the same principles I espouse -- which really amount to: let the style know it doesn't need to face-propertize -- can't be applied to other styles that don't need scoring. Although those don't seem to suffer from any performance problems, at least I haven't seens any complaints/reports/mesurements like you did for bug#48841. > But ok, let's talk about flex in particular. Yes, I think that is important since it is the style known to be least performant by its very lax nature. > I'm guessing you just skip the C step in your benchmarks? Which is > something that breaks our current contract. Right. Skipping the 'C =3D Copying step' is the whole point. It breaks our contract because the completion styles currently promise to "face"-propertize the string. So this is why I propose to let the completion-style know that it doesn't need to. When it is told of that, it is relieved of the necessity of copying the string. It is the frontend that will do that copy just before face-propertizing and displaying the string. As you note, and reality shows, that's much faster. There is no disagreement here. > Still, Daniel's patch should provide a comparable performance Kinf of, from what I've read, it _should_ open the way for that to happen. From what I understand, you must then change the frontend (in a big way?) to stop using completion-all-completions and start using the new thing. That work has not been done, as far as I know. Whereas in my proposal (which is now a patch posted to bug#48841) you change the frontend in a very minor way, and that work _has_ been done. Icomplete was very easy to adapt. I can try adapting company soon. In practice, we can't kill off completion-all-completions and start everyone on completion-filter-completions (if that's what it's called). So if the latter does turn out to be a step in the right direction (I'm mostly waiting on Stefan to chime in), then I also don't see why we couldn't have, as Eli suggested, both strategies for lazy highlighting at some point in the future. > improvement. If you're saying it doesn't give numbers as good, I'll > have to give it a more thorough read and testing tomorrow to comment > on that. It's not me who is saying it, it's my Emacs :-) The real problem is that with Daniel's patch, the frontends using the current API (as in icomplete/fido) measurably become _slower_. Though not by much (around 10%), it is still a shame. Yes, do your testing and please, as always, try to report as quantitatively as possible, so that we can really compare apples to apples. Jo=C3=A3o