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: Sat, 27 Jan 2024 14:45:10 +0000 Message-ID: References: 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="20833"; mail-complaints-to="usenet@ciao.gmane.io" To: Spencer Baugh , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 27 15:46:02 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 1rTjwX-0005DQ-H1 for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jan 2024 15:46:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTjw2-0000Rl-5S; Sat, 27 Jan 2024 09:45:30 -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 1rTjw0-0000Pg-3b for emacs-devel@gnu.org; Sat, 27 Jan 2024 09:45:28 -0500 Original-Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rTjvx-0003eL-IH for emacs-devel@gnu.org; Sat, 27 Jan 2024 09:45:27 -0500 Original-Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-50ea9daac4cso1279346e87.3 for ; Sat, 27 Jan 2024 06:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706366722; x=1706971522; darn=gnu.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9ISLgKiwH99k7GXeZHNyuBjESdYomjsSDJWIOOCsLrs=; b=CXOKW0K3dn87ANocJ3ekeVC/tQE1OfcUA3Ft7p32fkzjLHArEeez+f3L2MYxpshx+U vLkPqsyrSAvC9PxOlrVlHZw4WWABL1NkkY/+4UyWp74ry+sr1vtg1I8ZT3qRwJy+3HZW dbiQjp4wVnstiPQt8J/2HgKgKxlxNB++cN+Mysq9Hful9U7Z4O60vKEaifVcgoimpFUl u9H+nxqT7CgPcVjAg4HKlI70oLClcCiSywYNb38N2OCHbD+/aMkoOgTvhxEfQIWqNIRG yY0clKDlvbPv6yB8whJ1jYsaddciBe+k9NL8Tu5/+EUQltXe4RE8XeugRuAIWBDUohq5 DOaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706366722; x=1706971522; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9ISLgKiwH99k7GXeZHNyuBjESdYomjsSDJWIOOCsLrs=; b=b/ax9OQOfaFyZzeBn5Erzn1jH861sf64g5nRO7VmNtQym9cCk/229AEvY2WWXen6q7 +7f/R/+BE6tTTJZ7KU6NxROAdGZD9sxjISRnrId+pY7upMqvFYLUxzY4dcI0H9wG+Ygk v1qjbZMjsAmua6Zaqc4IydgxD9Tw3/D/2acZbG2iv+1NUF1ECwX5uZUBs/qQirWbtaVN 5b5V+Q7PVvSl/uL4VAXzC8MMymBnZE/H0F2wLJcdPyFRc1BTYRj3zhUptPTy/9fnNYoq poUPz5hABVKVqrG/WhaAbyXchmYb047nGhUqsZQEFpR24SnQC3eo74zQAiElJ2pb77Kd FopA== X-Gm-Message-State: AOJu0YwbM+tFEwKht7Xwae4YGgT3ql/tPGh2KBaNmU6VhhFzlIdRLGDC Ca+GF+cj33p+mOL6Q1ZW6yEFVp42VICe/qlnRqcJayYejjxLEpJDPAtXi4aceceQXS67IvyVAev BS87hi4qbcspi4XdL07XibX1hV7g= X-Google-Smtp-Source: AGHT+IGghagmxCexhu+FLv1kOyU3KoVzm+4fxb2snbhVGM39gipCziYXIOHy2tRw4yZgicOnVvddJflSqxATSHAGtO8= X-Received: by 2002:ac2:4c83:0:b0:50e:b2cf:4e20 with SMTP id d3-20020ac24c83000000b0050eb2cf4e20mr963885lfl.24.1706366722018; Sat, 27 Jan 2024 06:45:22 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::12b; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12b.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-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:315487 Archived-At: On Fri, Jan 26, 2024 at 8:38=E2=80=AFPM Spencer Baugh wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.emacs.devel as well. I suppose this email will appear in emacs-devel soon, might as well start answering. > The recent commit d376462c7183752bf44b9bd20bf5020fe7eaf75a prompted by > issue https://github.com/joaotavora/eglot/issues/1339 says: > > >I declare it impossible to make C-M-i use of 'try-completion' behave > >sanely with LSP in its current state. YMMV. Use a completion tooltip, > >like Company. > > So completion from Eglot, which is built into Emacs, is broken out of > the box? No. > It has a hard dependency on using company-mode or similar > third-party packages? No. > If this is the case, perhaps Eglot should make it more clear that it > cannot be used without also installing and using company-mode or some > other package. Perhaps it should abort rather than running if the user > is using the default completion-in-region. This would be nonsense, given the minute dimension of the problem. > Alternatively, as someone who uses default completion-in-region and > would like to use Eglot, is there some way to make the common case > behave correctly? _Your_ common case is not other's. I'd just use it and take note where it breaks down. AFAIK it's _partial_ completion doesn't work as you would expect from simpler completion models that only serve strings. A structured survey of cases using a variety of LSPs would be welcome, if you're inclined to contribute this work. I just fixed a small minor bug in eglot--dumb-tryc, by the way, so make sure you grab latest Eglot. > I guess the issue is that in the LSP protocol, there's a difference > between the "sortText" and "filterText" which are used for displaying > completions and letting the user choose them, and the > "insertText"/"textEdit" which are used for inserting them. Not the only reason, but that's one of them, yes. > So Eglot has this somewhat hacky code which runs in :exit-function to > delete the completion after completion-in-region inserts it, and insert > a different string instead: > > (cond (textEdit > ;; Revert buffer back to state when the edit > ;; was obtained from server. If a `proxy' > ;; "bar" was obtained from a buffer with > ;; "foo.b", the LSP edit applies to that > ;; state, _not_ the current "foo.bar". > (delete-region orig-pos (point)) > (insert (substring bounds-string (- orig-pos (car bounds)))) > (eglot--dbind ((TextEdit) range newText) textEdit > (pcase-let ((`(,beg . ,end) > (eglot-range-region range))) > (delete-region beg end) > (goto-char beg) > (funcall (or snippet-fn #'insert) newText)))) > (snippet-fn > ;; A snippet should be inserted, but using plain > ;; `insertText'. This requires us to delete the > ;; whole completion, since `insertText' is the full > ;; completion's text. > (delete-region (- (point) (length proxy)) (point)) > (funcall snippet-fn (or insertText label)))) > > This is code which is often broken, especially with default > completion-in-region. If you know of broken cases, contact bug-gnu-emacs@gnu.org and provide a full reproducible error recipe according to Eglot's manual (clangd, pyright, or rust-analyzer, gopls preferred, other servers must come with installation instructions. If installation too complex/bloaty it may take a while.) > However, the common case is that sortText=3D=3DinsertText/textEdit. Is it? The above all return textEdits, I think. How can sortText, a JSON string, equal textEdit, a JSON object? > 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? > Can Eglot detect this and avoid this somewhat hacky code in that case? Not easily or cleanly... > It should be a performance improvement and simplification anyway for all > completion frameworks. .. but you can try your hand at a patch. I'd love to be proven wrong. > (BTW, besides the issue with default completion-in-region, I also ran > into this while trying to write an OCaml-specific wrapper for > eglot-completion-at-point function which adds some additional > completions to those returned from the LSP. But if those completions > are chosen, then the Eglot exit-function breaks when it tries to look up > the insertText/textEdit. My LSP doesn't use textEdit at all, though, so > this is another unnecessary breakage) What contract exactly is eglot-completion-at-point breaking? Jo=C3=A3o