From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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: Fri, 27 Oct 2023 14:12:20 -0400 Message-ID: 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> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36389"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Daniel Mendler , Eli Zaretskii , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 47711@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 27 20:14:05 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 1qwRLR-0009HJ-30 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 Oct 2023 20:14:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qwRKv-0003W7-Um; Fri, 27 Oct 2023 14:13:33 -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 1qwRKt-0003VQ-CI for bug-gnu-emacs@gnu.org; Fri, 27 Oct 2023 14:13:32 -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 1qwRKs-0003e2-PQ for bug-gnu-emacs@gnu.org; Fri, 27 Oct 2023 14:13:31 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qwRLN-0008M0-OA for bug-gnu-emacs@gnu.org; Fri, 27 Oct 2023 14:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Oct 2023 18:14:01 +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.169843038231980 (code B ref 47711); Fri, 27 Oct 2023 18:14:01 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 18:13:02 +0000 Original-Received: from localhost ([127.0.0.1]:37158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwRKP-0008JZ-Pq for submit@debbugs.gnu.org; Fri, 27 Oct 2023 14:13:02 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwRKO-0008J7-2Q for 47711@debbugs.gnu.org; Fri, 27 Oct 2023 14:13:00 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1269710013E; Fri, 27 Oct 2023 14:12:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1698430342; bh=n51eu1FbK21yNxjOMzKMW99K0ZHoHIZcnKcWwODvDn0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KbD0SwiN/zVFyovUulFwGAABArqkvixZJqJYE0AvTDxqqArwfwPIzraouzEL73gLn ut0PTnKXOpDjQyyhjW0n788Wv/rFItDKi30vwn6yLuPl+8EDyhW/a7uf19rgr6HZJN x2/YOs1LRqM4X81YADxQXHnk+KgqDTrlMykvYnZg5tgGIBbJNec499OBh+nndeGPRt FxS7tpEhgErZfC+Uhu9hTJPGMFuqnr+OtiKBrrFVzsEvZY1qdq6PNR7QbXjfwfv3KY UJAyo6niMmbHnVFIMEwHstRKPNVXeXrAfPmllskNpuDC8mj2Lyn5ScqTcFOTrQhJuB MRCWubHflXiKA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3E63E10006B; Fri, 27 Oct 2023 14:12:22 -0400 (EDT) Original-Received: from pastel (unknown [45.72.195.71]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 075C812004E; Fri, 27 Oct 2023 14:12:22 -0400 (EDT) In-Reply-To: <1504b2e4-42d9-5d7b-eaa2-c7b7d5ca02ba@gutov.dev> (Dmitry Gutov's message of "Fri, 27 Oct 2023 20:06:11 +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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273402 Archived-At: >>> We could, for example, have a period when we warn about returned >>> non-matches. string-match-p is not free, but it's not very expensive either. >> The problem is that I dislike `completion-regexp-list` :-) > When we do use it, we can avoid copying all the strings to a new > list. Skipping consing this way can really move the needle at the level of > optimization we're discussing now. Oh, don't get me wrong, I like the functionality it offers, I just dislike the way it works. >> 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." 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...). Stefan