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: Eglot cannot work with default completion-in-region? Date: Mon, 29 Jan 2024 22:21:01 +0000 Message-ID: <874jevzsqa.fsf@gmail.com> References: <87ttmy7pog.fsf@catern.com> <87r0i1blch.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="30985"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: sbaugh@catern.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, jdtsmith@gmail.com To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 30 04:23:53 2024 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 1rUej3-0007mi-3d for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Jan 2024 04:23:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUeiO-00024u-0J; Mon, 29 Jan 2024 22:23:12 -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 1rUZzx-0001hl-7z for emacs-devel@gnu.org; Mon, 29 Jan 2024 17:21:01 -0500 Original-Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rUZzu-0001Gl-UY for emacs-devel@gnu.org; Mon, 29 Jan 2024 17:21:00 -0500 Original-Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-33ae7ae1c32so1352615f8f.3 for ; Mon, 29 Jan 2024 14:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706566857; x=1707171657; darn=gnu.org; 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=T1kWJKpCnlkqcE3Hf6CqNBW5JXo86TXw+G+DVOyjg1s=; b=R2WKujplUNLhDF20JTcrJtNRaL5PqARjiqkSzz7dFPN8RiA8gw8Cjm+h0RbHHzAtdx Nm6enAqfzYhBw4CwoQ9r5+YXJIRy7hBZ0VR/GQYqX/nPe6sG0Y2f1bBCJrF3dSvZODnt 7QhjTCQHtBtv8VlYql3Pcp6mWMIaoSlpwTP4G0CrWVMukdU72JvliM7kXytXPhhltwbl 8Hrme/tFLrmDQqKumaZ5SS19JroIwDv6+2XMTGxnjEB5Rymt7cfqmM+N8lLdtW5piVLb XqKPnnjn4amDU3naZ2lHl+UamknZ4oWaZ1DJjlPMHi++6EpI6uYm/0wcaaZJAudEtJLq qQsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706566857; x=1707171657; 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=T1kWJKpCnlkqcE3Hf6CqNBW5JXo86TXw+G+DVOyjg1s=; b=S7G1N37pd9UeRpExE/9u/nFAoOulDSQMX1kb8VoawIWgBH392M6gfdWhZXnay60Y3a yJCTwUMUzwNvFq0iYswwJ1GfvVEwaCrTYCU95XoTj1hp9UkGPzqLJiAw6vgdPWO5sMl0 6QSJQ23WDJ4WJfY/roXh7a03Kdg/IMYLf4erlrZmsQQf7YqogvQx2Gg9pWPWvcQtb+Ms 2B7P0kfwJtENEc8VuZnE9ZOZ0tjHk/6KQfm+DlallF7uT1JWEI6W9uJp61u+OVMSSXlP a063emWG0w7l7nnmfLHCKyuTSH6NpZRJAo/la8uIqXWst82RXncCF5xaVF2DZDNLa6iF eWwg== X-Gm-Message-State: AOJu0YwuA6sx/YoT/MKvJFOVDcd96MjVI6svr3jl+8XvXoemTYL44mIt IkLO9dSirXokO3itYbynnmxIu+JpniZi6pft+S0KfB2d30Jt3Tyj X-Google-Smtp-Source: AGHT+IE9b4oA5hltJDtTG+xkcnEj4r6Axtaqv/dMiFMB0wkMmZU5E6BFD8CUozVrBPN7vJdA7fHU0g== X-Received: by 2002:a05:6000:402a:b0:33a:e525:b15 with SMTP id cp42-20020a056000402a00b0033ae5250b15mr5299565wrb.19.1706566856761; Mon, 29 Jan 2024 14:20:56 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCWYC9WJWivQjomdtYKCOX4ABmRL8treZ1MgYH52brtOZ9cETH3hIDmYAbKBve4BiHvdXiMrq5rszWDXNmax82l+WgaD8awpf8m7CU0nl38zXNAPF8I0IDJ6rcDoVcVnPFTpXPbVlc4BDm7BgxI5b6kyjg== Original-Received: from krug (87-196-75-187.net.novis.pt. [87.196.75.187]) by smtp.gmail.com with ESMTPSA id e12-20020adfa44c000000b0033ae7cd8231sm5310253wra.0.2024.01.29.14.20.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 14:20:56 -0800 (PST) In-Reply-To: (Spencer Baugh's message of "Mon, 29 Jan 2024 16:14:06 -0500") Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42c.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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 29 Jan 2024 22:23:07 -0500 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:315621 Archived-At: Spencer Baugh writes: >> * Are you familiar with how LSP expresses edits? The very same edit can >> be expressed in a multitude of ways. Ultimately, the only way in >> which an edit can be determined to be trivial is by applying it and >> seeing it if was trivial. > > Yes. But a one-element list with the values I described above is pretty > easy to check for. We shall see :-) But it also means that a given server can keep its 100% LSP compliance and break your heuristic from one day to the next, right? Also heads up, the LSP spec has some kind of insertTextModeSupport capability that Eglot doesn't support yet, but might conceivably want to support in the future (maybe not, I admit I don't know very well what it's for.). >>>>> In that case, this code is not necessary, and Eglot doesn't need an >>>>> :exit-function at all. >>>> >>>> Indeed. But how do you plan to know this in advance? >>> >>> And if for all the completion items, we see that we can skip the >>> textEdit behavior, then we don't need an :exit-function at all. >> >> Indeed "for all". So this would mean iterating the full completion list >> for non-trivial computation. Even if that's manageable, are you aware >> that some completion lists are incomplete at first and then are resolved >> to complete lists as the completion session progresses? > > Ok, so maybe :exit-function is still needed, but it can be a no-op most > of the time. I think s/most/some. I'm not 100% clear when this is. But sure, let's assume you're right. >> Also, I hope that you are aware that LSP fundamentally disrepects any >> Emacs completion style. Because unless you can somehow teach Elisp to >> arbitrary language servers on the spot, they really have no idea what >> "flex", "partial-completion", "emacs22" or "orderless" is. >> >> I consider this to be a much, much greater nuisance than the partial >> completion limitations that you picked to start this thread.=20 > > Of course. That is indeed a significant annoyance. > > But to be somewhat provocative: elisp-completion-at-point also doesn't > know anything about completion styles, yet completion-styles still > affect completion with elisp-completion-at-point. I very much appreciate your provocation :-) really do, but I've been through this many times, often with JD Smith, who may already be reading this (I'm CCing him). Again, happy to be proven wrong, but I really doubt it. That's because it's a fundamentally different problem. With elisp-completion-at-point, Emacs functions have near-instantaneous access to the full completion set because these Elisp completions happen to live in the same addressing space as the Emacs that's requesting the completion. So while the table is indeed style-agnostic, estimably so, we can still use Elisp functional tricks to feed the configured completion styles direct access to the full set of completions coming from the table. Now, in LSP, completions have to "come in" from a different processe's addressing space through a comparatively much thinner, less capable straw. There's no portable way to even request the full completion set for a given position, and even if there was it would probably be unmanageable to transmit it fully over JSON. All clients can do is ask the LSP server "given that I have point here in this coordinates, what do you think are reasonable completions?". And then you get 0 or some completions, often not the full set, sometimes not even an indication if it is partial or full. There is no way for styles to "drive" the table like they do the elisp completion table. It may look like there is, but it's an illusion. Some people are using "orderless" with LSP (via Eglot or others), but they're guaranteed to be missing completions here and there except in perhaps in the most trivial cases. >> Anyway, as I said before, I think the starting point for this would have >> to be a systematic structured survey of how Eglot behaves currently in a >> number of language servers (including yours, of course, but not limited >> to it) and encode that as unit tests for Eglot (failing or passing). >> >> That effort is very valuable in itself and it is a prerequisite for any >> deep changes to that function. You can have a look at the exiting >> 'eglot-test-basic-completions' and 'eglot-test-non-unique-completions' >> tests. I'd welcome many more such tests. > > Reasonable. > > I can add some tests of completion with ocamllsp, rust-analyzer, and > pyright. > > Do these tests run with actual language servers in any CI system? If > so, should I make sure that the tests I add, work in that CI system? Yes and no. Mostly yes. Here in Emacs proper the Hydra CI system only has clangd and little more. So a significant chunk of Eglot tests are just skipped. There is the GitHub actions CI set up on GitHub which runs clangd, rust-analyzer, pylsp and some others. You can just clone my Eglot Github repo, copy over Emacs's lisp/progmodes/eglot.el and lisp/progmodes/eglot-tests.el and it should start running your new tests. Adding new servers to the GitHub CI setup shouldn't be terribly hard (though it's a bit laborious, as usual with CI things). You're also welcome to setup your own Micro$oft-less CI solution. > ;; When selecting from the *Completions* > ;; buffer, `proxy' won't have any properties. > ;; A lookup should fix that (github#148) > (get-text-property > 0 'eglot--lsp-item > (cl-find proxy (funcall proxies) :test #'string=3D)) > > :text-function would let you delete this code since you could rely the > text properties being present. Ah OK, that's one of the earlier issues, haven't read that in a while. But sure, pitch this to Stefan. >> For things to be "useful for Eglot" they have to translate to actual >> tangible benefits for Eglot users in some server/major-mode combination >> (and no bugs) >> >> "Eglot users" here means user of: >> >> Emacs -Q some-file.xyz -f eglot >> >> Where "xyz" is potentially _any_ file type managed by _any_ LSP server, >> past or future. >> >> It doesn't mean users of: >> >> Emacs -Q -l my-special-library-or-configuration.el some-file.ocaml -f = eglot >> >> That's _not_ to say the latter isn't useful for some, or even many, >> users. I just don't count that as "useful for Eglot". > > Of course. > > I intend the benefit to be better support for try-completion for any > file type and any LSP server. Great. > And also simplification of the code. Oh, now you're making it sexy > eglot-completion-at-point is a 200 line quite hairy function. I don't > really want to duplicate its code. Of course. I'm not particularly proud of that beast, it just grew that way. LSP's completion section is also the most complicated in the whole spec (and Eglot implements about half of it). You have carte blanche to split it up into multiple functions. I do heartily recommend writing some more tests first. Doesn't need to be an exhaustive battery, but importantly some of these tests must check that Company and completion-at-point keep working and requesting new completions only when they needs to. Maybe some manual testing will be needed or you'll need to ask Dmitry about ways to control company.el popups from tests. > If Eglot exposed parts of eglot-cap as individual APIs, that would > work too, Fine by me. Go for it, really, if you're confident and can demonstrate you haven't broken too many things. For example JD Smith has frequently pitched an idea that would change how eglot-c-a-p does caching, so that it would work perfectly with Corfu by default. He's confident it can work just as well as it does now. See this discussion https://github.com/joaotavora/eglot/discussions/1202#discussioncomment-55= 48656 I've turned the idea down in the past, but if you think it can contribute to your eglot-c-a-p overhaul AND it doesn't break Company and other things, I'm willing to reconsider my opinion. Especially now that icomplete-in-region is a thing and _I think_ it also assumes completion tables behaves like JD/Corfu likes them to. JD can lead the way here, if he's available. Jo=C3=A3o