From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: scratch/backend-completion c807121fbd 1/2: Add lisp/backend-completion.el Date: Fri, 25 Nov 2022 16:28:00 +0000 Message-ID: <878rjzuhgv.fsf@gmail.com> References: <166938157708.15020.14294469350904271113@vcs2.savannah.gnu.org> <20221125130621.A3C14C0E4C1@vcs2.savannah.gnu.org> 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="25464"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 25 17:27:12 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oybXj-0006SU-Df for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Nov 2022 17:27:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oybXP-0000kJ-Fd; Fri, 25 Nov 2022 11:26:51 -0500 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 1oybXN-0000j8-IF for emacs-devel@gnu.org; Fri, 25 Nov 2022 11:26:49 -0500 Original-Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oybXL-000628-Jf for emacs-devel@gnu.org; Fri, 25 Nov 2022 11:26:49 -0500 Original-Received: by mail-wm1-x32b.google.com with SMTP id h131-20020a1c2189000000b003d02dd48c45so725408wmh.0 for ; Fri, 25 Nov 2022 08:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7B07b07F6Bbznz1XKW8L3fRGQeQUBRnvfRvRTo2eJLs=; b=fXtBvSMNfOzKyKdxqCb+hl6pVVbsvEnJv7xtoU+a+MS//iQpqF1B3fmfIvgJpsFljC ZEEI+DB/8FTpmVh5aOHZFrfpb2EIncaAdHdhuTmSq64rADwaUT3jucfkl8FH3ABsv740 Haef0yeD/TMfoxcEZlxhhsnP+CfvmPiLaTjDu6l7fvMl18nEs9ZFmWCYGQB5W2YrOdx8 UCM2SnRbkP4ZyxBBVx9mSqvPQgpYLn7si4nwOvCJ27ICTNnUFjFe0Zne6DuAFnHwku2u /vrliu0rrvbX9hQzLUbHkJO5WooiYxq8bq/N+WH4VitdjDwZcpMmPk6BcCJlITM+OWht 88Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7B07b07F6Bbznz1XKW8L3fRGQeQUBRnvfRvRTo2eJLs=; b=ULCpNGIhb3o1/eb2bCUDlBTeV/AfiLZuBT+Qblm/2BiBXexZFG/TsYr8TsO4uF1ko2 lkwKEMq65fiTBW+mENLtUj1sVaCZenjq36YGFFz2sKiBfSvAJE4ywmgm7rRUYQKjRemT acEaGztlrUhR4KKK3vwUv8E6qAUlQGaUhAjGaQRWYpp/XLORwVX0BuEOkVl6iJ3J/vO8 p0LWQvVrqn9tYW5++sxmaVYQ1HU/ZVDxIFcJuLKuaW+Q/X656W0hxovdOKFe3yJLNGoz WQNxyvtRfw89BnwMp0j5OYJq1y+XRIfdW+QbiBAF7Chh2UPc3rlr+OEn7P6VAWeNS32+ 3E5g== X-Gm-Message-State: ANoB5pmXtTly72ezFGHloPIpFs92dH2Ja9xVm/dzcWPrtX4s74Ff8jio c/6hgTEk7lH5CJVuuGpOKSDDupBK0F0= X-Google-Smtp-Source: AA0mqf5PvJ/kmdkuEC9vsEY/At84Ez2HRCJp/cLi1T9ohNikCvDh+//+hJKThumiPi+CeouJ5bbIDA== X-Received: by 2002:a05:600c:4e50:b0:3d0:bda:f2c with SMTP id e16-20020a05600c4e5000b003d00bda0f2cmr15683494wmq.117.1669393605068; Fri, 25 Nov 2022 08:26:45 -0800 (PST) Original-Received: from krug ([87.196.72.177]) by smtp.gmail.com with ESMTPSA id u17-20020a05600c19d100b003c6f8d30e40sm10522209wmq.31.2022.11.25.08.26.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Nov 2022 08:26:44 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Fri, 25 Nov 2022 10:50:24 -0500") Received-SPF: pass client-ip=2a00:1450:4864:20::32b; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x32b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300492 Archived-At: Stefan Monnier writes: >> This completion style is meant to be used with a "programmable >> completion" table that interfaces with an external providing > > An external .... ? tool >> +;; overriden. This can be seen as a drawback, but, on the other hand, >> +;; the regular the full data set to be available in Emacs' addressing >> +;; space, which is often not feasible. > > There something wrong around "the regular the full data". "the regular styles require the full data set", obviously. Geez, can't you read moronese? >> +;; The programmable completion table amounts to a function taking >> +;; (PATTERN PRED ACTION) as arguments respond to at least three values >> +;; for ACTION: >> +;; >> +;; * The symbol `metadata', where the table should reply with a list >> +;; that looks like: >> +;; >> +;; (metadata (category . backend-completion) MORE...) >> +;; >> +;; where MORE... can be other "metadata" items like >> +;; `cycle-sort-function'. >> +;; >> +;; Other categories can be used in place of `backend-completion', >> +;; as long as the `styles' property of such categories contains the >> +;; sole element `backend-completion-backend-style'. > > Hmmm... I don't think we should recommend `backend-completion` as > a category. It is fundamentally wrong. So I think `backend-completion` > should be the name of the completion style, and the category name should > reflect the user-facing category of elements being completed rather than > the internal details of how the completion is performed. > > Maybe a good way to do that is to provide a (backend-completion-table > FUNC CATEGORY &optional METADATA) where FUN is a function which handles > the tryc and allc cases (maybe the `tryc` handling could even be > optional, depending on how the `tryc` case is usually handled (do > backends often provide something usable for `tryc`?)). That function > would then return an appropriate completion-table (function), and would > make sure along the way that CATEGORY is mapped to `completion-backend` > in the `completion-category-defaults`. I get the idea, I think. I thought about this, but I'm not sure this can be made generic enough to service the three examples I know of: Eglot, SLY and the eel.el thing I've been using lately. > That `backend-completion-table` would also have the benefit that it > could make sure the completion-table it returns also behaves sanely > with other styles (i.e. also handle the "normal" completion table > requests), whereas otherwise the temptation would be very high for users > of this package to use "completion table functions" which only handle > the `backend-completion-tryc/allc` requests and fail pathetically when > another style is used. Similarly `backend-completion-table` could also > make sure PRED is obeyed. Alright. But please, follow up with some code. You're probably right, but this whole thing is too complicated for me to understand. If it helps, use the current Eglot.el code as an example client of that new thing. Or you can assume I also have another function: (defun eel (pattern) ...) That returns a list of completions from an HTTP server (blockingly, sometimes slowly) or may returns the symbols 'user-input', 'timeout' depending on whether whether these two events happened before the completions became available. 'eel' knows how the HTTP server matches STRINGS and propertizes the strings it returns. How would I plug this 'eel' function into the backend-completion-table function you're envisioning? And would it return a working table with the backend completion style that I can put wherever (most likely completing-read)? >> (add-to-list 'completion-category-overrides >> - '(eglot-indirection-joy (styles . (eglot--lsp-backend-styl= e)))) >> + '(eglot-indirection-joy (styles . (backend-completion-back= end-style)))) > > Any reason not to call that completion category just `eglot`? Yes, 'eglot' is already a different completion category, for completion-at-point, with a different structure. `eglot-indirection-joy' is just a product of my usual confusion with this whole jungle of concepts: I just vaguely understand it's an indirection so I called it accordingly for mental reference. But feel free to suggest a better name. Jo=C3=A3o