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: Tue, 29 Nov 2022 22:59:04 +0000 Message-ID: <87a649qsef.fsf@gmail.com> References: <166938157708.15020.14294469350904271113@vcs2.savannah.gnu.org> <20221125130621.A3C14C0E4C1@vcs2.savannah.gnu.org> <878rjzuhgv.fsf@gmail.com> 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="31288"; 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 Tue Nov 29 23:58:29 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 1p09Yb-0007qC-1l for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Nov 2022 23:58:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p09Xz-0005k1-PL; Tue, 29 Nov 2022 17:57: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 1p09Xy-0005jQ-8f for emacs-devel@gnu.org; Tue, 29 Nov 2022 17:57:50 -0500 Original-Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p09Xw-0002Ao-I6 for emacs-devel@gnu.org; Tue, 29 Nov 2022 17:57:50 -0500 Original-Received: by mail-wm1-x336.google.com with SMTP id j5-20020a05600c410500b003cfa9c0ea76so137609wmi.3 for ; Tue, 29 Nov 2022 14:57:48 -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=wCeUZ89oMpxPJvn69wCnLRFlqtlPaCieSz6NGFbIoOA=; b=MOflBsGn13pWOlH08GVzCVdMkEaeQGCjeiJRJfl/LTFUOBqXKuIJ9PIXZlJRGfn5qN 9TIGolqCh5bpJKtzM07qaaDcPaX3i3HHHjw450UAvYoTloIfTeNbHudsJqMLG1HGqCes HuppOyQdEpi3xSrbPdPUmZNc/HTsigi7Kp2rf+FpJWywIRlJYnIzVeU+Nxu1DY2kIvYG 7o670a9o3sbtR9Phyc4Kw61MTNqAvQZia4KydKz6WQMzO6LOR7Hcr+K3jlj5i8xOUyMO QFG5XZA36xZHOCTzonNzoKnJsOpgTbyBYE5jsK3ZTJtSlSFQGJIlPxzrvUsI1mNRFR7z ocoA== 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=wCeUZ89oMpxPJvn69wCnLRFlqtlPaCieSz6NGFbIoOA=; b=PRafY2c/IdReufY0ZQ0aaozSPiWK9ksQJKITb1qZ1BZ7jbVuLkSRIfcVyKV0JzoHMi d24TdcdHMrQVwxgd2ikroKRSc5fc06wJPoyeu7NkaRBtQCEGEzwT0DO08zA+AuYX7YzY yMAlmeY7N+htWkfa55jzQQ5KBW4k/emIRjrJwPnWq23REGQE57xD1ZekZg6/nxzqrdlv TsbnI0MZbYYaV9hUrr41uPax3nJTcNYKLVQ/xTcDZHgzQ7ky127NHFI/9/QjecEI19qi XwJjgVB5GmXRqxpRXqpfYw9wfifLV6Xk8SBWthYWqZRRZi2EDV+keeP0ZNCNCfmGnjkG 67Hg== X-Gm-Message-State: ANoB5pk4zoudC+tLAfLnRKfZQbfXSbsrIofO6UGwGppkEZR7bUAAGwx3 ygaJhrEKr4cN/5SxrQIBtNILEHn2//4= X-Google-Smtp-Source: AA0mqf4+Z0PPu5DDhcwBzyk07F/6qqKGRKVXLHRw13a9yZP5PtNheIBREI0dhlJLNi50CZxS6xbyXw== X-Received: by 2002:a05:600c:210c:b0:3cf:6af4:c4fa with SMTP id u12-20020a05600c210c00b003cf6af4c4famr43824667wml.117.1669762666845; Tue, 29 Nov 2022 14:57:46 -0800 (PST) Original-Received: from krug (87-196-72-71.net.novis.pt. [87.196.72.71]) by smtp.gmail.com with ESMTPSA id o7-20020adfeac7000000b00236883f2f5csm14842846wrn.94.2022.11.29.14.57.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 14:57:46 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Tue, 29 Nov 2022 16:18:57 -0500") Received-SPF: pass client-ip=2a00:1450:4864:20::336; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x336.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:300733 Archived-At: Stefan Monnier writes: >>> 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. > > I can't see why it wouldn't be just as general as what we have now. > > (defun backend-completion-table ( tryc-function allc-function > category &optional metadata) > (unless (assq category completion-category-defaults) > (push `(,category (styles completion-backend)) > `completion-category-defaults)) > (lambda (string pred action) > (pcase action > (`metadata > `(metadata (category . ,category) . ,metadata)) > (`(backend-completion-tryc . ,point) > ;; FIXME: Obey `pred`? Pass it to `tryc`? > `(backend-completion-tryc . ,(funcall tryc string point))) > (`(backend-completion-allc . ,point) > (let ((all (funcall allc string point))) > `(backend-completion-allc . ,(seq-filter pred all)))) > (`(boundaries . ,_) nil) > (t > (let ((all (funcall allc string (length string)))) > (complete-with-action action all string pred)))))) OK great. But where do you plug the current eglot functions into it. > >>> 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. > > See above. > >>>> (add-to-list 'completion-category-overrides >>>> - '(eglot-indirection-joy (styles . (eglot--lsp-backend-st= yle)))) >>>> + '(eglot-indirection-joy (styles . (backend-completion-ba= ckend-style)))) > > Wow! I didn't pay attention at first, but I now see you're modifying > `completion-category-overrides` which is the user-facing variable. > You should modify `completion-category-defaults` instead! Yep. I actually meant to correct that in the patch. The reason I was using overrides is because fido-mode nullifies completion-category-defaults. It shouldn't, and I added another patch correcting that. So yes, you're right. >>> 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. > > I'm not very familiar with Eglot's code but based on a cursory check, it > seems this is used specifically when completing an identifier for things > like `xref`, so maybe `eglot-identifier` (and maybe `eglot` should be > renamed to `eglot-code` since it's used to complete the actual code in > the buffer)? Maybe. As I've often told you, all this completion code is hard to grasp. I do "get" it somewhat, and I've been working with it intensely for a long time. But also, I don't really get it :-) For example, I have no solid concept of what a category or a style is, so everything just reads like "an indirection from this thing to that other thing". So I named this thing 'eglot-indirection' . 'eglot-code' may be logical for someone who knows what a category means, now but sounds something that will make absolutely no sense to me 2 weeks from now. Jo=C3=A3o