From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#47711: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Sun, 29 Oct 2023 04:07:35 +0200 Message-ID: <40ddec76-751a-36cd-7f45-34de2d9d9393@gutov.dev> References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> <83fsvcbio7.fsf@gnu.org> <9f432d18-e70f-54c1-0173-1899fb66d176@gutov.dev> <877cnafv39.fsf@gmail.com> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@gutov.dev> <7d14bc13-4419-816c-5708-c42988c39c02@gutov.dev> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@gutov.dev> <1504b2e4-42d9-5d7b-eaa2-c7b7d5ca02ba@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18093"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Daniel Mendler , Eli Zaretskii , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 47711@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 29 03:09:00 2023 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 1qwvEY-0004VY-6y for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Oct 2023 03:08:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qwvE8-0000sP-Eu; Sat, 28 Oct 2023 22:08:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qwvE6-0000sH-Hs for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 22:08:30 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qwvE6-0008Sy-9y for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 22:08:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qwvEc-0005vQ-5b for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 22:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Oct 2023 02:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47711 X-GNU-PR-Package: emacs Original-Received: via spool by 47711-submit@debbugs.gnu.org id=B47711.169854530522727 (code B ref 47711); Sun, 29 Oct 2023 02:09:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 29 Oct 2023 02:08:25 +0000 Original-Received: from localhost ([127.0.0.1]:39943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwvE1-0005uU-CQ for submit@debbugs.gnu.org; Sat, 28 Oct 2023 22:08:25 -0400 Original-Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:35753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwvDv-0005uB-W4 for 47711@debbugs.gnu.org; Sat, 28 Oct 2023 22:08:23 -0400 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id 47AB13200124; Sat, 28 Oct 2023 22:07:41 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sat, 28 Oct 2023 22:07:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1698545260; x=1698631660; bh=M2L4AzMVPpI+cMM+ECgi89zAjqlAdeMTBeZ 1yasdGcg=; b=rgoszCqyLHaGeAphur8+OqUwfC2ccX05ektHxQIMCgnMb/KdXP5 6N4swtYVNVouk9Zwz1NsUeJFaSm/TbEat7EP48wJ/jLCMTzNkjq7HPF/aL/fQ+k9 6hFQ0xQi8LBhH+PhylHmdN68FYo0FiQuKqUnSqN9hegCRao+L1HKaO2e/+DlqAOC Ued75JyXEmF79m34MBa1TioTwCG7cI1tnd2fs6gIRx0WLK0dq2keVxdJIAC23FG9 5d6Fmi4KWqDz2NcAIL3T2Ct3seh/5ry3uBT5i1uFJf5yVZh/b1i7SSxDX6TBVwxR a75BXts31zemALkXYrp9RGbtjQSZQYa9eDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1698545260; x=1698631660; bh=M2L4AzMVPpI+cMM+ECgi89zAjqlAdeMTBeZ 1yasdGcg=; b=Gs7WVvNmTpY75g5usva1NDs9NQMkwSnMe9nfCLZY5OSBTvxQL+N xjtGCuuKrRdXcaIgFVWirNQD4lcM17T+YLI9pnon00kdI8ILDsxwasjTYh+JfJiW 3/A4KUw200TuerbPwpIB8M7MRRpDoKiUjnntSxAXDVTrUF7aQodsS8hsfOrE/+Ww G83gF4iUykrg08E0zwLPo0NUFizQ5Cbt49mNmnu7hcESnX5wrqLE17ADPkc1YQ2E Rn67hoLGiZF2+/KR1QTYWx856e6BrvglcPMcEnlYvrrEX+at3Zi9Lvt85ojg5UKA nQui3hERSCurDBxcGpDH+xDo6EakEOSZTfw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleejgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffgfeej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 28 Oct 2023 22:07:38 -0400 (EDT) Content-Language: en-US In-Reply-To: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273475 Archived-At: On 27/10/2023 21:12, Stefan Monnier wrote: >>> More seriously, since it's a dynbound variable it can have unwanted >>> effects in nested calls to `all/try-completions`, so it's safer to >>> ignore that variable because its binding is not always "meant for us" 🙁 >> I guess it would be more precise if it was a function argument, e.g. the >> first argument to 'fancy-all-completions' or somesuch that all completion >> tables are supposed to use inside. OTOH, I suppose that might hinder those >> that use external programs. > In my "work in progress" (not touched since last December 🙁 ), > I replace `all-completions` with: > > (cl-defgeneric completion-table-fetch-matches ( table pattern > &optional pre session) > "Return candidates matching PATTERN in the completion TABLE. > For tables with subfields, PRE is the text found before PATTERN such that > (let ((len (length PRE))) > (equal (completion-table-boundaries TABLE PRE len) (cons len len))) > > Return a list of strings or a list of cons cells whose car is a string. > SESSION if non-nil is a hash-table where we can stash arbitrary auxiliary > info to avoid recomputing it between calls of the same \"session\".") > > `pattern`s can take various shapes. In my WiP code, I implement 4 kinds > of patterns: prefix, glob, regexp, and predicate. Now, we don't want > completion tables to have to handle each and every one of those pattern > kinds (the set of which is extensible via CLOS methods), so there's > a middleman: > > (cl-defgeneric completion-pattern-convert (to pattern) > "Convert PATTERN to be of type TO. > Returns a pair (PRED . NEWPATTERN) where NEWPATTERN is of type TO > and should match everything that PATTERN matches. PRED is nil > if NEWPATTERN matches exactly the same candidates as PATTERN > and otherwise it is a function that takes a candidate and returns non-nil if the > candidate also matches PATTERN. PRED should not presume that the candidate > has already been filtered by NEWPATTERN." FWIW, this neat structure might not help too much: the most popular external completion backend (the LSP language servers, collectively) don't accept regexps or globs, they just send you the lists of completions available at point. With the name matching method sometimes configurable per-server. As such, the most useful methods currently are: 1) Emacs Regexp, 2) asking server for whatever it thinks is suitable (the "backend" completion style). I would also probably want to standardize on the recommended type of TO anyway: some of them are likely going to result in better performance than others. BTW, this reminds me about urgrep in GNU ELPA, which I think includes converters between different flavors of regexp. Something to keep in mind for the occasional completion table that's based on a Grep-like tool. > So the fallback definition of `completion-table-fetch-matches`, which > relies on the old API looks like: > > (defun completion-table--fetch-legacy (table pattern &optional pre _session) > (pcase-let ((`(,pred . ,regexp) > (completion-pattern-convert 'regexp pattern)) > (`(,ppred . ,prefix) > (completion-pattern-convert 'prefix pattern))) > (let ((matches > (let ((completion-regexp-list (if ppred (list regexp))) > (case-fold-search completion-ignore-case)) > (all-completions (concat pre prefix) table)))) > (if (null pred) > matches > (seq-filter pred matches))))) > > This is of course incorrect because `all-completions` could ignore > `completion-regexp-list`, in which case we should use `ppred` instead of > `pred` on the last 3 lines 😄 > > It has the disadvantage that every completion-table basically needs to > start by calling `completion-pattern-convert` so as to convert the > pattern to the format that it supports. But I think it's still better > than the current API where completion tables "have to" obey the prefix > string, the `completion-regexp-list`, and the predicate (and where the > latter two are often nil so tables tends to ignore them, and since > tables ignore them callers don't use them, etc...). So I guess it's also a way to make every completion table aware of PRED? That should work; though it might be hard to reach the same raw performance as the current all-completions + completion-regexp-list.