From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: scratch/backend-completion c807121fbd 1/2: Add lisp/backend-completion.el Date: Fri, 25 Nov 2022 10:50:24 -0500 Message-ID: References: <166938157708.15020.14294469350904271113@vcs2.savannah.gnu.org> <20221125130621.A3C14C0E4C1@vcs2.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4650"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 25 16:51:16 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 1oyayx-00010g-TI for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Nov 2022 16:51:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oyayN-00053n-Uz; Fri, 25 Nov 2022 10:50:39 -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 1oyayK-00051B-KQ for emacs-devel@gnu.org; Fri, 25 Nov 2022 10:50:36 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyayC-000136-Vm for emacs-devel@gnu.org; Fri, 25 Nov 2022 10:50:32 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3326F1000F8; Fri, 25 Nov 2022 10:50:27 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7FEE810002A; Fri, 25 Nov 2022 10:50:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1669391425; bh=nMsNF84/uOwz+Br+PCSY5bsKyQywxgv8dsH+jd21ukI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=n7nACG5IIVbJo77bRTffDTmOvKNL2WViY1XnIotzGY6YuMqcY8inasvIzFfutLczL h568HwdMgRKW31FBG8g2uugoyt4UALxWsHS5XfyUrpsz2GzDNNibrGfq1ibx+wfAvp XEn62ldxhr6zcxOsuouxB5zqve/nmynLLaUmd5ig7sRr0k+km2XNHpa0/jv3535xLU He2IClfh07B1zWI3hVj4pkb0NZfcqSMGo+uahV7daSZMdmhhVHJZILLxAoeusQprFQ Z8zdrCEPOTW7ijq5x2uoEApktUF9YNRSAVANrwSsDSIO62UfV2umDk33uSKbZkOcwx nCLJjkFdAOyyw== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5CAB9121E6F; Fri, 25 Nov 2022 10:50:25 -0500 (EST) In-Reply-To: <20221125130621.A3C14C0E4C1@vcs2.savannah.gnu.org> (=?windows-1252?Q?=22Jo=E3o=09T=E1vora=22's?= message of "Fri, 25 Nov 2022 08:06:21 -0500 (EST)") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:300490 Archived-At: > This completion style is meant to be used with a "programmable > completion" table that interfaces with an external providing An external .... ? > +;; 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 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`. 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. > (add-to-list 'completion-category-overrides > - '(eglot-indirection-joy (styles . (eglot--lsp-backend-style)))) > + '(eglot-indirection-joy (styles . (backend-completion-backend-style)))) Any reason not to call that completion category just `eglot`? Stefan