From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: joaotavora@gmail.com, bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Aug 2024 01:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 72705@debbugs.gnu.org Cc: joaotavora@gmail.com X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: joaotavora@gmail.com Received: via spool by submit@debbugs.gnu.org id=B.17240323277747 (code B ref -1); Mon, 19 Aug 2024 01:53:02 +0000 Received: (at submit) by debbugs.gnu.org; 19 Aug 2024 01:52:07 +0000 Received: from localhost ([127.0.0.1]:57146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfrZ0-00020s-Lb for submit@debbugs.gnu.org; Sun, 18 Aug 2024 21:52:07 -0400 Received: from lists.gnu.org ([209.51.188.17]:35486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfrYx-00020j-UZ for submit@debbugs.gnu.org; Sun, 18 Aug 2024 21:52:04 -0400 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 1sfrYI-00025y-FJ for bug-gnu-emacs@gnu.org; Sun, 18 Aug 2024 21:51:22 -0400 Received: from fout7-smtp.messagingengine.com ([103.168.172.150]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sfrYG-0000ss-EW for bug-gnu-emacs@gnu.org; Sun, 18 Aug 2024 21:51:22 -0400 Received: from phl-compute-06.internal (phl-compute-06.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id 6D0AD138D5D4 for ; Sun, 18 Aug 2024 21:51:19 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Sun, 18 Aug 2024 21:51:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm2; t=1724032279; x=1724118679; bh=9CjpP5YwIhKVaPmxIDWwezBF1BqQnzvd cIhEJIDuO38=; b=mPGlcpzLPXqRaIkDS74khEUOifXmyS+SH+tvFVcEOOxrlA0P zUqJi4wNd5Bo9a9KHSxmvz6gjwzthS1qkLYyguIlFMOvcvOldm2yQenzxQU0vRvy zlTfTGO8iyekQUW/CY9FXRJVLuIq63vFVmGqmgDm1B/NerDIaPpgiWHipdmetn// WcgJsIS7G3ckDhp7k9PuE4j4gmnhShGKol+Vk6E9QStAtuBsFNtrAYpVvp02aYaw 2sW1p4RYVC66yj2CqbUzTTtBoPWaP5wIHDkEGwwmNcddEHNrjGOlqZEOVyFf0ZPp s6fVdPchQbNKWsvCANM60nxga6iArgWXdB7yIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1724032279; x=1724118679; bh=9CjpP5YwIhKVaPmxIDWwezBF1BqQnzvdcIh EJIDuO38=; b=Q6DTAkxgTXouKuh6HPpgJKvD9MZJC2Qa28KdNMNIiUZ3vlcoHiz 1myiUBbRk9hYRmbDmBlaYMkyp2oeMbqJLskiclAHq6BXlC1uM2Y4OYLuGHNxXVG1 8rHn/f6Qr37CQQJgaiZBKtiRoVE+zng/xJX+nF6WUqpmaMdyz1Qfdh54gmG0FAOy lQnK2UI00pLWgBzEm5a1+g9e0THMqvXDSHMxLEw3hr2hL8JZCUQ/FCZ5NApD6+UD qFubJYaZwmGm3/PXY1acrdaHIiE/X6WuS56Fq+Wra+wGbrjSwZ8ZBohyvWZ+vH6k fE8cv/FCLcAQdCz0rJZ0aoINjx23bx7dX6Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddufedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpegtkfffgg gfvffuhfesmhdtreertddvjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughm ihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeefkeevleeuieegte elheefieeggfffgedtleelhfdvuddtkefgveelieeutdffheenucffohhmrghinhepghhi thhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopedupdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnh hurdhorhhg X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 18 Aug 2024 21:51:18 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------Ne087yXGQwAA5wHdhm38xk7i" Message-ID: Date: Mon, 19 Aug 2024 04:51:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Dmitry Gutov Received-SPF: pass client-ip=103.168.172.150; envelope-from=dmitry@gutov.dev; helo=fout7-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) This is a multi-part message in MIME format. --------------Ne087yXGQwAA5wHdhm38xk7i Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Debbugs-Cc: joaotavora@gmail.com 1. Have a project with just one file, test.go (attached). 2. Visit it, enable go-ts-mode, call 'M-x eglot'. 3. Move point right after "math.As", press C-M-i. 4. Code will get completed to "math.Asin" This is a problem because "math.As" has more completions (one can look at them by pressing TAB after "math.A") - such as "Acos", "Acosh" and "Abs" - in other words, "fuzzy" matches. Expected behavior: 1. When input is "math.As" - keep the string as-is. 2. When input is "math.Asi" - complete to "math.Asin". This problem seems older than 65ea742ed5ec (the change that introduced eglot--dumb-tryc itself, bug#68699), but it doesn't reproduce with Eglot from Emacs 29. Branches emacs-30 and master are affected. There is also another issue there: when there are no completions at all, this style still has completion-try-completion return a non-nil value (the last line of the implementation). Both of these issues is something I came across when working on closer 'try-completion' integration for company-mode (https://github.com/company-mode/company-mode/pull/1488) and testing out the new code with Eglot. Not sure what's the best fix, but the patch below seems to address both problems in my limited testing. WDYT? diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index 353877f60c2..e8823a9d2f0 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -3142,8 +3142,14 @@ eglot--dumb-allc (defun eglot--dumb-tryc (pat table pred point) (let ((probe (funcall table pat pred nil))) (cond ((eq probe t) t) - (probe (cons probe (length probe))) - (t (cons pat point))))) + ((and probe + (cl-every + (lambda (s) (string-prefix-p probe s completion-ignore-case)) + (funcall table pat pred t))) + (cons probe (length probe))) + (t + (and (funcall table pat pred t) + (cons pat point)))))) (add-to-list 'completion-category-defaults '(eglot-capf (styles eglot--dumb-flex))) (add-to-list 'completion-styles-alist '(eglot--dumb-flex eglot--dumb-tryc eglot--dumb-allc)) --------------Ne087yXGQwAA5wHdhm38xk7i Content-Type: text/x-go; charset=UTF-8; name="test.go" Content-Disposition: attachment; filename="test.go" Content-Transfer-Encoding: base64 cGFja2FnZSB0ZXN0CgppbXBvcnQgIm1hdGgiCgpmdW5jIG1haW4oKSB7CgltYXRoLkFzCn0K --------------Ne087yXGQwAA5wHdhm38xk7i-- From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Aug 2024 09:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.172405944622972 (code B ref 72705); Mon, 19 Aug 2024 09:25:01 +0000 Received: (at 72705) by debbugs.gnu.org; 19 Aug 2024 09:24:06 +0000 Received: from localhost ([127.0.0.1]:57658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfycP-0005yR-Mp for submit@debbugs.gnu.org; Mon, 19 Aug 2024 05:24:06 -0400 Received: from mail-oo1-f41.google.com ([209.85.161.41]:46154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfycN-0005xh-Th for 72705@debbugs.gnu.org; Mon, 19 Aug 2024 05:24:05 -0400 Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-5d5b850d969so2602590eaf.0 for <72705@debbugs.gnu.org>; Mon, 19 Aug 2024 02:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724059337; x=1724664137; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YCv0xtEAnnpy9gtgr/IICmhWj96NiXxYoh83gUg2IJU=; b=nNEmEeJgn/r/s0r/ClfIx/g1OPXEvGZvcyzXFtn++LkFw01S4NmVWjvIolWv3N4BZy br39aFBJUYowSJ4KACUZzQ5r2rOF5rF+JBAu78LVXwwSI2EYLpgBaxl3z9hiOfCFhjC9 5GvjxTSKYZ6B5pk1/v4qCpQFcmfG3o34wCwCwQztaD7bZV8OwtONbrN+C28sCJn+ePVa 3WA1HUwoBlAfvv9+apheW52LMa0qQpzK6RMCOkWk7heoFgPIjs1owgO7ebqtEn1dzgHQ ykMrPc8a0SQlpJObqKfyIQuH7gw/1DCaVWxB53MUKCdueflvvPJ2Y61ypiOqImkvkRF+ daUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724059337; x=1724664137; h=content-transfer-encoding:cc: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=YCv0xtEAnnpy9gtgr/IICmhWj96NiXxYoh83gUg2IJU=; b=a//4+th8WzrS16qWb3op2Z529SZdR0jxFAYDs4odtOjJ1nQKjf5LQtXPuVhGhLVHuO DyNYG7XP1J/p1EauzjaHzxkQPQG6kAv2kSIrp9SiBc31Q3fV1PU2mQKNktf4uYmrSE1J JW3MHAHHRbKDXLjgNXUTlQG8hBXt6doqgEx3AGaK2AHXyln6AuB9+3pvP5ru4UWpNIFZ A3z8+/J9ReNZ2MDd5+OafDBWOS5PIgCHY+nTUIiCv6ecO/v57AX9BQM8ETnicKBz/z6y hui5zw/Cbx4gWFyCzwOqpVeOUjuenIrYXSapZq7NX2wAQ54Vhq+0icL8uR/q8gLqr97X 4u2A== X-Gm-Message-State: AOJu0Yzggrb9vG7cg3LNSTSe0E9aonra2OL00nitLpu/sv417DA+3zy3 VT8n023S9vc3ZUkVMp1lO+abO9bh8XqdUPowI2uFEKXpe/iBMzaZ6G6LmQnHbEPuVBwij4yKepf lCDUY91kGpnP/q7+ikNE2xSlT26BQnFyC X-Google-Smtp-Source: AGHT+IHw0Fxx3vnnUFZyFftQbZAmb09JIJXYjLjsc7sN4oqXnyZTln+afPMzghB/5KtwUVg5rvjNeApEDmBuEUSX+Ic= X-Received: by 2002:a05:6820:2295:b0:5d8:e6a:236 with SMTP id 006d021491bc7-5da98012003mr10886670eaf.3.1724059336654; Mon, 19 Aug 2024 02:22:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 19 Aug 2024 10:22:06 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 19, 2024 at 2:52=E2=80=AFAM Dmitry Gutov wro= te: > has more completions > (one can look at them by pressing TAB after "math.A") That's not relevant. LSP servers can make completely different decisions in each position. What's relevant is to look at the completion list returned in the "math.As" case (via the events buffer, for example). > Not sure what's the best fix, but the patch below seems to address both > problems in my limited testing. WDYT? I would be (pleasantly) surprised if your change doesn't break something else. I tried many many variations in the fairly recent past and each of them seemed to break something. Be wary of :exit-function which is where things like snippet conversion and edits happen. So I'd say this need more testing, especially with more servers. I also don't understand why the "string-prefix" is being used. The "dumb" in eglot--dumb-try should be taken to heart. See logs of commits: d376462c7183752bf44b9bd20bf5020fe7eaf75a 4dcbf61c1518dc53061707aeff8887517e050003 a6ef458e3831001b0acad57cf8fa75b77a4aff3f You should also encode whatever decisions you make in tests in eglot-tests.el. From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Aug 2024 11:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.17240676074180 (code B ref 72705); Mon, 19 Aug 2024 11:41:01 +0000 Received: (at 72705) by debbugs.gnu.org; 19 Aug 2024 11:40:07 +0000 Received: from localhost ([127.0.0.1]:57779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sg0k3-00015M-5F for submit@debbugs.gnu.org; Mon, 19 Aug 2024 07:40:07 -0400 Received: from fout5-smtp.messagingengine.com ([103.168.172.148]:55575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sg0k0-00014V-Mr for 72705@debbugs.gnu.org; Mon, 19 Aug 2024 07:40:05 -0400 Received: from phl-compute-07.internal (phl-compute-07.nyi.internal [10.202.2.47]) by mailfout.nyi.internal (Postfix) with ESMTP id 7552E138FFFE; Mon, 19 Aug 2024 07:39:17 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Mon, 19 Aug 2024 07:39:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1724067557; x=1724153957; bh=Le2GZo1TtkmF0xgsPLhgeaFn3Z6fNCPleBufyg6vUVw=; b= oWXjcrIVPl6T/49ZAk7bLKlRDFAusmgBw+TRtNRkkr4tDbAYqQ0Q4xnPfCOFmIQN Xh5/E7thg3emuxFsfP/8dPRmfYsxY3i8VyYPP91Y5bea3GT0e2TEmML5kX1Lr2Fb ZVevCg+UTYS/aiYskZQIdhzqIIijORaaS0f5UkyLAdZUAHklvVvYovaLQCyDE5eY hJZpP1Ud4Dxnyzfa7ibEK86Pzi2OBY8HP3Z9mSqqePykgelf4xEmHQcgmGd063m5 u2hWu1fhDGvK+CR09B6WUS8gLWlle6+HWx1FW/kGIfsO35SIhuJRAVyGLgLst2oo 5+b7nrXWm/+SuToRjgkF+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1724067557; x= 1724153957; bh=Le2GZo1TtkmF0xgsPLhgeaFn3Z6fNCPleBufyg6vUVw=; b=j gj4api9W4LwyhegSIV/eV0LVzbsGPoV2ERtE/KcZ95wO5FXJDDD+7geteRUgs7IV h6yV+69jDYxS+npBITnKgFvdMooeCwS1xilcjtvsuOYBFOc5Xi04KrJYdrq3o43L gxbRPWW3IVeB4YJDdRwFce9gmFMjMY6B/zoL2i8Jq/x72jtQgkVyvIrV3+ReLDEt Q09hZKGH/mk2OSXhZ0wxQOFPWLfpoJFALko/vHLQc5hu8vYNvLa8qu5bcISsTJkV Q3EAbs23U09QCdLYbcwrcCTjNVfGyBQXdobQZ3BxQOEYd1iBAHWC/yRDRirUQYDk 8LtlYSmz4loEjAl2Yg7kA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddugedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveeg tedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho pedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjohgrohhtrghvohhrrgesgh hmrghilhdrtghomhdprhgtphhtthhopeejvdejtdehseguvggssghughhsrdhgnhhurdho rhhg X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 19 Aug 2024 07:39:15 -0400 (EDT) Message-ID: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> Date: Mon, 19 Aug 2024 14:39:13 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 19/08/2024 12:22, João Távora wrote: > On Mon, Aug 19, 2024 at 2:52 AM Dmitry Gutov wrote: > >> has more completions >> (one can look at them by pressing TAB after "math.A") > > That's not relevant. LSP servers can make completely different > decisions in each position. What's relevant is to look at the completion > list returned in the "math.As" case (via the events buffer, for example). True, but it's hard to look at completions for "math.As" using completion-at-point because try-completion behaves this way. You can also check out Company's completions popup for "math.As" - it shows the extra ones. >> Not sure what's the best fix, but the patch below seems to address both >> problems in my limited testing. WDYT? > > I would be (pleasantly) surprised if your change doesn't break something > else. I tried many many variations in the fairly recent past and each > of them seemed to break something. Be wary of :exit-function > which is where things like snippet conversion and edits happen. > So I'd say this need more testing, especially with more servers. Here's hoping. > I also don't understand why the "string-prefix" is being used. > The "dumb" in eglot--dumb-try should be taken to heart. string-prefix-p is being used because 'try-completion' will ignore non-prefix completions as if they weren't there. We need to make sure that the proposed "probe" is indeed a prefix for all completions. > See logs of commits: > d376462c7183752bf44b9bd20bf5020fe7eaf75a > 4dcbf61c1518dc53061707aeff8887517e050003 > a6ef458e3831001b0acad57cf8fa75b77a4aff3f > > You should also encode whatever decisions you make in > tests in eglot-tests.el. Thanks for the references, I'll dig in more. Surprised to hear that exit-function can be affected. From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Aug 2024 13:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.172407248612920 (code B ref 72705); Mon, 19 Aug 2024 13:02:02 +0000 Received: (at 72705) by debbugs.gnu.org; 19 Aug 2024 13:01:26 +0000 Received: from localhost ([127.0.0.1]:57874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sg20g-0003MG-N5 for submit@debbugs.gnu.org; Mon, 19 Aug 2024 09:01:26 -0400 Received: from mail-oo1-f53.google.com ([209.85.161.53]:60824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sg20e-0003M0-9Q for 72705@debbugs.gnu.org; Mon, 19 Aug 2024 09:01:21 -0400 Received: by mail-oo1-f53.google.com with SMTP id 006d021491bc7-5d5e97b84fbso2465390eaf.1 for <72705@debbugs.gnu.org>; Mon, 19 Aug 2024 06:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724072373; x=1724677173; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AXnFgK55mm6aN96CdJW3ta3e4LwMq/6V9NfeszftfbI=; b=j3UFHjVsTPq6qbONjIL2W1a7yw/hl6abdK6/h9SJv9Ow7DK3lfOO5ldTz65NUvf95I Of2g63OfYhijZLF7o/FAQafYRQxk+NyCbF9DbuwE2G4W9ZC2PZ673U1TGBOwzA6US6L8 GA4kmmDj3zryS2nSY3rZIgsRrb4gbMvcMfcC8kYO+UYtp6lArnL/KQbT4o69UerK2Cbk 5BNhJ7loG5WWX9lB010nQG0QrF54KJGHwJWHpWbcNw/ZNx1GYPXJPZhogE/AwUkvdmZz ja6s9PJspnxc+7sc/by9U25Rk56g34x73EAYdksBgl6KcIPEyLkNhDjc05LWAgPHdIEM zv2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724072373; x=1724677173; h=content-transfer-encoding:cc: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=AXnFgK55mm6aN96CdJW3ta3e4LwMq/6V9NfeszftfbI=; b=wzFi19LyV1x/7Etanw2xs6PRZeceEbndst6JfOTU9dISmkm8SoFfy1sE/2Cm/xeDy/ b0VbG0iyDskVS+U9xwStHjHT79jgkkwobG7mHn2kieG5fKDVzd5FOxDDfKlm5lBKpzbL jj5T8VT4oLt7anA9FkWtYWCnqCBo8fOzeryU0HIb0LoeAw6Bt9TDlKptW3FZ1+po8iVZ Nrc5ev9x7zrSTY7DfIwGx7nXKCS0NHEdIWRoDQY8NVj+D8dDxOqTnFAaTm8CBrx1Jl/c bMa3Oi79kbWxpvnj5FgX+CR9dReOXVWPlBcv4+taTcKbnetEs89W+8xjbaCjjtbeNwNj lFkQ== X-Gm-Message-State: AOJu0YwJh/eU+u0s6pwzej9M0Kq77xDnk7cBiZFoIbn+77IJVN8/vIfp oTgxivfYKG291l3czk/tE0nb8dq72xsZrCBU+dhfCqeenaH/OZP+WAa2p8Kr+PdtKut5zAGZ/br n2dC6QsaZDBK+0b83Ax3YDjV56JQ= X-Google-Smtp-Source: AGHT+IE+RQ7/sr3GoEpIFcyye3pkMsD1adztmWDJSeFfFLyz6L4FDkafG5wMhhdEfGlDrE5H4AKyna7gwJ84Z5WKm3o= X-Received: by 2002:a05:6820:1acc:b0:5d5:d7fc:955c with SMTP id 006d021491bc7-5da9801a875mr10913848eaf.5.1724072372656; Mon, 19 Aug 2024 05:59:32 -0700 (PDT) MIME-Version: 1.0 References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> In-Reply-To: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 19 Aug 2024 13:59:22 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 19, 2024 at 12:39=E2=80=AFPM Dmitry Gutov wr= ote: > > So I'd say this need more testing, especially with more servers. > Here's hoping. If you want this change, you'll have to do the testing. > Thanks for the references, I'll dig in more. > > Surprised to hear that exit-function can be affected. exit-function needs a fully formed completion. try-completion's and Emacs partial complete semantics aren't compatible. ISTR that even a full completion obtained via try-completion would sometimes not run the function. Maybe I'm misremembering. This whole system is held up by very thin wires unfortunately, and a lot of people are relying on those wires. The best choice to use LSP's completions, which were obviously modelled after other IDEs where completions are much simpler and similar to the Company tooltip... is naturally to use something like company (or corfu with some patch applied). I hope you don't change any Company behaviour backward-incompatibly (though I have my fork anyway, so no problem). Jo=C3=A3o From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Aug 2024 02:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.172411975332635 (code B ref 72705); Tue, 20 Aug 2024 02:10:01 +0000 Received: (at 72705) by debbugs.gnu.org; 20 Aug 2024 02:09:13 +0000 Received: from localhost ([127.0.0.1]:59498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgEJ6-0008UH-DG for submit@debbugs.gnu.org; Mon, 19 Aug 2024 22:09:12 -0400 Received: from fhigh1-smtp.messagingengine.com ([103.168.172.152]:51445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgEJ4-0008U4-3g for 72705@debbugs.gnu.org; Mon, 19 Aug 2024 22:09:11 -0400 Received: from phl-compute-05.internal (phl-compute-05.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 284871151B4B; Mon, 19 Aug 2024 22:08:22 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 19 Aug 2024 22:08:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1724119702; x=1724206102; bh=t0WsjGYs1S rhjNWpabpNAsXBk25Uu5jx+x9F0EZnnPU=; b=X5sinBYeuYRUnBg0WCgDCXvg5J zCGZ8MbxwiQ/+TSqMlWROqyeECSUBUmTOoX96VjTdtFbgf+RPpSmV8HXJWPXaWzH SWcEEC1ACl7TsDvKaNTOU5YR/qlibIH0Bm1zmSmRljhgmm/bN/5qtHjoiidTjlBZ kRspl8DRTgoUzVw5N+3Kc4mIr10rTAca+0M+/gt7YsvXYJSAnYgyiR0m/P6jOBaS 893uNSzuVXtztaVZ3c272x7RXTXZBl4VulO/p7igJK7beLHOv8yLxgeQYPpFi2yX HWf86ldVdsMgqdLYDT2oqWAK7bEsfh4hT1AFRwaG+LH9xG68mgMOZ54TfkRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1724119702; x=1724206102; bh=t0WsjGYs1SrhjNWpabpNAsXBk25U u5jx+x9F0EZnnPU=; b=HtTCXoSPSvH+tklFoao287lNWaGzAVh1ol6dfAgf5ksH WmgkNwVHA68VdzZBbKrMDYcODQGPXymxzv5AfHvr9Oysz/qpsY3Y+MZ1NmEY6HtQ YLf0V4XUEd5s7urL6D64XMf6+FS04T0gxSosbwmGkRz/lUHLzVJGJuvPnXgaFaho JUFVNmqfPmtJRJYocTfqSUiqcHqLKa+JWJolfR1p4eTh/MVGuo/pfn5dG+S/WkDw 3Cs8aMptMHoaa/Yi+MKZDLvSOmTfXLWvIfHrMm5/VvpURa8JUqm2FVNIBSYb3C37 /nv4ymeaM5VN6Mg/ZqaNrv90n5CcoJchTcBiEFtFFQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudduhedgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpefhleektdfgfedttdeuteeijeevtdffgeekgfethedv vdevhfelleefieeuueehfeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehg uhhtohhvrdguvghvpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprh gtphhtthhopehjohgrohhtrghvohhrrgesghhmrghilhdrtghomhdprhgtphhtthhopeej vdejtdehseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 19 Aug 2024 22:08:21 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------T4UGtGQT4rcQv4uN3TEjMO4n" Message-ID: <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> Date: Tue, 20 Aug 2024 05:08:19 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> Content-Language: en-US From: Dmitry Gutov In-Reply-To: X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------T4UGtGQT4rcQv4uN3TEjMO4n Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 19/08/2024 15:59, João Távora wrote: > On Mon, Aug 19, 2024 at 12:39 PM Dmitry Gutov wrote: > >>> So I'd say this need more testing, especially with more servers. >> Here's hoping. > > If you want this change, you'll have to do the testing. So far I've tested with gopls and clangd (when writing the new tests), typescript-language-server and rust-analyzer. >> Thanks for the references, I'll dig in more. >> >> Surprised to hear that exit-function can be affected. > > exit-function needs a fully formed completion. try-completion's > and Emacs partial complete semantics aren't compatible. ISTR > that even a full completion obtained via try-completion would > sometimes not run the function. Maybe I'm misremembering. All right. The proposed change doesn't alter the kinds of strings that are inserted, only the cases when that happens. When the added predicate returns nil, we fall back to the next clause; and the check at the end also allows us to return nil, which is useful in certain rare contexts. > This whole system is held up by very thin wires unfortunately, > and a lot of people are relying on those wires. The best choice > to use LSP's completions, which were obviously modelled after > other IDEs where completions are much simpler and similar to > the Company tooltip... is naturally to use something like > company (or corfu with some patch applied). > > I hope you don't change any Company behaviour backward-incompatibly > (though I have my fork anyway, so no problem). The change is in a pending PR, it's designed to be opt-in on the backend level, but company-capf is a separate backend, so... you know. It alters what happens when you explicitly press TAB, which previously only did prefix-matching inside Company code, but now can delegate to backends for some extra smarts (longer expansions being the goal), which unfortunately don't work too well with LSP. The report that's referenced in the 3 commits your mentioned does seem to have regressed is https://github.com/joaotavora/eglot/issues/1339 - not to the original behavior (exit-function still works), but C-M-i changes buffer text to v.call1234.1234567890 Not sure how important that case is, but it's a consequence of having the style return nil in try-completion and unavoidable failover to 'basic' because of that (in completion--styles, because a category can't actually override, only prepend styles). I suppose that could be fixed by moving some matching logic from the style into the completion table. Not sure how important/realistic the example is, although somebody did report it... In the meantime, here's an updated patch with 3 new tests (and existing ones all passing). The implementation has been retouched too for better performance (the typescript server in particular made things slower with the previous proposal). --------------T4UGtGQT4rcQv4uN3TEjMO4n Content-Type: text/x-patch; charset=UTF-8; name="eglot--dumb-tryc-more-checks.diff" Content-Disposition: attachment; filename="eglot--dumb-tryc-more-checks.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL2VnbG90LmVsIGIvbGlzcC9wcm9nbW9kZXMv ZWdsb3QuZWwKaW5kZXggMzUzODc3ZjYwYzIuLjc0NGYyYjI2YzNiIDEwMDY0NAotLS0gYS9s aXNwL3Byb2dtb2Rlcy9lZ2xvdC5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9lZ2xvdC5lbApA QCAtMzE0Miw4ICszMTQyLDE2IEBAIGVnbG90LS1kdW1iLWFsbGMKIChkZWZ1biBlZ2xvdC0t ZHVtYi10cnljIChwYXQgdGFibGUgcHJlZCBwb2ludCkKICAgKGxldCAoKHByb2JlIChmdW5j YWxsIHRhYmxlIHBhdCBwcmVkIG5pbCkpKQogICAgIChjb25kICgoZXEgcHJvYmUgdCkgdCkK LSAgICAgICAgICAocHJvYmUgKGNvbnMgcHJvYmUgKGxlbmd0aCBwcm9iZSkpKQotICAgICAg ICAgICh0IChjb25zIHBhdCBwb2ludCkpKSkpCisgICAgICAgICAgKHByb2JlCisgICAgICAg ICAgIChpZiAoYW5kIChub3QgKGVxdWFsIHByb2JlIHBhdCkpCisgICAgICAgICAgICAgICAg ICAgIChjbC1ldmVyeQorICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAocykgKHN0cmlu Zy1wcmVmaXgtcCBwcm9iZSBzIGNvbXBsZXRpb24taWdub3JlLWNhc2UpKQorICAgICAgICAg ICAgICAgICAgICAgKGZ1bmNhbGwgdGFibGUgcGF0IHByZWQgdCkpKQorICAgICAgICAgICAg ICAgKGNvbnMgcHJvYmUgKGxlbmd0aCBwcm9iZSkpCisgICAgICAgICAgICAgKGNvbnMgcGF0 IHBvaW50KSkpCisgICAgICAgICAgKHQKKyAgICAgICAgICAgKGFuZCAoZnVuY2FsbCB0YWJs ZSBwYXQgcHJlZCB0KQorICAgICAgICAgICAgICAgIChjb25zIHBhdCBwb2ludCkpKSkpKQog CiAoYWRkLXRvLWxpc3QgJ2NvbXBsZXRpb24tY2F0ZWdvcnktZGVmYXVsdHMgJyhlZ2xvdC1j YXBmIChzdHlsZXMgZWdsb3QtLWR1bWItZmxleCkpKQogKGFkZC10by1saXN0ICdjb21wbGV0 aW9uLXN0eWxlcy1hbGlzdCAnKGVnbG90LS1kdW1iLWZsZXggZWdsb3QtLWR1bWItdHJ5YyBl Z2xvdC0tZHVtYi1hbGxjKSkKZGlmZiAtLWdpdCBhL3Rlc3QvbGlzcC9wcm9nbW9kZXMvZWds b3QtdGVzdHMuZWwgYi90ZXN0L2xpc3AvcHJvZ21vZGVzL2VnbG90LXRlc3RzLmVsCmluZGV4 IDUzNGM0N2IyNjQ2Li42MjViZTJlYTMwZiAxMDA2NDQKLS0tIGEvdGVzdC9saXNwL3Byb2dt b2Rlcy9lZ2xvdC10ZXN0cy5lbAorKysgYi90ZXN0L2xpc3AvcHJvZ21vZGVzL2VnbG90LXRl c3RzLmVsCkBAIC02MDAsNiArNjAwLDIwIEBAIGVnbG90LXRlc3QtYmFzaWMtY29tcGxldGlv bnMKICAgICAgIChtZXNzYWdlIChidWZmZXItc3RyaW5nKSkKICAgICAgIChzaG91bGQgKGxv b2tpbmctYmFjayAiZnByaW50Zi4/IikpKSkpCiAKKyhlcnQtZGVmdGVzdCBlZ2xvdC10ZXN0 LWNvbW1vbi1wcmVmaXgtY29tcGxldGlvbiAoKQorICAiVGVzdCBjb21wbGV0aW9uIGFwcGVu ZGluZyB0aGUgY29tbW9uIHByZWZpeC4iCisgIChza2lwLXVubGVzcyAoZXhlY3V0YWJsZS1m aW5kICJjbGFuZ2QiKSkKKyAgKGVnbG90LS13aXRoLWZpeHR1cmUKKyAgICAgIGAoKCJwcm9q ZWN0IiAuICgoImNvaXNvLmMiIC4KKyAgICAgICAgICAgICAgICAgICAgICAgLChjb25jYXQg ImludCBmb29fYmFyOyBpbnQgZm9vX2Jhcl9iYXo7IgorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAiaW50IG1haW4oKSB7Zm9vIikpKSkpCisgICAgKHdpdGgtY3VycmVudC1i dWZmZXIKKyAgICAgICAgKGVnbG90LS1maW5kLWZpbGUtbm9zZWxlY3QgInByb2plY3QvY29p c28uYyIpCisgICAgICAoZWdsb3QtLXdhaXQtZm9yLWNsYW5nZCkKKyAgICAgIChnb3RvLWNo YXIgKHBvaW50LW1heCkpCisgICAgICAoY29tcGxldGlvbi1hdC1wb2ludCkKKyAgICAgIChz aG91bGQgKGxvb2tpbmctYmFjayAie2Zvb19iYXIiKSkpKSkKKwogKGVydC1kZWZ0ZXN0IGVn bG90LXRlc3Qtbm9uLXVuaXF1ZS1jb21wbGV0aW9ucyAoKQogICAiVGVzdCBjb21wbGV0aW9u IHJlc3VsdGluZyBpbiAnQ29tcGxldGUsIGJ1dCBub3QgdW5pcXVlJy4iCiAgIChza2lwLXVu bGVzcyAoZXhlY3V0YWJsZS1maW5kICJjbGFuZ2QiKSkKQEAgLTYxOSw2ICs2MzMsMzYgQEAg ZWdsb3QtdGVzdC1ub24tdW5pcXVlLWNvbXBsZXRpb25zCiAgICAgICAgIChmb3J3YXJkLWxp bmUgLTEpCiAgICAgICAgIChzaG91bGQgKGxvb2tpbmctYXQgIkNvbXBsZXRlLCBidXQgbm90 IHVuaXF1ZSIpKSkpKSkpCiAKKyhlcnQtZGVmdGVzdCBlZ2xvdC10ZXN0LXN0b3AtY29tcGxl dGlvbi1vbi1ub25wcmVmaXggKCkKKyAgIlRlc3QgY29tcGxldGlvbiBhbHNvIHJlc3VsdGlu ZyBpbiAnQ29tcGxldGUsIGJ1dCBub3QgdW5pcXVlJy4iCisgIChza2lwLXVubGVzcyAoZXhl Y3V0YWJsZS1maW5kICJjbGFuZ2QiKSkKKyAgKGVnbG90LS13aXRoLWZpeHR1cmUKKyAgICAg IGAoKCJwcm9qZWN0IiAuICgoImNvaXNvLmMiIC4KKyAgICAgICAgICAgICAgICAgICAgICAg LChjb25jYXQgImludCBmb290OyBpbnQgZm9vdGVyOyBpbnQgZm9fb2JhcjsiCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICJpbnQgbWFpbigpIHtmb28iKSkpKSkKKyAgICAo d2l0aC1jdXJyZW50LWJ1ZmZlcgorICAgICAgICAoZWdsb3QtLWZpbmQtZmlsZS1ub3NlbGVj dCAicHJvamVjdC9jb2lzby5jIikKKyAgICAgIChlZ2xvdC0td2FpdC1mb3ItY2xhbmdkKQor ICAgICAgKGdvdG8tY2hhciAocG9pbnQtbWF4KSkKKyAgICAgIChjb21wbGV0aW9uLWF0LXBv aW50KQorICAgICAgKHNob3VsZCAobG9va2luZy1iYWNrICJmb28iKSkpKSkKKworKGVydC1k ZWZ0ZXN0IGVnbG90LXRlc3QtdHJ5LWNvbXBsZXRpb24tbm9tYXRjaCAoKQorICAiVGVzdCBj b21wbGV0aW9uIHRhYmxlIHdpdGggbm9uLW1hdGNoaW5nIGlucHV0LCByZXR1cm5pbmcgbmls LiIKKyAgKHNraXAtdW5sZXNzIChleGVjdXRhYmxlLWZpbmQgImNsYW5nZCIpKQorICAoZWds b3QtLXdpdGgtZml4dHVyZQorICAgICAgYCgoInByb2plY3QiIC4gKCgiY29pc28uYyIgLgor ICAgICAgICAgICAgICAgICAgICAgICAsKGNvbmNhdCAiaW50IG1haW4oKSB7YWJjIikpKSkp CisgICAgKHdpdGgtY3VycmVudC1idWZmZXIKKyAgICAgICAgKGVnbG90LS1maW5kLWZpbGUt bm9zZWxlY3QgInByb2plY3QvY29pc28uYyIpCisgICAgICAoZWdsb3QtLXdhaXQtZm9yLWNs YW5nZCkKKyAgICAgIChnb3RvLWNoYXIgKHBvaW50LW1heCkpCisgICAgICAoc2hvdWxkCisg ICAgICAgKG51bGwKKyAgICAgICAgKGNvbXBsZXRpb24tdHJ5LWNvbXBsZXRpb24KKyAgICAg ICAgICJhYmMiCisgICAgICAgICAobnRoIDIgKGVnbG90LWNvbXBsZXRpb24tYXQtcG9pbnQp KSBuaWwgMykpKSkpKQorCiAoZXJ0LWRlZnRlc3QgZWdsb3QtdGVzdC1iYXNpYy14cmVmICgp CiAgICJUZXN0IGJhc2ljIHhyZWYgZnVuY3Rpb25hbGl0eSBpbiBhIGNsYW5nZCBMU1AuIgog ICAoc2tpcC11bmxlc3MgKGV4ZWN1dGFibGUtZmluZCAiY2xhbmdkIikpCg== --------------T4UGtGQT4rcQv4uN3TEjMO4n-- From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Aug 2024 09:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.172414683716388 (code B ref 72705); Tue, 20 Aug 2024 09:41:02 +0000 Received: (at 72705) by debbugs.gnu.org; 20 Aug 2024 09:40:37 +0000 Received: from localhost ([127.0.0.1]:59902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgLLw-0004GE-Tf for submit@debbugs.gnu.org; Tue, 20 Aug 2024 05:40:37 -0400 Received: from mail-oi1-f176.google.com ([209.85.167.176]:58804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgLLu-0004Fu-Og for 72705@debbugs.gnu.org; Tue, 20 Aug 2024 05:40:35 -0400 Received: by mail-oi1-f176.google.com with SMTP id 5614622812f47-3db19caec60so3360030b6e.1 for <72705@debbugs.gnu.org>; Tue, 20 Aug 2024 02:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724146726; x=1724751526; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4hABxycDZc18QRd7ndWj1tWcDVA2+zA4ImAjCWKrN/Q=; b=QXt250aG4fkcuWcn5tpqsg4CD/09/VE7XW9o91yj9fxRjEXTDgupfeEmkjsTcFtCYe xbJQoerdBMVAulZ4Ipc9BXcbB/NQ5kte7BdOKIEPaYLdPlwOz0L6spZV8ab3Ov3hCLfI equO9v2850dU/Lu6BYlHwxzBCFxA7pv1RBKPeNehS5bcuqWbgvO5N7pYC2cX+N7Nfhf8 Z9T7y9rSwXAjRh5MLUMkrMuHgGZpI1wVC6qSqZsz0rvAkm7W8LPVCDxYt/FW4N7Ph+lv FXPlemyZadA63FlaZ/7C8KDY1bx5BB7XMCiVJI/LzCR5E413d7nuJtDitq0+zoQjcn9g 4gzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724146726; x=1724751526; h=content-transfer-encoding:cc: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=4hABxycDZc18QRd7ndWj1tWcDVA2+zA4ImAjCWKrN/Q=; b=WoO6bkM/FBGzHxRGp2Ogn1UpA5ZWi+HMY+IpdfPhE6QiUQJEgCmGKAB9GNRoH5rNse OSdiI+lZIP/rqnXvQdof+dLysQOn08ZO1x4OEw1mJG7alh810SHbzC8vXvZyiAgnD+Vz u5j8VqfjliXq5tFVqqeSb5kRdhPga3BMixJzJ/O/U4/C1mM88yroAKq/i752UrtSyyt5 5PGQBSvL5/aNmTQ6cP8JZkzZMugoAJXsy//qLTtCxuTTmq+cUrISe8PGUcsjTWFmGiJV 8SiuXfYeeLE6plnFeB1hLPTZo97x2fHGNtLOIKc6P+qhp8bGPg6p0ip51vg2QvraiAlz SpKg== X-Gm-Message-State: AOJu0YxBX8iDebVE5DBY+85bx61vNSw0Gj9FRF7fdgrqiESK/B6xTZ+w MLaL02CHUa6+u7/E7pcpde2TMQggs5yzsVfIrw2DkXKJom0Sr6xFIRXLvpxOgubChmebajYiYWy WGFLrFSQ8wlY1ZyrediiioIP18io= X-Google-Smtp-Source: AGHT+IFbAUjzIBjJ1hdeG0aV5UPsoN34hWglZcVDZEIxQAmgncuMg8ExKRXtgCb0gRzdazia2jWn0p5HX23IZ9nrNDg= X-Received: by 2002:a05:6808:150e:b0:3d9:3649:9087 with SMTP id 5614622812f47-3dd3af827f1mr17913189b6e.41.1724146725974; Tue, 20 Aug 2024 02:38:45 -0700 (PDT) MIME-Version: 1.0 References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> In-Reply-To: <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Tue, 20 Aug 2024 10:40:01 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Aug 20, 2024 at 3:08=E2=80=AFAM Dmitry Gutov wro= te: > So far I've tested with gopls and clangd (when writing the new tests), > typescript-language-server and rust-analyzer. That's pretty good. If you could add pylsp or pyright (basedpyright), I'd feel even more confident. > All right. > > The proposed change doesn't alter the kinds of strings that are > inserted, only the cases when that happens. When the added predicate > returns nil, we fall back to the next clause; and the check at the end > also allows us to return nil, which is useful in certain rare contexts. I don't have time to spend examining these details, just the final outcome is relevant: partial completions cannot be inserted, but fragments of a completion can be completed to a fully formed completion (eventually running exit-function then). > The report that's referenced in the 3 commits your mentioned does seem > to have regressed is https://github.com/joaotavora/eglot/issues/1339 > not to the original behavior (exit-function still works), but C-M-i > changes buffer text to > > v.call1234.1234567890 I don't have time to investigate right now, but indeed that issue there wer= e two consecutive fixes: the first one (which you say "still works") and a se= cond one which I eventually reverted because it fixes some things and broke others. So is the regression you mention in relation to the current Eglot state or to that intermediate state? Regardless, if possible, make an automated test and mark it "expected failing" to record this fact. > I suppose that could be fixed by moving some matching logic from the > style into the completion table. Not sure how important/realistic the > example is, although somebody did report it... I'd have to have a clearer view on what exactly has regressed and what has advanced. Then a better decision can be made. Thank you for this work. Jo=C3=A3o From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Aug 2024 00:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.172420027515341 (code B ref 72705); Wed, 21 Aug 2024 00:32:01 +0000 Received: (at 72705) by debbugs.gnu.org; 21 Aug 2024 00:31:15 +0000 Received: from localhost ([127.0.0.1]:34643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgZFr-0003zM-0Y for submit@debbugs.gnu.org; Tue, 20 Aug 2024 20:31:15 -0400 Received: from fout4-smtp.messagingengine.com ([103.168.172.147]:52283) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgZFo-0003z5-7q for 72705@debbugs.gnu.org; Tue, 20 Aug 2024 20:31:14 -0400 Received: from phl-compute-05.internal (phl-compute-05.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 18C3E139006F; Tue, 20 Aug 2024 20:30:23 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Tue, 20 Aug 2024 20:30:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1724200222; x=1724286622; bh=C7JOcnaau5 aSy68aB09dYTolDnLZJvEm3XqtL/bbg6Y=; b=E/XBsdwUDpe/jT10viJ/1dVnNH wXF0F6PVPxmPz/af6zVw8/mDRVNrcZnswL3l9HasVCpgZUrfDAkO8lBsScj49Zta OtSeD6XJDnHCC1BLxVxOCiviJTj0tCxo2XZuWLvPR225A/l1QeKa/F4Br/kkQVqV J3UPRxm7wg0Mxj2+Z0LN+nmB1yzt39GsAhzFprLUNP9nFgvnK98D/lXgr05qdsE2 SWdWLTdg25TykYJm5lVWL7dLf7kCQZ+kl5ZaJSgY+YH7z4B3TJqlYbKoFYFwarNC IgVfH86njNEUAEtpX8f744cUz6nchexx8+VA8/eg5KhrQ4dkNNqMcPZhomEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1724200222; x=1724286622; bh=C7JOcnaau5aSy68aB09dYTolDnLZ JvEm3XqtL/bbg6Y=; b=D8oW8OoEC2v/+/I42in6Upn8HkOqcTbVvxR1cDdOl5kR aW41b+i4u++DiZN2SU7/cQNzL+aXQm6rSChnpMugFdVM3rxLDMV43WPKX8Qini6m AayAR2G8nxPTZWJ1AndnT5EyPgeP3oI9kntUk+hTpNA4kx2DHQMGGO+ttA+fGc3D 60pQv/6tg1/zSl3wYxL5FZjI+6kuNXQXfMZbkYeFN9dWdtmWtdE+/vBX2MagK6Ay TjmIRWc0D4tQ1pCqUe33tRvPaoAIhgbyp1BfNvfjGHuxCgPnXT5x2hs9ZZC+OZVt 3cgbk8Kc+kDTALyVmA9x70KUJDb1stke8W5eylDyxw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddujedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpefhleektdfgfedttdeuteeijeevtdffgeekgfethedv vdevhfelleefieeuueehfeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehg uhhtohhvrdguvghvpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprh gtphhtthhopehjohgrohhtrghvohhrrgesghhmrghilhdrtghomhdprhgtphhtthhopeej vdejtdehseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Aug 2024 20:30:20 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------vDpKdcKfCe8K1U9PZwR4G8Nc" Message-ID: <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> Date: Wed, 21 Aug 2024 03:30:18 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> Content-Language: en-US From: Dmitry Gutov In-Reply-To: X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------vDpKdcKfCe8K1U9PZwR4G8Nc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 20/08/2024 12:40, João Távora wrote: > On Tue, Aug 20, 2024 at 3:08 AM Dmitry Gutov wrote: > >> So far I've tested with gopls and clangd (when writing the new tests), >> typescript-language-server and rust-analyzer. > > That's pretty good. If you could add pylsp or pyright (basedpyright), > I'd feel even more confident. Installed pylsp with apt - the basic things I tested seem to work too. > I don't have time to spend examining these details, just the final > outcome is relevant: partial completions cannot be inserted, but > fragments of a completion can be completed to a fully formed > completion (eventually running exit-function then). And only fragments that prefix-match all completions as prefix. exit-function seems to function. >> The report that's referenced in the 3 commits your mentioned does seem >> to have regressed is https://github.com/joaotavora/eglot/issues/1339 >> not to the original behavior (exit-function still works), but C-M-i >> changes buffer text to >> >> v.call1234.1234567890 > > I don't have time to investigate right now, but indeed that issue there were > two consecutive fixes: the first one (which you say "still works") and a second > one which I eventually reverted because it fixes some things and broke > others. Now that I've looked at them a few more times - all 3 changes were in the completion table, whereas I'm altering the completion style here. And indeed what seems to be the crux of the previous improvement (working exit-function) stays around. > So is the regression you mention in relation to the current Eglot state or > to that intermediate state? In relation to the current state, but I think I've figured it out - see the new revision attached. So what I think what was happening, is since the style was returning nil when the input has a non-matching suffix, the 'emacs22' style came into play (style which only looks at the prefix) and expanded the input from "c" to "call". Anyway, the attached avoids the failover by returning non-nil in the last clause, if at least the prefix matches the table. That makes "C-M-i" keep the input at "v.c|1234" (with two completions: "match" and "call") - but selecting either of the completions using Company or the mouse, or M-RET, expands each into the corresponding snippet, which seems most optimal all-around. See the new test 'eglot-test-try-completion-inside-symbol' inside the patch. Wasn't sure whether to make it use 'completion-try-completion' or 'completion-at-point', but the former seems more explicit. --------------vDpKdcKfCe8K1U9PZwR4G8Nc Content-Type: text/x-patch; charset=UTF-8; name="eglot--dumb-tryc-more-checks-v2.diff" Content-Disposition: attachment; filename="eglot--dumb-tryc-more-checks-v2.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL2VnbG90LmVsIGIvbGlzcC9wcm9nbW9kZXMv ZWdsb3QuZWwKaW5kZXggMzUzODc3ZjYwYzIuLjU5ZDljMzQ2NDI0IDEwMDY0NAotLS0gYS9s aXNwL3Byb2dtb2Rlcy9lZ2xvdC5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9lZ2xvdC5lbApA QCAtMzE0Miw4ICszMTQyLDE4IEBAIGVnbG90LS1kdW1iLWFsbGMKIChkZWZ1biBlZ2xvdC0t ZHVtYi10cnljIChwYXQgdGFibGUgcHJlZCBwb2ludCkKICAgKGxldCAoKHByb2JlIChmdW5j YWxsIHRhYmxlIHBhdCBwcmVkIG5pbCkpKQogICAgIChjb25kICgoZXEgcHJvYmUgdCkgdCkK LSAgICAgICAgICAocHJvYmUgKGNvbnMgcHJvYmUgKGxlbmd0aCBwcm9iZSkpKQotICAgICAg ICAgICh0IChjb25zIHBhdCBwb2ludCkpKSkpCisgICAgICAgICAgKHByb2JlCisgICAgICAg ICAgIChpZiAoYW5kIChub3QgKGVxdWFsIHByb2JlIHBhdCkpCisgICAgICAgICAgICAgICAg ICAgIChjbC1ldmVyeQorICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAocykgKHN0cmlu Zy1wcmVmaXgtcCBwcm9iZSBzIGNvbXBsZXRpb24taWdub3JlLWNhc2UpKQorICAgICAgICAg ICAgICAgICAgICAgKGZ1bmNhbGwgdGFibGUgcGF0IHByZWQgdCkpKQorICAgICAgICAgICAg ICAgKGNvbnMgcHJvYmUgKGxlbmd0aCBwcm9iZSkpCisgICAgICAgICAgICAgKGNvbnMgcGF0 IHBvaW50KSkpCisgICAgICAgICAgKHQKKyAgICAgICAgICAgOzsgTWF0Y2ggaWdub3Jpbmcg c3VmZml4OiBpZiB0aGVyZSBhcmUgYW55IGNvbXBsZXRpb25zIGZvcgorICAgICAgICAgICA7 OyB0aGUgY3VycmVudCBwcmVmaXggYXQgbGVhc3QsIGtlZXAgdGhlIGN1cnJlbnQgaW5wdXQu CisgICAgICAgICAgIChhbmQgKGZ1bmNhbGwgdGFibGUgKHN1YnN0cmluZyBwYXQgMCBwb2lu dCkgcHJlZCB0KQorICAgICAgICAgICAgICAgIChjb25zIHBhdCBwb2ludCkpKSkpKQogCiAo YWRkLXRvLWxpc3QgJ2NvbXBsZXRpb24tY2F0ZWdvcnktZGVmYXVsdHMgJyhlZ2xvdC1jYXBm IChzdHlsZXMgZWdsb3QtLWR1bWItZmxleCkpKQogKGFkZC10by1saXN0ICdjb21wbGV0aW9u LXN0eWxlcy1hbGlzdCAnKGVnbG90LS1kdW1iLWZsZXggZWdsb3QtLWR1bWItdHJ5YyBlZ2xv dC0tZHVtYi1hbGxjKSkKZGlmZiAtLWdpdCBhL3Rlc3QvbGlzcC9wcm9nbW9kZXMvZWdsb3Qt dGVzdHMuZWwgYi90ZXN0L2xpc3AvcHJvZ21vZGVzL2VnbG90LXRlc3RzLmVsCmluZGV4IDUz NGM0N2IyNjQ2Li40Zjc0NWIyNmI0MiAxMDA2NDQKLS0tIGEvdGVzdC9saXNwL3Byb2dtb2Rl cy9lZ2xvdC10ZXN0cy5lbAorKysgYi90ZXN0L2xpc3AvcHJvZ21vZGVzL2VnbG90LXRlc3Rz LmVsCkBAIC02MDAsNiArNjAwLDIwIEBAIGVnbG90LXRlc3QtYmFzaWMtY29tcGxldGlvbnMK ICAgICAgIChtZXNzYWdlIChidWZmZXItc3RyaW5nKSkKICAgICAgIChzaG91bGQgKGxvb2tp bmctYmFjayAiZnByaW50Zi4/IikpKSkpCiAKKyhlcnQtZGVmdGVzdCBlZ2xvdC10ZXN0LWNv bW1vbi1wcmVmaXgtY29tcGxldGlvbiAoKQorICAiVGVzdCBjb21wbGV0aW9uIGFwcGVuZGlu ZyB0aGUgY29tbW9uIHByZWZpeC4iCisgIChza2lwLXVubGVzcyAoZXhlY3V0YWJsZS1maW5k ICJjbGFuZ2QiKSkKKyAgKGVnbG90LS13aXRoLWZpeHR1cmUKKyAgICAgIGAoKCJwcm9qZWN0 IiAuICgoImNvaXNvLmMiIC4KKyAgICAgICAgICAgICAgICAgICAgICAgLChjb25jYXQgImlu dCBmb29fYmFyOyBpbnQgZm9vX2Jhcl9iYXo7IgorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAiaW50IG1haW4oKSB7Zm9vIikpKSkpCisgICAgKHdpdGgtY3VycmVudC1idWZm ZXIKKyAgICAgICAgKGVnbG90LS1maW5kLWZpbGUtbm9zZWxlY3QgInByb2plY3QvY29pc28u YyIpCisgICAgICAoZWdsb3QtLXdhaXQtZm9yLWNsYW5nZCkKKyAgICAgIChnb3RvLWNoYXIg KHBvaW50LW1heCkpCisgICAgICAoY29tcGxldGlvbi1hdC1wb2ludCkKKyAgICAgIChzaG91 bGQgKGxvb2tpbmctYmFjayAie2Zvb19iYXIiKSkpKSkKKwogKGVydC1kZWZ0ZXN0IGVnbG90 LXRlc3Qtbm9uLXVuaXF1ZS1jb21wbGV0aW9ucyAoKQogICAiVGVzdCBjb21wbGV0aW9uIHJl c3VsdGluZyBpbiAnQ29tcGxldGUsIGJ1dCBub3QgdW5pcXVlJy4iCiAgIChza2lwLXVubGVz cyAoZXhlY3V0YWJsZS1maW5kICJjbGFuZ2QiKSkKQEAgLTYxOSw2ICs2MzMsNTUgQEAgZWds b3QtdGVzdC1ub24tdW5pcXVlLWNvbXBsZXRpb25zCiAgICAgICAgIChmb3J3YXJkLWxpbmUg LTEpCiAgICAgICAgIChzaG91bGQgKGxvb2tpbmctYXQgIkNvbXBsZXRlLCBidXQgbm90IHVu aXF1ZSIpKSkpKSkpCiAKKyhlcnQtZGVmdGVzdCBlZ2xvdC10ZXN0LXN0b3AtY29tcGxldGlv bi1vbi1ub25wcmVmaXggKCkKKyAgIlRlc3QgY29tcGxldGlvbiBhbHNvIHJlc3VsdGluZyBp biAnQ29tcGxldGUsIGJ1dCBub3QgdW5pcXVlJy4iCisgIChza2lwLXVubGVzcyAoZXhlY3V0 YWJsZS1maW5kICJjbGFuZ2QiKSkKKyAgKGVnbG90LS13aXRoLWZpeHR1cmUKKyAgICAgIGAo KCJwcm9qZWN0IiAuICgoImNvaXNvLmMiIC4KKyAgICAgICAgICAgICAgICAgICAgICAgLChj b25jYXQgImludCBmb290OyBpbnQgZm9vdGVyOyBpbnQgZm9fb2JhcjsiCisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICJpbnQgbWFpbigpIHtmb28iKSkpKSkKKyAgICAod2l0 aC1jdXJyZW50LWJ1ZmZlcgorICAgICAgICAoZWdsb3QtLWZpbmQtZmlsZS1ub3NlbGVjdCAi cHJvamVjdC9jb2lzby5jIikKKyAgICAgIChlZ2xvdC0td2FpdC1mb3ItY2xhbmdkKQorICAg ICAgKGdvdG8tY2hhciAocG9pbnQtbWF4KSkKKyAgICAgIChjb21wbGV0aW9uLWF0LXBvaW50 KQorICAgICAgKHNob3VsZCAobG9va2luZy1iYWNrICJmb28iKSkpKSkKKworKGVydC1kZWZ0 ZXN0IGVnbG90LXRlc3QtdHJ5LWNvbXBsZXRpb24tbm9tYXRjaCAoKQorICAiVGVzdCBjb21w bGV0aW9uIHRhYmxlIHdpdGggbm9uLW1hdGNoaW5nIGlucHV0LCByZXR1cm5pbmcgbmlsLiIK KyAgKHNraXAtdW5sZXNzIChleGVjdXRhYmxlLWZpbmQgImNsYW5nZCIpKQorICAoZWdsb3Qt LXdpdGgtZml4dHVyZQorICAgICAgYCgoInByb2plY3QiIC4gKCgiY29pc28uYyIgLgorICAg ICAgICAgICAgICAgICAgICAgICAsKGNvbmNhdCAiaW50IG1haW4oKSB7YWJjIikpKSkpCisg ICAgKHdpdGgtY3VycmVudC1idWZmZXIKKyAgICAgICAgKGVnbG90LS1maW5kLWZpbGUtbm9z ZWxlY3QgInByb2plY3QvY29pc28uYyIpCisgICAgICAoZWdsb3QtLXdhaXQtZm9yLWNsYW5n ZCkKKyAgICAgIChnb3RvLWNoYXIgKHBvaW50LW1heCkpCisgICAgICAoc2hvdWxkCisgICAg ICAgKG51bGwKKyAgICAgICAgKGNvbXBsZXRpb24tdHJ5LWNvbXBsZXRpb24KKyAgICAgICAg ICJhYmMiCisgICAgICAgICAobnRoIDIgKGVnbG90LWNvbXBsZXRpb24tYXQtcG9pbnQpKSBu aWwgMykpKSkpKQorCisoZXJ0LWRlZnRlc3QgZWdsb3QtdGVzdC10cnktY29tcGxldGlvbi1p bnNpZGUtc3ltYm9sICgpCisgICJUZXN0IGNvbXBsZXRpb24gdGFibGUgaW5zaWRlIHN5bWJv bCwgd2l0aCBvbmx5IHByZWZpeCBtYXRjaGluZy4iCisgIChza2lwLXVubGVzcyAoZXhlY3V0 YWJsZS1maW5kICJjbGFuZ2QiKSkKKyAgKGVnbG90LS13aXRoLWZpeHR1cmUKKyAgICAgIGAo KCJwcm9qZWN0IiAuICgoImNvaXNvLmMiIC4KKyAgICAgICAgICAgICAgICAgICAgICAgLChj b25jYXQKKyAgICAgICAgICAgICAgICAgICAgICAgICAiaW50IGZvb2JhcjsiCisgICAgICAg ICAgICAgICAgICAgICAgICAgImludCBtYWluKCkge2ZvbzEyMyIpKSkpKQorICAgICh3aXRo LWN1cnJlbnQtYnVmZmVyCisgICAgICAgIChlZ2xvdC0tZmluZC1maWxlLW5vc2VsZWN0ICJw cm9qZWN0L2NvaXNvLmMiKQorICAgICAgKGVnbG90LS13YWl0LWZvci1jbGFuZ2QpCisgICAg ICAoZ290by1jaGFyICgtIChwb2ludC1tYXgpIDMpKQorICAgICAgKHNob3VsZAorICAgICAg IChlcXVhbAorICAgICAgICAnKCJmb28xMjMiIC4gMykKKyAgICAgICAgKGNvbXBsZXRpb24t dHJ5LWNvbXBsZXRpb24KKyAgICAgICAgICJmb28xMjMiCisgICAgICAgICAobnRoIDIgKGVn bG90LWNvbXBsZXRpb24tYXQtcG9pbnQpKSBuaWwgMykpKSkpKQorCiAoZXJ0LWRlZnRlc3Qg ZWdsb3QtdGVzdC1iYXNpYy14cmVmICgpCiAgICJUZXN0IGJhc2ljIHhyZWYgZnVuY3Rpb25h bGl0eSBpbiBhIGNsYW5nZCBMU1AuIgogICAoc2tpcC11bmxlc3MgKGV4ZWN1dGFibGUtZmlu ZCAiY2xhbmdkIikpCg== --------------vDpKdcKfCe8K1U9PZwR4G8Nc-- From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Aug 2024 16:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.17242591694458 (code B ref 72705); Wed, 21 Aug 2024 16:53:01 +0000 Received: (at 72705) by debbugs.gnu.org; 21 Aug 2024 16:52:49 +0000 Received: from localhost ([127.0.0.1]:36210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgoZk-00019p-RT for submit@debbugs.gnu.org; Wed, 21 Aug 2024 12:52:49 -0400 Received: from mail-wm1-f47.google.com ([209.85.128.47]:55496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgoZi-00019Z-Ew for 72705@debbugs.gnu.org; Wed, 21 Aug 2024 12:52:47 -0400 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-428141be2ddso55104325e9.2 for <72705@debbugs.gnu.org>; Wed, 21 Aug 2024 09:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724259055; x=1724863855; darn=debbugs.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=2gGVmpjOvGS5RV6v6kkKckogN299ipEg9nj3UNfF4yo=; b=nUOoCHnuFcoTnQjWJJ48iJUwOARtNON+VO3LYsRPKFLfoTvSR7k561fzJw/3WIQ9fU S6oQSD8tYt2/YgcTKy+GOrPVd1PRqWpr335alJ+D4d8jZ9so7eCDm1nIFoB6TbLaxLPu 14Pfm5Xfqxm4KN1h86curbzTIneNxoQIU2PJYB8g4AIWJXc9lH5pAbPm6ru6PPjJus9e 1zL4uaRbfWdyqw/WUndIENR4jPH2BPLYZvMwlNuS26Y5zceme92sKzH5D1V2vyYvKJnU dYaSZ5T55x0zs8LhmiIq8a6id4pix4saHfELNNSqoxjEFTd7e/ZIb941rCrY4l1+ewVl bFwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724259055; x=1724863855; 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=2gGVmpjOvGS5RV6v6kkKckogN299ipEg9nj3UNfF4yo=; b=nD+AsGXHJH3jaroZ+ed5gXsaWgfBcVMTmG19CsYA+0grB2dpYy3SPh9eg118uvIQc2 JkePogjWbPuEBVzdYHsNkaQFkQdVfY24wcNqszB/VaqXZR2HJBmHBWe2XEKk4v5FJwJf MVvMVP3PfEZCCKTip1BKRhzfVWzydmLdFRRsEfQD4d+eNbTpF340r6kDlsXczYWKsCrp v3blTEW1dRoPvlcEiCa1dMPW5SV/7N8HImJ8SWfw/pNZjnDflBEW+mETE9ABZBD8vIcc w0Z+ScV+NKJgcYy4qCQ72oS1VqvnxjtPWnLKVOr3vo18OWN9fyeqQnqKaLBuVPYjrkvE x3aQ== X-Gm-Message-State: AOJu0YxbSCMpo1IkYex7L471oKNvhICjPgFxMH31mquaQ7mCiDea6i1l G7D2kKL7cTbe6iQwhX7oDoP4n8cfoXK+c3UK1h4vbeqEFbo3zXpREjmnCQ== X-Google-Smtp-Source: AGHT+IFZbz7JZZur1QAiA5XeYmaDzIuKTNB3SaxAn0/2VrDVUT7V0LLlXPJryGZ6qn27rfE/nniCRA== X-Received: by 2002:a5d:43c7:0:b0:368:4c38:a669 with SMTP id ffacd0b85a97d-372fd5a85d2mr1629920f8f.10.1724259054842; Wed, 21 Aug 2024 09:50:54 -0700 (PDT) Received: from krug (87-196-102-145.net.novis.pt. [87.196.102.145]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3718984948csm16222076f8f.29.2024.08.21.09.50.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Aug 2024 09:50:54 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= In-Reply-To: <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> (Dmitry Gutov's message of "Wed, 21 Aug 2024 03:30:18 +0300") References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> Date: Wed, 21 Aug 2024 17:52:19 +0100 Message-ID: <87ed6hyg1o.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 20/08/2024 12:40, Jo=C3=A3o T=C3=A1vora wrote: >> On Tue, Aug 20, 2024 at 3:08=E2=80=AFAM Dmitry Gutov = wrote: >>=20 >>> So far I've tested with gopls and clangd (when writing the new tests), >>> typescript-language-server and rust-analyzer. >> That's pretty good. If you could add pylsp or pyright >> (basedpyright), >> I'd feel even more confident. > > Installed pylsp with apt - the basic things I tested seem to work too. Great. >> I don't have time to spend examining these details, just the final >> outcome is relevant: partial completions cannot be inserted, but >> fragments of a completion can be completed to a fully formed >> completion (eventually running exit-function then). > > And only fragments that prefix-match all completions as > prefix. exit-function seems to function. Also good. > In relation to the current state, but I think I've figured it out - > see the new revision attached. Great. > See the new test 'eglot-test-try-completion-inside-symbol' inside the > patch. Wasn't sure whether to make it use 'completion-try-completion' > or 'completion-at-point', but the former seems more explicit. This all looks very good, especially the abundant tests. You may push right now if you want. I'll just comment on those: +(ert-deftest eglot-test-common-prefix-completion () + "Test completion appending the common prefix." + (skip-unless (executable-find "clangd")) + (eglot--with-fixture + `(("project" . (("coiso.c" . Eh. You may replace "coiso.c" for the Russian equivalent of "thingy.c" if you want :-). Or something more imaginative. + ,(concat "int foo_bar; int foo_bar_baz;" + "int main() {foo"))))) + (with-current-buffer + (eglot--find-file-noselect "project/coiso.c") + (eglot--wait-for-clangd) + (goto-char (point-max)) + (completion-at-point) + (should (looking-back "{foo_bar"))))) Here, we completed to foo_bar and it's a fully formed completion. I understand you've checked that exit-function does run. This is good. Unfortunately, if the the two ints were named "foo_bar_1" and "foo_bar_2" it would also complete to foo_bar_, which is wrong in the general case, since that text is not a fully formed completion. exit-function cannot run here. It happens to "work" here because clangd supplies the "insertText" as well as the "textEdit" property and that "insertText" isn't meaningless. The LSP spec recommendation is for servers to prefer supplying textEdit. * The `insertText` is subject to interpretation by the client side. * Some tools might not take the string literally. For example * VS Code when code complete is requested in this example * `con` and a completion item with an `insertText` of * `console` is provided it will only insert `sole`. Therefore it is * recommended to use `textEdit` instead since it avoids additional clie= nt * side interpretation. Anyway this is _not_ a regression in your patch: the current state also does this mistake. Though, I wonder if you could fix it as well (in a follow-up commit, maybe). +(ert-deftest eglot-test-stop-completion-on-nonprefix () + "Test completion also resulting in 'Complete, but not unique'." + (skip-unless (executable-find "clangd")) + (eglot--with-fixture + `(("project" . (("coiso.c" . + ,(concat "int foot; int footer; int fo_obar;" + "int main() {foo"))))) + (with-current-buffer + (eglot--find-file-noselect "project/coiso.c") + (eglot--wait-for-clangd) + (goto-char (point-max)) + (completion-at-point) + (should (looking-back "foo"))))) Here, we're looking-back to "foo" here because _no_ completion took place. This means a *Completions* buffer has appeared and is now offering foot and footer. The current state does not do this, and chooses one of the two completions indiscrimately. This is, I think, the original bug you reported here. So this is clearly a win. To underline it and defend against regresison, I suggest to also assert that the *Completions* buffer popped up. Though, maybe not going so far as asserting the there are exactly those two completions in that order -- doing it "graphically" might prove too brittle. +(ert-deftest eglot-test-try-completion-inside-symbol () + "Test completion table inside symbol, with only prefix matching." + (skip-unless (executable-find "clangd")) + (eglot--with-fixture + `(("project" . (("coiso.c" . + ,(concat + "int foobar;" + "int main() {foo123"))))) + (with-current-buffer + (eglot--find-file-noselect "project/coiso.c") + (eglot--wait-for-clangd) + (goto-char (- (point-max) 3)) + (should + (equal + '("foo123" . 3) + (completion-try-completion + "foo123" + (nth 2 (eglot-completion-at-point)) nil 3)))))) I don't understand the point of this last test. Are you checking that nothing changes? What are you guarding against? Finally, an interesting test could be the rust-analyzer one from the issue 1339 issue, which starts with. fn main() { let v: usize =3D 1; 1234.1234567890 } I've manually checked that neither the v.c1234.12345676890 nor the v.count_on1234.1234567890 case has regressed. The tests for rust-analyzer require a bit more boilerplate (they require a "cargo" call to setup a temporary project), but other than that it's mostly the same. They won't run on Hydra (no rust-analyzer there)), but I do run them on occasion. Jo=C3=A3o From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Aug 2024 00:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.172428737621779 (code B ref 72705); Thu, 22 Aug 2024 00:43:01 +0000 Received: (at 72705) by debbugs.gnu.org; 22 Aug 2024 00:42:56 +0000 Received: from localhost ([127.0.0.1]:36465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgvui-0005fC-12 for submit@debbugs.gnu.org; Wed, 21 Aug 2024 20:42:56 -0400 Received: from fhigh5-smtp.messagingengine.com ([103.168.172.156]:37585) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgvue-0005es-7I for 72705@debbugs.gnu.org; Wed, 21 Aug 2024 20:42:54 -0400 Received: from phl-compute-06.internal (phl-compute-06.nyi.internal [10.202.2.46]) by mailfhigh.nyi.internal (Postfix) with ESMTP id B5C11114E9FC; Wed, 21 Aug 2024 20:42:00 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Wed, 21 Aug 2024 20:42:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1724287320; x=1724373720; bh=QK/2Rsw2wmcLY4dzOyXaBbzSyQD6CgBwsgLDPGJo4Bw=; b= RS/ACSS2Vd621fOSq0c+DiD1Ib5r1hQiXNaHQDP8o6WmJ/iwPEn22ilvUTIqY3G9 SkWkDtwTmkjszx420MKXRVr7KgC7NMqxesHuRjUuUi/YMCP6KCU0cCzAOY/6bcSB IoFM1Lw/ekJIKlbAMcG88yj0poQAd7iXJWVTHYaMCPvJCbzqFJR1oO3H1U6HxgpO 2bXrusCf3gEvvrEqEUSgeUId8FN9bHmdPGjQ+GH6RIz8x99Mu2f1B2ii6W80QPyD pD9mzduh+i65Us23LLv4cT8tP0iGgOOUuI6RYLi+t0hxPCK+rbtnFkIisobonWz5 UriAfMoEN6Kvv+vlX3Tolw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1724287320; x= 1724373720; bh=QK/2Rsw2wmcLY4dzOyXaBbzSyQD6CgBwsgLDPGJo4Bw=; b=h IFWMc8NAsJQTvlXxqkA0ENxuNKDavTSGPttrgi3qErFM1wsTRt+qZKCjsIF5VQ4J phxxgv7oC1zA6KP92tAIgon2AVnwXstVpspScR6C8SKndAdB0aHqgiWq4BjT0obw Q/b4ANwtM2+kTX7szSSruip5NAovmAfDzWHiUPF8NtGFXC8kLrrWvhR8Fb5dzOjE FFO0FcL/o2rG3l88UbaDWze+Kd+AqENV0ADHifBw2/pFPHOB//CA4nFA6ZZmQ0ql TkhLWTjOFRqn9dd7u9NzF2qPB4Y2SblObM/CqbIJ1VLPfnnN0/wIclJH445zQwar jJE/qZlCl4wIVlzgD2Bhw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudduledgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveeg tedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho pedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjohgrohhtrghvohhrrgesgh hmrghilhdrtghomhdprhgtphhtthhopeejvdejtdehseguvggssghughhsrdhgnhhurdho rhhg X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 21 Aug 2024 20:41:59 -0400 (EDT) Message-ID: <06cfce49-33ff-41a2-b999-469c4a0009c0@gutov.dev> Date: Thu, 22 Aug 2024 03:41:57 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> <87ed6hyg1o.fsf@gmail.com> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <87ed6hyg1o.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 21/08/2024 19:52, João Távora wrote: >> See the new test 'eglot-test-try-completion-inside-symbol' inside the >> patch. Wasn't sure whether to make it use 'completion-try-completion' >> or 'completion-at-point', but the former seems more explicit. > > This all looks very good, especially the abundant tests. You may push > right now if you want. Thanks! The next question I should ask, though, is can we get it into Emacs 30? Like with the previous discussions about Eglot in Emacs 29, I think there will be a lot of users who just use the version of it that comes with the release, without upgrading. > I'll just comment on those: > > +(ert-deftest eglot-test-common-prefix-completion () > + "Test completion appending the common prefix." > + (skip-unless (executable-find "clangd")) > + (eglot--with-fixture > + `(("project" . (("coiso.c" . > > Eh. You may replace "coiso.c" for the Russian equivalent of "thingy.c" > if you want :-). Or something more imaginative. schtuka? The Portuguese version sounds pretty good to my ear. I'd try the Greek variant, but "pragma" already has a different meaning in C langs. > + ,(concat "int foo_bar; int foo_bar_baz;" > + "int main() {foo"))))) > + (with-current-buffer > + (eglot--find-file-noselect "project/coiso.c") > + (eglot--wait-for-clangd) > + (goto-char (point-max)) > + (completion-at-point) > + (should (looking-back "{foo_bar"))))) > > Here, we completed to foo_bar and it's a fully formed completion. I > understand you've checked that exit-function does run. This is good. I did check, though not in any of the included tests. > Unfortunately, if the the two ints were named "foo_bar_1" and > "foo_bar_2" it would also complete to foo_bar_, which is wrong in the > general case, since that text is not a fully formed completion. > exit-function cannot run here. Is it really a problem? In my testing completing to foo_bar_ usually is a good thing (you have fewer chars left to type), even though nothing else happens. To try a different example, if I have C functions foo_bar_1 and foo_bar_2, with Clang input 'foo_' does get completed to 'foo_bar_', without exit-function running. But to get it called, I only need to additionally type '1' and press C-M-i again. Or, if Company is used, completing to 'foo_bar_' keeps the popup active, so I just press RET to pick the first completion. > It happens to "work" here because clangd supplies the "insertText" as > well as the "textEdit" property and that "insertText" isn't meaningless. > The LSP spec recommendation is for servers to prefer supplying textEdit. > > * The `insertText` is subject to interpretation by the client side. > * Some tools might not take the string literally. For example > * VS Code when code complete is requested in this example > * `con` and a completion item with an `insertText` of > * `console` is provided it will only insert `sole`. Therefore it is > * recommended to use `textEdit` instead since it avoids additional client > * side interpretation. > > Anyway this is _not_ a regression in your patch: the current state also > does this mistake. Though, I wonder if you could fix it as well (in a > follow-up commit, maybe). It seems to me that performing *some* completion is better than always returning the original input, isn't it? Do you have an example of a language server and a scenario where this becomes a problem? > +(ert-deftest eglot-test-stop-completion-on-nonprefix () > + "Test completion also resulting in 'Complete, but not unique'." > + (skip-unless (executable-find "clangd")) > + (eglot--with-fixture > + `(("project" . (("coiso.c" . > + ,(concat "int foot; int footer; int fo_obar;" > + "int main() {foo"))))) > + (with-current-buffer > + (eglot--find-file-noselect "project/coiso.c") > + (eglot--wait-for-clangd) > + (goto-char (point-max)) > + (completion-at-point) > + (should (looking-back "foo"))))) > > Here, we're looking-back to "foo" here because _no_ completion took > place. This means a *Completions* buffer has appeared and is now > offering foot and footer. Right. > The current state does not do this, and chooses one of the two > completions indiscrimately. This is, I think, the original bug you > reported here. So this is clearly a win. To underline it and defend > against regresison, I suggest to also assert that the *Completions* > buffer popped up. Sure. > Though, maybe not going so far as asserting the there > are exactly those two completions in that order -- doing it > "graphically" might prove too brittle. An alternative might be to use a completion-all-completions call, to assert the full list of completions. Or some completions that are in it anyway. > +(ert-deftest eglot-test-try-completion-inside-symbol () > + "Test completion table inside symbol, with only prefix matching." > + (skip-unless (executable-find "clangd")) > + (eglot--with-fixture > + `(("project" . (("coiso.c" . > + ,(concat > + "int foobar;" > + "int main() {foo123"))))) > + (with-current-buffer > + (eglot--find-file-noselect "project/coiso.c") > + (eglot--wait-for-clangd) > + (goto-char (- (point-max) 3)) > + (should > + (equal > + '("foo123" . 3) > + (completion-try-completion > + "foo123" > + (nth 2 (eglot-completion-at-point)) nil 3)))))) > > I don't understand the point of this last test. Are you checking that > nothing changes? What are you guarding against? With the input, I'm describing the actual prefix and suffix that get used. It might help someone who comes later to understand this separate case. Indeed "nothing happens", it's just that something did happen with the previous version of my patch, and we're testing against that. Might be more interesting to have a similar example where the prefix changes while the (non-emtpy) suffix stays the same, but I think we aren't going to support this in this c-style. > Finally, an interesting test could be the rust-analyzer one from the > issue 1339 issue, which starts with. > > fn main() { > let v: usize = 1; > 1234.1234567890 > } > > I've manually checked that neither the v.c1234.12345676890 nor the > v.count_on1234.1234567890 case has regressed. Yep, that's the one I fixed in the last revision. It's the same case as '("foo123" . 3) in the test above, isn't it? > The tests for rust-analyzer require a bit more boilerplate (they require > a "cargo" call to setup a temporary project), but other than that it's > mostly the same. They won't run on Hydra (no rust-analyzer there)), but > I do run them on occasion. Was a bit non-trivial to get it running indeed. From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Aug 2024 17:00:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.1724345974388 (code B ref 72705); Thu, 22 Aug 2024 17:00:01 +0000 Received: (at 72705) by debbugs.gnu.org; 22 Aug 2024 16:59:34 +0000 Received: from localhost ([127.0.0.1]:38272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shB9p-00006B-DX for submit@debbugs.gnu.org; Thu, 22 Aug 2024 12:59:33 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:48504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shB9m-00005t-3V for 72705@debbugs.gnu.org; Thu, 22 Aug 2024 12:59:32 -0400 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-37193ef72a4so592996f8f.1 for <72705@debbugs.gnu.org>; Thu, 22 Aug 2024 09:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724345858; x=1724950658; darn=debbugs.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=+r2X5KsYJdKQufFSycBGWmsDI9deB0ZOGfeM/Ss1lmk=; b=GdQHrBYxzTClm+Hs7q5ukR2uF/NA0uPGhLyV6yHJws2qVrjrCSbhrIrCuAamedXMp/ a3flrlpwcxrLk5FdICWMGLANO2E1ORFtmtiUbfiVA9wO1e127G2XJG5UHnLcvPK2XTxb hjNlE9xG4uiZCYzls96PwWwLBPaSctshWkxwiUDDAItCplpbC+w4KONZoQE4J95i5z+v y5hrv/ox1M/tMmwR9llKBYTmhzrqIEyUr54aY+jqVEzD5/ki+EWQ/hqKye/CLjLE3BrT e8TCtZqkbNs9OLWwRSVwle1bmbflOe5cFLwjijRREdzVSM4FWV3U9OmeQ++7zbZbOpEn V5bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724345858; x=1724950658; 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=+r2X5KsYJdKQufFSycBGWmsDI9deB0ZOGfeM/Ss1lmk=; b=HMMrPsGvo7+eYgoVi1gpMRCd9AMJ1T/vezl8CQCq3SBaXwiS4HaHMqgmDA+Y6b0uC/ ECeHem7SvEkFjSPkiuTDqkgbsOkRglzP13daEf/QYxDT4CI2syJvPpIvuiEhxoXYLvNP lltuclVZP3VYxmsBCJSpUO2G+o6wZEeTLlGsYsRvej6tFce5eEF9OcAKgLm/w3Z8Ebff 2wtden0K9AqQL+AzsMMYwHP7hU6dhp0A92dZ4LPClckMlpiUP2VzghdVqX6HB7NbWi+t k40t7A1nY/FJY2RXAu9stsATePBscFojCEM6o4np3Z3m+q5Mr/HwuZH8GdrYfksubk3f 5sSA== X-Gm-Message-State: AOJu0YylllYb0fhqzADPSahwpERsHDwaVhVamQWeO6vbCFO9dS7ie5uw UVTuyVmFWpGyi7+VZ3LN0LxL+YsCUjjcLMiHB3vJLD2Y7s9bt/fNuD+tbA== X-Google-Smtp-Source: AGHT+IFqZEZNlCMtN+PWxQcptTuTgoxqYKaB15Vka/476t2LZxJOe1ZvKcABrYfGdq3glTWHaXXa5Q== X-Received: by 2002:a05:6000:4388:b0:373:b44:675 with SMTP id ffacd0b85a97d-3730b440ab5mr1401610f8f.20.1724345857414; Thu, 22 Aug 2024 09:57:37 -0700 (PDT) Received: from krug (87-196-102-145.net.novis.pt. [87.196.102.145]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42ab6e7d718sm62200665e9.0.2024.08.22.09.57.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2024 09:57:36 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= In-Reply-To: <06cfce49-33ff-41a2-b999-469c4a0009c0@gutov.dev> (Dmitry Gutov's message of "Thu, 22 Aug 2024 03:41:57 +0300") References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> <87ed6hyg1o.fsf@gmail.com> <06cfce49-33ff-41a2-b999-469c4a0009c0@gutov.dev> Date: Thu, 22 Aug 2024 17:59:01 +0100 Message-ID: <87o75kwl2i.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > Like with the previous discussions about Eglot in Emacs 29, I think > there will be a lot of users who just use the version of it that comes > with the release, without upgrading. Hopefully upgrading should be a matter of M-x eglot-upgrade-eglot. But no problem on my side. In a separate "don't merge" commit, look into editing the etc/EGLOT-NEWS there which I've already bumped to 1.17.30 (the version of Eglot to be bundled with Emacs 30). I'll then copy that text to master eventually and release 1.17 to GNU Elpa. >> Unfortunately, if the the two ints were named "foo_bar_1" and >> "foo_bar_2" it would also complete to foo_bar_, which is wrong in the >> general case, since that text is not a fully formed completion. >> exit-function cannot run here. > > Is it really a problem? Yes. Start 'clangd --completion-style=3Ddetailed' in this thingy.cpp C++ file: int foobar(int x, char c) { return x + c; } =20=20=20=20 int foobar(int x, float f) { return x + f; } =20=20=20=20 int main() { foob } if you press C-M-i here this will expand to the partial 'foobar(int x, ' which doesn't make C/C++ syntactic sense in that context. Emacs is just inserting the LSP "label", which as the name implies, is just for displaying, not for inserting. The goal of these two completions is to expand a snippet and the snippet can only be expanded through the exit function. Even if we complexified Eglot's capf to insert the 'insertText' instead of the 'label' (assuming it existed), we'd be inserting a partial snippet skeleton, even more nonsensical in C/C++. > completing to 'foo_bar_' keeps the popup active, so I just press RET > to pick the first completion. With the above 'foobar(int x, ' example and with bare C-M-i it's even worse: it's hard (if not impossible) to complete to the full completion and thus get the desired snippet expansion because the common prefix of both completion labels ends with a space. > It seems to me that performing *some* completion is better than always > returning the original input, isn't it? No, not always. LSP just wasn't thought with the "partial completion" scenario in mind. > Do you have an example of a language server and a scenario where this > becomes a problem? The above. >> The current state does not do this, and chooses one of the two >> completions indiscrimately. This is, I think, the original bug you >> reported here. So this is clearly a win. To underline it and defend >> against regresison, I suggest to also assert that the *Completions* >> buffer popped up. > > Sure. Great. >> Though, maybe not going so far as asserting the there >> are exactly those two completions in that order -- doing it >> "graphically" might prove too brittle. > > An alternative might be to use a completion-all-completions call, to > assert the full list of completions. Or some completions that are in > it anyway. Yes, I generally prefer "end-to-end" tests using interactive interfaces. So unless you're duplicating the test I think this part should be skipped. But your call. >> +(ert-deftest eglot-test-try-completion-inside-symbol () >> + "Test completion table inside symbol, with only prefix matching." >> + (skip-unless (executable-find "clangd")) >> + (eglot--with-fixture >> + `(("project" . (("coiso.c" . >> + ,(concat >> + "int foobar;" >> + "int main() {foo123"))))) >> + (with-current-buffer >> + (eglot--find-file-noselect "project/coiso.c") >> + (eglot--wait-for-clangd) >> + (goto-char (- (point-max) 3)) >> + (should >> + (equal >> + '("foo123" . 3) >> + (completion-try-completion >> + "foo123" >> + (nth 2 (eglot-completion-at-point)) nil 3)))))) >> I don't understand the point of this last test. Are you checking >> that >> nothing changes? What are you guarding against? > > With the input, I'm describing the actual prefix and suffix that get > used. It might help someone who comes later to understand this > separate case. Indeed "nothing happens", it's just that something did > happen with the previous version of my patch, and we're testing > against that. Fine. So maybe be a little bit more explicit in the comment or docstring about what you _don't_ want to happen. AFAIU, you don't want 'foobar123' or 'foobar' to be the result of that completion. > Might be more interesting to have a similar example where the prefix > changes while the (non-emtpy) suffix stays the same, but I think we > aren't going to support this in this c-style. > >> Finally, an interesting test could be the rust-analyzer one from the >> issue 1339 issue, which starts with. >> fn main() { >> let v: usize =3D 1; >> 1234.1234567890 >> } >> I've manually checked that neither the v.c1234.12345676890 nor the >> v.count_on1234.1234567890 case has regressed. > > Yep, that's the one I fixed in the last revision. > > It's the same case as '("foo123" . 3) in the test above, isn't it? I don't think so. In a rust-analyzer hello world (which you can make with cargo init, if I'm not mistaken), both v.c1234.12345676890 v.count_on1234.12345676890 should expand to v.count_ones().1234567890 In the first case, you'll have to manually select "count_ones" from the completions buffer. The expansion and removal of the 1234 happens via LSP text edits, which are enacte by the :exit-function. This scenario wasn't working a while ago and I'd like to protect it against regression. Jo=C3=A3o From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Aug 2024 23:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.17243686327766 (code B ref 72705); Thu, 22 Aug 2024 23:18:02 +0000 Received: (at 72705) by debbugs.gnu.org; 22 Aug 2024 23:17:12 +0000 Received: from localhost ([127.0.0.1]:38545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shH3I-00021B-4y for submit@debbugs.gnu.org; Thu, 22 Aug 2024 19:17:12 -0400 Received: from fout1-smtp.messagingengine.com ([103.168.172.144]:44529) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shH3F-00020w-Rp for 72705@debbugs.gnu.org; Thu, 22 Aug 2024 19:17:10 -0400 Received: from phl-compute-01.internal (phl-compute-01.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id 40AC61390182; Thu, 22 Aug 2024 19:16:18 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Thu, 22 Aug 2024 19:16:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1724368578; x=1724454978; bh=IgDgFQRrBhtPA2ghvDbE8kyf72sCdwBGjjEhD5TuWZQ=; b= i+tAiUHHmj2KPHu93RfZqiiEKurpcHT8GuDHY9ii6/10mnBuwQqhnrhQNs37QgWQ /Y/rSvZTCWPZ8/YboS2y5JDSHuYzDMbHF2kqg6qiYdFKz1syO2L0OeZm9ynqo1Tm Z8/RaII4/YUngpxa9oL8EqiqogSF8v9QRCZIF3h0oK18Zi9M4SsCCz22R4T4yHi5 2xBeVUQnzGKzv4izbgbl4di9USCr5HxQOWyxR7G2hum533Wx/FG9oyQCjyXxTTG+ SHY9V7JmR+IEXFgRgRn+LDylMdpUWx1nIlrkFyqwx0RM+KLt9gzFfVxNq3elfpDR TnmoeRIs+L9bLtq84Qvbrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1724368578; x= 1724454978; bh=IgDgFQRrBhtPA2ghvDbE8kyf72sCdwBGjjEhD5TuWZQ=; b=S RmwqZVHXYF4s7soA5pQF9wxYuIkAXiqqVgvcclaYl+dKycARQN+RzPL/88KQNgj/ he8D60OeuoX80yJ538dny+I1/SrayEhUkgHEI3nas/UZ15zWeFcjAfLZc2f8gfhK zD110xdAJ3x9rLnCp7WxYDdsMve3b8Rxk2VtSyJzZAVWk+QSY7gNilQtEAFsQntQ jrkFF2W/xVAtyGujutDDATsUgnsJdMkO7xwd3Bg9MZXm9AVT+CuA1r5Aoibzej8L t8WIu8429Zigz4mAcwUmyfAqvSlhS8j0kbnZVGdukaSLQ3X0GV8WSqo4Z6a8t2KX TPockopKwAnV065NGmrQA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddvuddgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepfedvjeeviefffeeukeelveeikeegtddtveeileev gfdvgffhtdfggeeffeegiefgnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhies ghhuthhovhdruggvvhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepjhhorghothgrvhhorhgrsehgmhgrihhlrdgtohhmpdhrtghpthhtohep jedvjedtheesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 Aug 2024 19:16:17 -0400 (EDT) Message-ID: Date: Fri, 23 Aug 2024 02:16:14 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> <87ed6hyg1o.fsf@gmail.com> <06cfce49-33ff-41a2-b999-469c4a0009c0@gutov.dev> <87o75kwl2i.fsf@gmail.com> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <87o75kwl2i.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 22/08/2024 19:59, João Távora wrote: > Dmitry Gutov writes: > >> Like with the previous discussions about Eglot in Emacs 29, I think >> there will be a lot of users who just use the version of it that comes >> with the release, without upgrading. > > Hopefully upgrading should be a matter of M-x eglot-upgrade-eglot. > > But no problem on my side. In a separate "don't merge" commit, look > into editing the etc/EGLOT-NEWS there which I've already bumped to > 1.17.30 (the version of Eglot to be bundled with Emacs 30). I'll then > copy that text to master eventually and release 1.17 to GNU Elpa. Great! Bump it to 1.17.60? >>> Unfortunately, if the the two ints were named "foo_bar_1" and >>> "foo_bar_2" it would also complete to foo_bar_, which is wrong in the >>> general case, since that text is not a fully formed completion. >>> exit-function cannot run here. >> >> Is it really a problem? > > Yes. Start 'clangd --completion-style=detailed' in this thingy.cpp C++ > file: > > int foobar(int x, char c) { > return x + c; > } > > int foobar(int x, float f) { > return x + f; > } > > int main() { > foob > } > > if you press C-M-i here this will expand to the partial 'foobar(int x, ' > which doesn't make C/C++ syntactic sense in that context. Emacs is just > inserting the LSP "label", which as the name implies, is just for > displaying, not for inserting. The goal of these two completions is to > expand a snippet and the snippet can only be expanded through the exit > function. Even if we complexified Eglot's capf to insert the > 'insertText' instead of the 'label' (assuming it existed), we'd be > inserting a partial snippet skeleton, even more nonsensical in C/C++. Thanks, now I remember: it's https://github.com/company-mode/company-mode/issues/1412. The current proposal doesn't fix it, though it probably makes things a bit better (simply because the "common" string is on average computed to be shorter). A somewhat complete solution would probably include per-language "stop character" map - where we could check the `probe' for chars such as "(" (or whatever the language uses) and shorten the return value accordingly if found. It would replace the currently added "string-prefix-p" check, I guess. >> completing to 'foo_bar_' keeps the popup active, so I just press RET >> to pick the first completion. > > With the above 'foobar(int x, ' example and with bare C-M-i it's even > worse: it's hard (if not impossible) to complete to the full completion > and thus get the desired snippet expansion because the common prefix of > both completion labels ends with a space. Yeah, it'd be great to have C-M-i stop before the paren. >> An alternative might be to use a completion-all-completions call, to >> assert the full list of completions. Or some completions that are in >> it anyway. > > Yes, I generally prefer "end-to-end" tests using interactive interfaces. > So unless you're duplicating the test I think this part should be > skipped. But your call. It's a different test (albeit with the same result as an existing one). I don't mind rewriting it in a different style, if you prefer. The result is kind of messy either way. >>> +(ert-deftest eglot-test-try-completion-inside-symbol () >>> + "Test completion table inside symbol, with only prefix matching." >>> + (skip-unless (executable-find "clangd")) >>> + (eglot--with-fixture >>> + `(("project" . (("coiso.c" . >>> + ,(concat >>> + "int foobar;" >>> + "int main() {foo123"))))) >>> + (with-current-buffer >>> + (eglot--find-file-noselect "project/coiso.c") >>> + (eglot--wait-for-clangd) >>> + (goto-char (- (point-max) 3)) >>> + (should >>> + (equal >>> + '("foo123" . 3) >>> + (completion-try-completion >>> + "foo123" >>> + (nth 2 (eglot-completion-at-point)) nil 3)))))) >>> I don't understand the point of this last test. Are you checking >>> that >>> nothing changes? What are you guarding against? >> >> With the input, I'm describing the actual prefix and suffix that get >> used. It might help someone who comes later to understand this >> separate case. Indeed "nothing happens", it's just that something did >> happen with the previous version of my patch, and we're testing >> against that. > > Fine. So maybe be a little bit more explicit in the comment or > docstring about what you _don't_ want to happen. AFAIU, you don't want > 'foobar123' or 'foobar' to be the result of that completion. Right! >> Might be more interesting to have a similar example where the prefix >> changes while the (non-emtpy) suffix stays the same, but I think we >> aren't going to support this in this c-style. >> >>> Finally, an interesting test could be the rust-analyzer one from the >>> issue 1339 issue, which starts with. >>> fn main() { >>> let v: usize = 1; >>> 1234.1234567890 >>> } >>> I've manually checked that neither the v.c1234.12345676890 nor the >>> v.count_on1234.1234567890 case has regressed. >> >> Yep, that's the one I fixed in the last revision. >> >> It's the same case as '("foo123" . 3) in the test above, isn't it? > > I don't think so. In a rust-analyzer hello world (which you can make > with cargo init, if I'm not mistaken), both > > v.c1234.12345676890 > v.count_on1234.12345676890 > > should expand to > > v.count_ones().1234567890 > > In the first case, you'll have to manually select "count_ones" from the > completions buffer. The expansion and removal of the 1234 happens via > LSP text edits, which are enacte by the :exit-function. Okay, I am seeing a difference too: C-M-i does eat the suffix in the Rust example (the "1234"). But completion with Company does not :-/ I guess the difference might come from C-M-i always going through try-completion, whereas the Company popup relies on all-completions. There's a similar difference when using gopls. But Clangd actually looks special (just filed separate bug#72765). > This scenario > wasn't working a while ago and I'd like to protect it against > regression. Would we have a test that launches rust-analyzer (and depends on it being installed, and a Cargo project initialized)? From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Aug 2024 10:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.172440866412472 (code B ref 72705); Fri, 23 Aug 2024 10:25:01 +0000 Received: (at 72705) by debbugs.gnu.org; 23 Aug 2024 10:24:24 +0000 Received: from localhost ([127.0.0.1]:39048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shRSx-0003F5-2W for submit@debbugs.gnu.org; Fri, 23 Aug 2024 06:24:23 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:42247) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shRSt-0003Em-Dn for 72705@debbugs.gnu.org; Fri, 23 Aug 2024 06:24:21 -0400 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-37182eee02dso960059f8f.1 for <72705@debbugs.gnu.org>; Fri, 23 Aug 2024 03:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724408546; x=1725013346; darn=debbugs.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=IjAENOtGO21tnrzHFw6nxI0GpBXtfr1fwdxfbwnUJEg=; b=QrWwAQ+Tcg3tDHrUbqkdTbPSL2NSL8LEPi9bciK7z7Rn9J/IR/N2+rEt0/xtaVsGC/ bJDKNvB+ZOonTMilr5l+rZBpJ6CbiA52Nc3dw3Z4hhDb0dopkDpPIPHT+ofdIXq8kUx5 ohi+BZ+hMOsrBadcJWTSObuz82JSF4QWNwkZg6vYXdkoKN7GhtPodEz1bRglsmEoDJWP fpHoigRPstYUDdXFfoIUYvIucV6LqTwRTSVhx9+qEymzDZhyzWldXwCYsx3VgvMgGCB9 uHZJXYxfR5j72cTFGzk5yzH0LSbtfHY3ifBKZhrPUoMyxN0lUuMMi4JVaN0VIIx0PxF7 607g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724408546; x=1725013346; 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=IjAENOtGO21tnrzHFw6nxI0GpBXtfr1fwdxfbwnUJEg=; b=RacoxswExNeGSgyDRinh2OOQiXWSm4pSRGdGz3yS/W2LogGo5bYANhM9tv/OPnkFG+ 2cYSYmleqLlaodA9TrBkhaWT1HX1iu0bvTmEllEhRV60HLbAiMgMJGH93FMUHXRZeY0g xAkiC6xVenEgnWbe0Q/VD13tNHhYVJrUrLBe19wS9qPfuzf9YqaF25hUjz+pAqsbje+L PIV5FawfP0ZoBWMP/gcxOrxSkksYdBp1Ubhc99xxCmPIsXkOfEW7fA7s5jIPcvNENFiy PzNOBHhYll8q46Qidn6WZ+wVOi6/6Zsg7C2RrUonzCse1SRppL7qIYtv4KjxwukLqhAB z5QQ== X-Gm-Message-State: AOJu0YxFe2y8lSB9sxpOtoWtu2ujbDc3qdMTQ1zmDummG9i1nKjpX3FC gTV66LKNJy1suN2FzzS2c7nSw8onxn76YyhOJRdtYg4cYxOTKlTC1PdCkw== X-Google-Smtp-Source: AGHT+IEnEcuAI+EIyahT1PPziB9M7AO5Umu2Cau3vc2hMiZRiEur2yoWPOlRl1OPeXBcTlGiImIthw== X-Received: by 2002:a5d:5547:0:b0:363:ac4d:c44f with SMTP id ffacd0b85a97d-37310ebfa3bmr1073000f8f.17.1724408545805; Fri, 23 Aug 2024 03:22:25 -0700 (PDT) Received: from krug (87-196-102-145.net.novis.pt. [87.196.102.145]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3730817a076sm3802182f8f.60.2024.08.23.03.22.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Aug 2024 03:22:25 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= In-Reply-To: (Dmitry Gutov's message of "Fri, 23 Aug 2024 02:16:14 +0300") References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> <87ed6hyg1o.fsf@gmail.com> <06cfce49-33ff-41a2-b999-469c4a0009c0@gutov.dev> <87o75kwl2i.fsf@gmail.com> Date: Fri, 23 Aug 2024 11:23:50 +0100 Message-ID: <87h6bbwn9l.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 22/08/2024 19:59, Jo=C3=A3o T=C3=A1vora wrote: >> Dmitry Gutov writes: >>=20 >>> Like with the previous discussions about Eglot in Emacs 29, I think >>> there will be a lot of users who just use the version of it that comes >>> with the release, without upgrading. >> Hopefully upgrading should be a matter of M-x eglot-upgrade-eglot. >> But no problem on my side. In a separate "don't merge" commit, look >> into editing the etc/EGLOT-NEWS there which I've already bumped to >> 1.17.30 (the version of Eglot to be bundled with Emacs 30). I'll then >> copy that text to master eventually and release 1.17 to GNU Elpa. > > Great! Bump it to 1.17.60? No, keep it at 1.17.30. That's the 1.17-ish version of Eglot that will ship with Emacs 30, just as 1.12.29 is the 1.12-ish version of Eglot that shipped with Emacs 29. The change you're proposing will eventually also be merged to master and be part of the 1.18 GNU Elpa release (earlier I wrote 1.17 GNU Elpa by mistake). > The current proposal doesn't fix it, though it probably makes things a > bit better (simply because the "common" string is on average computed > to be shorter). A somewhat complete solution would probably include > per-language "stop character" map - where we could check the `probe' > for chars such as "(" (or whatever the language uses) and shorten the > return value accordingly if found. > > It would replace the currently added "string-prefix-p" check, I guess. Sounds clever but I really doubt that would work in the general case. I'm not getting my point across I think. An LSP label is just a label. Except for in very primitive uses of LSP, it's not meant to be inserted or to be used in the computation of prefixes or commonality between completions. These primitives uses are deprecated as I hope the LSP quote from the spec confirmed. Foreign as it might seem to Emacs devs and users, LSP doesn't want any concept of "prefix" (or suffix or commonality). In general, two very closely related completions in the final insertion result can have two wildly different labels displayed to the user. In this sense, the "completions" popup in LSP is less like our all-too-familiar listing of strings that can help complete the thing at point and more akin to a specialized context menu for "things to _do_ at point". There's not even an LSP mandate that this thing to _do_ must include something to insert at point. Currently it could be just tidying up imports elsewhere in the LSP document. In future LSP versions, it could be just running an arbitrary server action, or sending an email. In conclusion, Emacs's partial completion makes no sense in LSP (except for the aforementioned fringe/deprecated cases). The correct fix for this separate issue to disable partial completion: either a full completion can be inserted or a listing of all applicable completions should be shown. The other "fix" is to lobby with the LSP spec people, but they're very VSCode-inclined. From what I've seen, even other editors which are more popular than Emacs have very little sway there. >>> completing to 'foo_bar_' keeps the popup active, so I just press RET >>> to pick the first completion. >> With the above 'foobar(int x, ' example and with bare C-M-i it's >> even >> worse: it's hard (if not impossible) to complete to the full completion >> and thus get the desired snippet expansion because the common prefix of >> both completion labels ends with a space. > > Yeah, it'd be great to have C-M-i stop before the paren. No, it wouldn't. It'd fix this particular case, but it could break in some other future version of LSP where the LSP label isn't a prefix of the thing that selecting that label would insert. >>> An alternative might be to use a completion-all-completions call, to >>> assert the full list of completions. Or some completions that are in >>> it anyway. >> Yes, I generally prefer "end-to-end" tests using interactive >> interfaces. >> So unless you're duplicating the test I think this part should be >> skipped. But your call. > > It's a different test (albeit with the same result as an existing > one). I don't mind rewriting it in a different style, if you > prefer. The result is kind of messy either way. My suggestion is just test that *Completions* pops up. >>> It's the same case as '("foo123" . 3) in the test above, isn't it? >> I don't think so. In a rust-analyzer hello world (which you can >> make >> with cargo init, if I'm not mistaken), both >> v.c1234.12345676890 >> v.count_on1234.12345676890 >> should expand to >> v.count_ones().1234567890 >> In the first case, you'll have to manually select "count_ones" from >> the >> completions buffer. The expansion and removal of the 1234 happens via >> LSP text edits, which are enacte by the :exit-function. > > Okay, I am seeing a difference too: C-M-i does eat the suffix in the > Rust example (the "1234"). But completion with Company does not :-/ I can't even get Company to appear in those situations. But I wouldn't bother about it. The bug report was about C-M-i originally. The important thing is that the LSP textEdit is run (via exit-function) with the correct LSP document state that the server expects. As far as I can tell, this is happening right now, so I'd be nice to have a test to shore it up. > I guess the difference might come from C-M-i always going through > try-completion, whereas the Company popup relies on all-completions. > > There's a similar difference when using gopls. > > But Clangd actually looks special (just filed separate bug#72765). > >> This scenario >> wasn't working a while ago and I'd like to protect it against >> regression. > > Would we have a test that launches rust-analyzer (and depends on it > being installed, and a Cargo project initialized)? Yes. Look in the existing eglot-tests.el: there is already such a test: eglot-test-rust-analyzer-watches-files. I'd just cargo-cult the lines until the "cargo init" call. Jo=C3=A3o From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 02:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.172455426316838 (code B ref 72705); Sun, 25 Aug 2024 02:52:01 +0000 Received: (at 72705) by debbugs.gnu.org; 25 Aug 2024 02:51:03 +0000 Received: from localhost ([127.0.0.1]:42044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1si3LK-0004NU-Qp for submit@debbugs.gnu.org; Sat, 24 Aug 2024 22:51:03 -0400 Received: from fhigh4-smtp.messagingengine.com ([103.168.172.155]:46501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1si3LH-0004Mx-8U for 72705@debbugs.gnu.org; Sat, 24 Aug 2024 22:51:01 -0400 Received: from phl-compute-02.internal (phl-compute-02.nyi.internal [10.202.2.42]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 2D6F31152A9D; Sat, 24 Aug 2024 22:50:04 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Sat, 24 Aug 2024 22:50:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1724554204; x=1724640604; bh=UYa4tbMk/G JqMudeGLUy0uXeE5tdAupyo6wPQyja400=; b=K+hopUHAuSqCBZ10GOVHVbyVqq W20q9sCb7yLV6KPuJVdibrFygoG+AnKowom/YmtfGte3QCVdaC3+KfSxogzfHFcW 1NxnSw1V4x4dKbpNeq6oC8+6MTPuAJ6DYv0eEimZed5vwd8qBAY5tvQAhtXe/0Wl oQ78sZa0HFOuTOjkazuQMrE41EKoJBt+FdMuWdk2hlhM14mzBFCgLjhyFiUybhxZ be0ZZmty+QXjdmlazY8g80h+puzCl/3a3vToktGxmpTYhs+xLKWeNSOFVDGGghII /2HTAXGKrAVRywCe2klsIuE5bq7YcuTlMhLN/hBN9KxbXVaSS8whDCNnZx2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1724554204; x=1724640604; bh=UYa4tbMk/GJqMudeGLUy0uXeE5td Aupyo6wPQyja400=; b=kdCiiTKFZQgHZCmZChi//jgECOQBIQtFGP6xF6/dOLj6 JN4kwXqsnmupYfkedCJtF5MV5OWWc2pO2rXOP0k1UoHNFPmbpsbj+iXO3NSTa0cS khgezSV7isGI2UqlHcarGWtWYHkZbx9wmK7KkRNctjQp824bHy6Jl5SNt6m/pofN WPTHeg7E/NMT7V7gpdvij2/dnD2VfiCLE+RNLbM8EITHhKB1j9wozT/xukBmNnd4 r3ndUeYN7zHkjXivbPlF3vtmcqU7V0mh4VVak9PnmpHnpccyc0xC7EbXnrjyPVUy Nu1V1GM/GcmbvqBoeXpyfDfWgsEFuAYb5qX90hlK7A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddvhedgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeehleefudekudduveekieelgfeiffdvkefhkeeljeeu jeegueekveffkeejjeevheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep vddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhorghothgrvhhorhgrsehgmh grihhlrdgtohhmpdhrtghpthhtohepjedvjedtheesuggvsggsuhhgshdrghhnuhdrohhr gh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 24 Aug 2024 22:50:02 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------arPiFn5kgdzYr0C0twxovAcZ" Message-ID: Date: Sun, 25 Aug 2024 05:49:59 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> <87ed6hyg1o.fsf@gmail.com> <06cfce49-33ff-41a2-b999-469c4a0009c0@gutov.dev> <87o75kwl2i.fsf@gmail.com> <87h6bbwn9l.fsf@gmail.com> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <87h6bbwn9l.fsf@gmail.com> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------arPiFn5kgdzYr0C0twxovAcZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 23/08/2024 13:23, João Távora wrote: >> Great! Bump it to 1.17.60? > > No, keep it at 1.17.30. That's the 1.17-ish version of Eglot that will > ship with Emacs 30, just as 1.12.29 is the 1.12-ish version of Eglot > that shipped with Emacs 29. > > The change you're proposing will eventually also be merged to master > and be part of the 1.18 GNU Elpa release (earlier I wrote 1.17 GNU Elpa > by mistake). Perfect, thanks. > Foreign as it might seem to Emacs devs and users, LSP doesn't want any > concept of "prefix" (or suffix or commonality). In general, two very > closely related completions in the final insertion result can have two > wildly different labels displayed to the user. In this sense, the > "completions" popup in LSP is less like our all-too-familiar listing of > strings that can help complete the thing at point and more akin to a > specialized context menu for "things to _do_ at point". There's not > even an LSP mandate that this thing to _do_ must include something to > insert at point. Currently it could be just tidying up imports > elsewhere in the LSP document. In future LSP versions, it could be just > running an arbitrary server action, or sending an email. I see what you're saying, but insofar that current completion is mostly working out well, adding the special logic for parens would improve a lot of cases, and keep others the same degree of broken (the email-sending ones, for sure). So it might be worth a try. Anyway, stopping any partial completion (at first I didn't understand that you meant a more general notion that the partial-completion c-style) should be similarly easy to what the current patch does. You would just drop the second clause in eglot--dumb-tryc, I think. Or maybe both the first and the second. > The other "fix" is to lobby with the LSP spec people, but they're very > VSCode-inclined. From what I've seen, even other editors which are more > popular than Emacs have very little sway there. It seems we only have our hacks to help. They got pretty advanced, though. >> Yeah, it'd be great to have C-M-i stop before the paren. > > No, it wouldn't. It'd fix this particular case, but it could break in > some other future version of LSP where the LSP label isn't a prefix of > the thing that selecting that label would insert. Quite possibly, yes. Though reverting to the simpler behavior at that point would just require a 3-4 lines diff, as discussed. >>>> An alternative might be to use a completion-all-completions call, to >>>> assert the full list of completions. Or some completions that are in >>>> it anyway. >>> Yes, I generally prefer "end-to-end" tests using interactive >>> interfaces. >>> So unless you're duplicating the test I think this part should be >>> skipped. But your call. >> >> It's a different test (albeit with the same result as an existing >> one). I don't mind rewriting it in a different style, if you >> prefer. The result is kind of messy either way. > > My suggestion is just test that *Completions* pops up. Alas, this check does not succeed: (should (get-buffer-window "*Completions")) This works: (when (buffer-live-p "*Completions*") (kill-buffer "*Completions*")) (completion-at-point) (should (looking-back "foo")) (should (looking-at "123")) (should (get-buffer "*Completions*")) Is that better? >>>> It's the same case as '("foo123" . 3) in the test above, isn't it? >>> I don't think so. In a rust-analyzer hello world (which you can >>> make >>> with cargo init, if I'm not mistaken), both >>> v.c1234.12345676890 >>> v.count_on1234.12345676890 >>> should expand to >>> v.count_ones().1234567890 >>> In the first case, you'll have to manually select "count_ones" from >>> the >>> completions buffer. The expansion and removal of the 1234 happens via >>> LSP text edits, which are enacte by the :exit-function. >> >> Okay, I am seeing a difference too: C-M-i does eat the suffix in the >> Rust example (the "1234"). But completion with Company does not :-/ > > I can't even get Company to appear in those situations. You might have an older version installed? > But I wouldn't bother about it. The bug report was about C-M-i > originally. The important thing is that the LSP textEdit is run (via > exit-function) with the correct LSP document state that the server > expects. As far as I can tell, this is happening right now, so I'd be > nice to have a test to shore it up. Okay, see the attached patch with the added test. It took way longer than expected. Seems pretty brittle (note how eglot--wait-for-rust-analyzer is defined), but should be better than nothing. I also checked how VS Code behaves in such completions, since we were talking about what LSP's authors designed for or not. Works differently: 1) Completions are not filtered by suffix, ever. 2) Completing count_ones() does not delete the suffix ("1234" remains). It might mean that either behavior is okay, though. --------------arPiFn5kgdzYr0C0twxovAcZ Content-Type: text/x-patch; charset=UTF-8; name="eglot--dumb-tryc-more-checks-v3.diff" Content-Disposition: attachment; filename="eglot--dumb-tryc-more-checks-v3.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL2VnbG90LmVsIGIvbGlzcC9wcm9nbW9kZXMv ZWdsb3QuZWwKaW5kZXggMzUzODc3ZjYwYzIuLjU5ZDljMzQ2NDI0IDEwMDY0NAotLS0gYS9s aXNwL3Byb2dtb2Rlcy9lZ2xvdC5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9lZ2xvdC5lbApA QCAtMzE0Miw4ICszMTQyLDE4IEBAIGVnbG90LS1kdW1iLWFsbGMKIChkZWZ1biBlZ2xvdC0t ZHVtYi10cnljIChwYXQgdGFibGUgcHJlZCBwb2ludCkKICAgKGxldCAoKHByb2JlIChmdW5j YWxsIHRhYmxlIHBhdCBwcmVkIG5pbCkpKQogICAgIChjb25kICgoZXEgcHJvYmUgdCkgdCkK LSAgICAgICAgICAocHJvYmUgKGNvbnMgcHJvYmUgKGxlbmd0aCBwcm9iZSkpKQotICAgICAg ICAgICh0IChjb25zIHBhdCBwb2ludCkpKSkpCisgICAgICAgICAgKHByb2JlCisgICAgICAg ICAgIChpZiAoYW5kIChub3QgKGVxdWFsIHByb2JlIHBhdCkpCisgICAgICAgICAgICAgICAg ICAgIChjbC1ldmVyeQorICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAocykgKHN0cmlu Zy1wcmVmaXgtcCBwcm9iZSBzIGNvbXBsZXRpb24taWdub3JlLWNhc2UpKQorICAgICAgICAg ICAgICAgICAgICAgKGZ1bmNhbGwgdGFibGUgcGF0IHByZWQgdCkpKQorICAgICAgICAgICAg ICAgKGNvbnMgcHJvYmUgKGxlbmd0aCBwcm9iZSkpCisgICAgICAgICAgICAgKGNvbnMgcGF0 IHBvaW50KSkpCisgICAgICAgICAgKHQKKyAgICAgICAgICAgOzsgTWF0Y2ggaWdub3Jpbmcg c3VmZml4OiBpZiB0aGVyZSBhcmUgYW55IGNvbXBsZXRpb25zIGZvcgorICAgICAgICAgICA7 OyB0aGUgY3VycmVudCBwcmVmaXggYXQgbGVhc3QsIGtlZXAgdGhlIGN1cnJlbnQgaW5wdXQu CisgICAgICAgICAgIChhbmQgKGZ1bmNhbGwgdGFibGUgKHN1YnN0cmluZyBwYXQgMCBwb2lu dCkgcHJlZCB0KQorICAgICAgICAgICAgICAgIChjb25zIHBhdCBwb2ludCkpKSkpKQogCiAo YWRkLXRvLWxpc3QgJ2NvbXBsZXRpb24tY2F0ZWdvcnktZGVmYXVsdHMgJyhlZ2xvdC1jYXBm IChzdHlsZXMgZWdsb3QtLWR1bWItZmxleCkpKQogKGFkZC10by1saXN0ICdjb21wbGV0aW9u LXN0eWxlcy1hbGlzdCAnKGVnbG90LS1kdW1iLWZsZXggZWdsb3QtLWR1bWItdHJ5YyBlZ2xv dC0tZHVtYi1hbGxjKSkKZGlmZiAtLWdpdCBhL3Rlc3QvbGlzcC9wcm9nbW9kZXMvZWdsb3Qt dGVzdHMuZWwgYi90ZXN0L2xpc3AvcHJvZ21vZGVzL2VnbG90LXRlc3RzLmVsCmluZGV4IDUz NGM0N2IyNjQ2Li40MTgyNGY0NzdiOCAxMDA2NDQKLS0tIGEvdGVzdC9saXNwL3Byb2dtb2Rl cy9lZ2xvdC10ZXN0cy5lbAorKysgYi90ZXN0L2xpc3AvcHJvZ21vZGVzL2VnbG90LXRlc3Rz LmVsCkBAIC01ODcsNiArNTg3LDE4IEBAIGVnbG90LS13YWl0LWZvci1jbGFuZ2QKICAgICAo ZWdsb3QtLXdhaXQtZm9yIChzLW5vdGlmcyAyMCkgKCZrZXkgbWV0aG9kICZhbGxvdy1vdGhl ci1rZXlzKQogICAgICAgKHN0cmluZz0gbWV0aG9kICJ0ZXh0RG9jdW1lbnQvcHVibGlzaERp YWdub3N0aWNzIikpKSkKIAorKGRlZnVuIGVnbG90LS13YWl0LWZvci1ydXN0LWFuYWx5emVy ICgpCisgIChlZ2xvdC0tc25pZmZpbmcgKDpzZXJ2ZXItbm90aWZpY2F0aW9ucyBzLW5vdGlm cykKKyAgICAoc2hvdWxkIChlZ2xvdC0tdGVzdHMtY29ubmVjdCkpCisgICAgKGVnbG90LS13 YWl0LWZvciAocy1ub3RpZnMgMjApICgma2V5IG1ldGhvZCBwYXJhbXMgJmFsbG93LW90aGVy LWtleXMpCisgICAgICAoYW5kCisgICAgICAgKHN0cmluZz0gbWV0aG9kICIkL3Byb2dyZXNz IikKKyAgICAgICAicnVzdEFuYWx5emVyL0luZGV4aW5nIgorICAgICAgIChlcXVhbCBwYXJh bXMKKyAgICAgICAgICAgICAgJyg6dG9rZW4gInJ1c3RBbmFseXplci9JbmRleGluZyIgOnZh bHVlCisgICAgICAgICAgICAgICAgICAgICAgIDs7IENvdWxkIHdhaXQgZm9yIDpraW5kICJl bmQiIGluc3RlYWQsIGJ1dCBpdCdzIDIgbW9yZSBzZWNvbmRzLgorICAgICAgICAgICAgICAg ICAgICAgICAoOmtpbmQgImJlZ2luIiA6dGl0bGUgIkluZGV4aW5nIiA6Y2FuY2VsbGFibGUg Ompzb24tZmFsc2UgOnBlcmNlbnRhZ2UgMCkpKSkpKSkKKwogKGVydC1kZWZ0ZXN0IGVnbG90 LXRlc3QtYmFzaWMtY29tcGxldGlvbnMgKCkKICAgIlRlc3QgYmFzaWMgYXV0b2NvbXBsZXRp b24gaW4gYSBjbGFuZ2QgTFNQLiIKICAgKHNraXAtdW5sZXNzIChleGVjdXRhYmxlLWZpbmQg ImNsYW5nZCIpKQpAQCAtNjAwLDYgKzYxMiwyMCBAQCBlZ2xvdC10ZXN0LWJhc2ljLWNvbXBs ZXRpb25zCiAgICAgICAobWVzc2FnZSAoYnVmZmVyLXN0cmluZykpCiAgICAgICAoc2hvdWxk IChsb29raW5nLWJhY2sgImZwcmludGYuPyIpKSkpKQogCisoZXJ0LWRlZnRlc3QgZWdsb3Qt dGVzdC1jb21tb24tcHJlZml4LWNvbXBsZXRpb24gKCkKKyAgIlRlc3QgY29tcGxldGlvbiBh cHBlbmRpbmcgdGhlIGNvbW1vbiBwcmVmaXguIgorICAoc2tpcC11bmxlc3MgKGV4ZWN1dGFi bGUtZmluZCAiY2xhbmdkIikpCisgIChlZ2xvdC0td2l0aC1maXh0dXJlCisgICAgICBgKCgi cHJvamVjdCIgLiAoKCJjb2lzby5jIiAuCisgICAgICAgICAgICAgICAgICAgICAgICwoY29u Y2F0ICJpbnQgZm9vX2JhcjsgaW50IGZvb19iYXJfYmF6OyIKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgImludCBtYWluKCkge2ZvbyIpKSkpKQorICAgICh3aXRoLWN1cnJl bnQtYnVmZmVyCisgICAgICAgIChlZ2xvdC0tZmluZC1maWxlLW5vc2VsZWN0ICJwcm9qZWN0 L2NvaXNvLmMiKQorICAgICAgKGVnbG90LS13YWl0LWZvci1jbGFuZ2QpCisgICAgICAoZ290 by1jaGFyIChwb2ludC1tYXgpKQorICAgICAgKGNvbXBsZXRpb24tYXQtcG9pbnQpCisgICAg ICAoc2hvdWxkIChsb29raW5nLWJhY2sgIntmb29fYmFyIikpKSkpCisKIChlcnQtZGVmdGVz dCBlZ2xvdC10ZXN0LW5vbi11bmlxdWUtY29tcGxldGlvbnMgKCkKICAgIlRlc3QgY29tcGxl dGlvbiByZXN1bHRpbmcgaW4gJ0NvbXBsZXRlLCBidXQgbm90IHVuaXF1ZScuIgogICAoc2tp cC11bmxlc3MgKGV4ZWN1dGFibGUtZmluZCAiY2xhbmdkIikpCkBAIC02MTksMTkgKzY0NSw5 OSBAQCBlZ2xvdC10ZXN0LW5vbi11bmlxdWUtY29tcGxldGlvbnMKICAgICAgICAgKGZvcndh cmQtbGluZSAtMSkKICAgICAgICAgKHNob3VsZCAobG9va2luZy1hdCAiQ29tcGxldGUsIGJ1 dCBub3QgdW5pcXVlIikpKSkpKSkKIAotKGVydC1kZWZ0ZXN0IGVnbG90LXRlc3QtYmFzaWMt eHJlZiAoKQotICAiVGVzdCBiYXNpYyB4cmVmIGZ1bmN0aW9uYWxpdHkgaW4gYSBjbGFuZ2Qg TFNQLiIKKyhlcnQtZGVmdGVzdCBlZ2xvdC10ZXN0LXN0b3AtY29tcGxldGlvbi1vbi1ub25w cmVmaXggKCkKKyAgIlRlc3QgY29tcGxldGlvbiBhbHNvIHJlc3VsdGluZyBpbiAnQ29tcGxl dGUsIGJ1dCBub3QgdW5pcXVlJy4iCisgIChza2lwLXVubGVzcyAoZXhlY3V0YWJsZS1maW5k ICJjbGFuZ2QiKSkKKyAgKGVnbG90LS13aXRoLWZpeHR1cmUKKyAgICAgIGAoKCJwcm9qZWN0 IiAuICgoImNvaXNvLmMiIC4KKyAgICAgICAgICAgICAgICAgICAgICAgLChjb25jYXQgImlu dCBmb290OyBpbnQgZm9vdGVyOyBpbnQgZm9fb2JhcjsiCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICJpbnQgbWFpbigpIHtmb28iKSkpKSkKKyAgICAod2l0aC1jdXJyZW50 LWJ1ZmZlcgorICAgICAgICAoZWdsb3QtLWZpbmQtZmlsZS1ub3NlbGVjdCAicHJvamVjdC9j b2lzby5jIikKKyAgICAgIChlZ2xvdC0td2FpdC1mb3ItY2xhbmdkKQorICAgICAgKGdvdG8t Y2hhciAocG9pbnQtbWF4KSkKKyAgICAgIChjb21wbGV0aW9uLWF0LXBvaW50KQorICAgICAg KHNob3VsZCAobG9va2luZy1iYWNrICJmb28iKSkpKSkKKworKGVydC1kZWZ0ZXN0IGVnbG90 LXRlc3QtdHJ5LWNvbXBsZXRpb24tbm9tYXRjaCAoKQorICAiVGVzdCBjb21wbGV0aW9uIHRh YmxlIHdpdGggbm9uLW1hdGNoaW5nIGlucHV0LCByZXR1cm5pbmcgbmlsLiIKKyAgKHNraXAt dW5sZXNzIChleGVjdXRhYmxlLWZpbmQgImNsYW5nZCIpKQorICAoZWdsb3QtLXdpdGgtZml4 dHVyZQorICAgICAgYCgoInByb2plY3QiIC4gKCgiY29pc28uYyIgLgorICAgICAgICAgICAg ICAgICAgICAgICAsKGNvbmNhdCAiaW50IG1haW4oKSB7YWJjIikpKSkpCisgICAgKHdpdGgt Y3VycmVudC1idWZmZXIKKyAgICAgICAgKGVnbG90LS1maW5kLWZpbGUtbm9zZWxlY3QgInBy b2plY3QvY29pc28uYyIpCisgICAgICAoZWdsb3QtLXdhaXQtZm9yLWNsYW5nZCkKKyAgICAg IChnb3RvLWNoYXIgKHBvaW50LW1heCkpCisgICAgICAoc2hvdWxkCisgICAgICAgKG51bGwK KyAgICAgICAgKGNvbXBsZXRpb24tdHJ5LWNvbXBsZXRpb24KKyAgICAgICAgICJhYmMiCisg ICAgICAgICAobnRoIDIgKGVnbG90LWNvbXBsZXRpb24tYXQtcG9pbnQpKSBuaWwgMykpKSkp KQorCisoZXJ0LWRlZnRlc3QgZWdsb3QtdGVzdC10cnktY29tcGxldGlvbi1pbnNpZGUtc3lt Ym9sICgpCisgICJUZXN0IGNvbXBsZXRpb24gdGFibGUgaW5zaWRlIHN5bWJvbCwgd2l0aCBv bmx5IHByZWZpeCBtYXRjaGluZy4iCiAgIChza2lwLXVubGVzcyAoZXhlY3V0YWJsZS1maW5k ICJjbGFuZ2QiKSkKICAgKGVnbG90LS13aXRoLWZpeHR1cmUKICAgICAgIGAoKCJwcm9qZWN0 IiAuICgoImNvaXNvLmMiIC4KLSAgICAgICAgICAgICAgICAgICAgICAgLChjb25jYXQgImlu dCBmb289NDI7IGludCBmb29leTsiCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICJpbnQgbWFpbigpIHtmb289ODI7fSIpKSkpKQorICAgICAgICAgICAgICAgICAgICAgICAs KGNvbmNhdAorICAgICAgICAgICAgICAgICAgICAgICAgICJpbnQgZm9vYmFyOyIKKyAgICAg ICAgICAgICAgICAgICAgICAgICAiaW50IG1haW4oKSB7Zm9vMTIzIikpKSkpCiAgICAgKHdp dGgtY3VycmVudC1idWZmZXIKICAgICAgICAgKGVnbG90LS1maW5kLWZpbGUtbm9zZWxlY3Qg InByb2plY3QvY29pc28uYyIpCi0gICAgICAoc2hvdWxkIChlZ2xvdC0tdGVzdHMtY29ubmVj dCkpCi0gICAgICAoc2VhcmNoLWZvcndhcmQgIntmb28iKQotICAgICAgKGNhbGwtaW50ZXJh Y3RpdmVseSAneHJlZi1maW5kLWRlZmluaXRpb25zKQotICAgICAgKHNob3VsZCAobG9va2lu Zy1hdCAiZm9vPTQyIikpKSkpCisgICAgICAoZWdsb3QtLXdhaXQtZm9yLWNsYW5nZCkKKyAg ICAgIChnb3RvLWNoYXIgKC0gKHBvaW50LW1heCkgMykpCisgICAgICAod2hlbiAoYnVmZmVy LWxpdmUtcCAiKkNvbXBsZXRpb25zKiIpCisgICAgICAgIChraWxsLWJ1ZmZlciAiKkNvbXBs ZXRpb25zKiIpKQorICAgICAgKGNvbXBsZXRpb24tYXQtcG9pbnQpCisgICAgICAoc2hvdWxk IChsb29raW5nLWJhY2sgImZvbyIpKQorICAgICAgKHNob3VsZCAobG9va2luZy1hdCAiMTIz IikpCisgICAgICAoc2hvdWxkIChnZXQtYnVmZmVyICIqQ29tcGxldGlvbnMqIikpCisgICAg ICApKSkKKworKGVydC1kZWZ0ZXN0IGVnbG90LXRlc3QtcnVzdC1jb21wbGV0aW9uLWV4aXQt ZnVuY3Rpb24gKCkKKyAgIkhvdmVyIGFuZCBoaWdobGlnaHRDaGFuZ2VzLiIKKyAgKHNraXAt dW5sZXNzIChleGVjdXRhYmxlLWZpbmQgInJ1c3QtYW5hbHl6ZXIiKSkKKyAgKHNraXAtdW5s ZXNzIChleGVjdXRhYmxlLWZpbmQgImNhcmdvIikpCisgIChlZ2xvdC0td2l0aC1maXh0dXJl CisgICAgICAnKCgiY21wbC1wcm9qZWN0IiAuCisgICAgICAgICAoKCJtYWluLnJzIiAuCisg ICAgICAgICAgICJmbiB0ZXN0KCkgLT4gaTMyIHsgbGV0IHY6IHVzaXplID0gMTsgdi5jb3Vu dF9vbjEyMzQuMTIzNDU2Nzg5MDsiKSkpKQorICAgICh3aXRoLWN1cnJlbnQtYnVmZmVyCisg ICAgICAgIChlZ2xvdC0tZmluZC1maWxlLW5vc2VsZWN0ICJjbXBsLXByb2plY3QvbWFpbi5y cyIpCisgICAgICAoc2hvdWxkICh6ZXJvcCAoc2hlbGwtY29tbWFuZCAiY2FyZ28gaW5pdCIp KSkKKyAgICAgIChlZ2xvdC0tdGVzdHMtY29ubmVjdCkKKyAgICAgIChnb3RvLWNoYXIgKHBv aW50LW1pbikpCisgICAgICAoc2VhcmNoLWZvcndhcmQgInYuY291bnRfb24iKQorICAgICAg KGxldCAoKG1pbmlidWZmZXItbWVzc2FnZS10aW1lb3V0IDApCisgICAgICAgICAgICA7OyBG YWlsIGF0IChkaW5nKSBpZiBjb21wbGV0aW9uIGZhaWxzLgorICAgICAgICAgICAgKGV4ZWN1 dGluZy1rYmQtbWFjcm8gdCkpCisgICAgICAgICh3aGVuIChidWZmZXItbGl2ZS1wICIqQ29t cGxldGlvbnMqIikKKyAgICAgICAgICAoa2lsbC1idWZmZXIgIipDb21wbGV0aW9ucyoiKSkK KyAgICAgICAgKGVnbG90LS13YWl0LWZvci1ydXN0LWFuYWx5emVyKQorICAgICAgICAoY29t cGxldGlvbi1hdC1wb2ludCkKKyAgICAgICAgKHNob3VsZCAobG9va2luZy1iYWNrICJcXC5j b3VudF9vbiIpKQorICAgICAgICAoc2hvdWxkIChnZXQtYnVmZmVyICIqQ29tcGxldGlvbnMq IikpCisgICAgICAgIChtaW5pYnVmZmVyLW5leHQtY29tcGxldGlvbiAxKQorICAgICAgICAo bWluaWJ1ZmZlci1jaG9vc2UtY29tcGxldGlvbiB0KSkKKyAgICAgIChzaG91bGQKKyAgICAg ICAoZXF1YWwKKyAgICAgICAgImZuIHRlc3QoKSAtPiBpMzIgeyBsZXQgdjogdXNpemUgPSAx OyB2LmNvdW50X29uZXMoKS4xMjM0NTY3ODkwOyIKKyAgICAgICAgKGJ1ZmZlci1zdHJpbmcp KSkpKSkKKworKGVydC1kZWZ0ZXN0IGVnbG90LXRlc3QtYmFzaWMteHJlZiAoKQorICAiVGVz dCBiYXNpYyB4cmVmIGZ1bmN0aW9uYWxpdHkgaW4gYSBjbGFuZ2QgTFNQLiIKKyAgKHNraXAt dW5sZXNzIChleGVjdXRhYmxlLWZpbmQgImNsYW5nZCIpKQorICAoZWdsb3QtLXdpdGgtZml4 dHVyZQorICAgYCgoInByb2plY3QiIC4gKCgiY29pc28uYyIgLgorICAgICAgICAgICAgICAg ICAgICAsKGNvbmNhdCAiaW50IGZvbz00MjsgaW50IGZvb2V5OyIKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgImludCBtYWluKCkge2Zvbz04Mjt9IikpKSkpCisgICAod2l0aC1j dXJyZW50LWJ1ZmZlcgorICAgICAgIChlZ2xvdC0tZmluZC1maWxlLW5vc2VsZWN0ICJwcm9q ZWN0L2NvaXNvLmMiKQorICAgICAoc2hvdWxkIChlZ2xvdC0tdGVzdHMtY29ubmVjdCkpCisg ICAgIChzZWFyY2gtZm9yd2FyZCAie2ZvbyIpCisgICAgIChjYWxsLWludGVyYWN0aXZlbHkg J3hyZWYtZmluZC1kZWZpbml0aW9ucykKKyAgICAgKHNob3VsZCAobG9va2luZy1hdCAiZm9v PTQyIikpKSkpCiAKIChkZWZ2YXIgZWdsb3QtLXRlc3QtYy1idWZmZXIKICAgIlwK --------------arPiFn5kgdzYr0C0twxovAcZ-- From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 09:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.172457962532688 (code B ref 72705); Sun, 25 Aug 2024 09:54:02 +0000 Received: (at 72705) by debbugs.gnu.org; 25 Aug 2024 09:53:45 +0000 Received: from localhost ([127.0.0.1]:42260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1si9wO-0008VA-LM for submit@debbugs.gnu.org; Sun, 25 Aug 2024 05:53:45 -0400 Received: from mail-wm1-f42.google.com ([209.85.128.42]:60600) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1si9wL-0008Uu-P1 for 72705@debbugs.gnu.org; Sun, 25 Aug 2024 05:53:43 -0400 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-42ab880b73eso29307705e9.0 for <72705@debbugs.gnu.org>; Sun, 25 Aug 2024 02:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724579506; x=1725184306; darn=debbugs.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=qZGQ7RADD/yKZzW1eCK+e9S/FZtvb3D4Y88M7kp3lSI=; b=V8jpXS87nis9PnSw9q+X6FfcutJNGpCSP0WMqNHP8WmV9xnWwuZ5h4Pl3U6jMO5OII AwJUcWNG66VtYLbd2+PjcAaeCI10hrwlPsorF5uo16sx1/gRd30P88OEu0T6j2e37WX4 vdnvnTe/UqHd3Bzh8/YLPmcn14BiSUVmhELXkGyBi6bHuojwVtd81W2olGwjIj7uxKTy bqcdhmHSBs4QotYiQR4e5Db3Yu8x8Jwwv8Dno+ehrzUrbYDZgNgxPHc+/g/PzldkIMTd ONcFiJwQ9wqh07PaetI9hLE82aJMOe2ZgIwYD4AxhE7y63rmiqHWYHgYGk9tm4g1/JBm zG9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724579506; x=1725184306; 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=qZGQ7RADD/yKZzW1eCK+e9S/FZtvb3D4Y88M7kp3lSI=; b=XdyFgBcbi3f7W84a7Vq/u6dToIJiUNeDdToRXITTXNMAT0Y9UJsyo4VAm4WOTfwU7v uqr7C3ex/KYXuO+aP93v7+PGet+vsFyBXXMswVnuBN10r40fGRvxq26cd63uDKpP5ojH bwi6geNzlb0YSoMel+xGnXgIdrek/q5G4OA/IEi5ojAx677vsBQjcuKms3TEikb8n3Yk g6gDYI6JwbBj3DRaLyDROY7j3soiy2uE1jisf+1e8+b0f1/gS80sv47UgxKjjTOee7yp DDTvUHWrZqL6z0qoI0ODCgXmD4dv5lMK5V28iEFeTlpgS4HmdD/mk6a0rOSgIUEU+s+3 PKCQ== X-Gm-Message-State: AOJu0YwZqhlpbHidwfn874+GTf4wyOHd7zuW4b6y4fR32dJ5wUH1e/EN 3Rckqq3z8Jkcvw4TZHqJ3CbeteKUCm/inhpOYyxBKu4gYZkdXBsFJq2X4A== X-Google-Smtp-Source: AGHT+IF061D9k8zz9eBTPHZb59TZ4EmOWRg6plloMvwTPtvUHF+ztkE0aJ1rb0nqK6tiHYQ7Z7t2nQ== X-Received: by 2002:a05:600c:1c1d:b0:426:67dd:e9e9 with SMTP id 5b1f17b1804b1-42acc8d36edmr50271295e9.3.1724579505363; Sun, 25 Aug 2024 02:51:45 -0700 (PDT) Received: from krug (87-196-102-145.net.novis.pt. [87.196.102.145]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42ac514e071sm119181585e9.4.2024.08.25.02.51.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Aug 2024 02:51:44 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= In-Reply-To: (Dmitry Gutov's message of "Sun, 25 Aug 2024 05:49:59 +0300") References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> <87ed6hyg1o.fsf@gmail.com> <06cfce49-33ff-41a2-b999-469c4a0009c0@gutov.dev> <87o75kwl2i.fsf@gmail.com> <87h6bbwn9l.fsf@gmail.com> Date: Sun, 25 Aug 2024 10:53:10 +0100 Message-ID: <874j79vshl.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 23/08/2024 13:23, Jo=C3=A3o T=C3=A1vora wrote: > > I see what you're saying, but insofar that current completion is > mostly working out well, adding the special logic for parens would > improve a lot of cases, and keep others the same degree of broken (the > email-sending ones, for sure). So it might be worth a try. No, it's not. It's the kind of complexity Eglot isn't after. It's a losing game with the growing number of servers who aren't bound by these rules in any way. > Anyway, stopping any partial completion (at first I didn't understand > that you meant a more general notion that the partial-completion > c-style) should be similarly easy to what the current patch does. You > would just drop the second clause in eglot--dumb-tryc, I think. Or > maybe both the first and the second. If it's easy, then we should definitely do it. >> The other "fix" is to lobby with the LSP spec people, but they're very >> VSCode-inclined. From what I've seen, even other editors which are more >> popular than Emacs have very little sway there. > > It seems we only have our hacks to help. They got pretty advanced, > though. Yes, but they always lose. >>> Yeah, it'd be great to have C-M-i stop before the paren. >> No, it wouldn't. It'd fix this particular case, but it could break >> in >> some other future version of LSP where the LSP label isn't a prefix of >> the thing that selecting that label would insert. > > Quite possibly, yes. Though reverting to the simpler behavior at that > point would just require a 3-4 lines diff, as discussed. That's more complexity. And you can't easily know _if_ the LSP label is or isn't a prefix of the thing selecting the completion would insert without effectively simulating the completion (which is frequently). > Alas, this check does not succeed: > > (should (get-buffer-window "*Completions")) Window management code, likely. > This works: > > (when (buffer-live-p "*Completions*") > (kill-buffer "*Completions*")) > (completion-at-point) > (should (looking-back "foo")) > (should (looking-at "123")) > (should (get-buffer "*Completions*")) > > Is that better? It's half-decent, I think. Please use that. >>> Okay, I am seeing a difference too: C-M-i does eat the suffix in the >>> Rust example (the "1234"). But completion with Company does not :-/ >> I can't even get Company to appear in those situations. > You might have an older version installed? Maybe. > 1) Completions are not filtered by suffix, ever. > 2) Completing count_ones() does not delete the suffix ("1234" > remains). Interesting, I thought deleting the 1234 was part of the edit, but the user of that bug report was after some Emacs specific behaviour. Anyway, I don't think the test is too brittle, and I think I'd like to know anyway if something about that breaks anyway. Maybe you can just add a comment saying ";; this test might be a bit too brittle, but interesting nonetheless". I think you can commit the patch then. Thanks. Jo=C3=A3o From unknown Sun Jun 22 00:20:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72705 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 72705@debbugs.gnu.org Received: via spool by 72705-submit@debbugs.gnu.org id=B72705.17246014277774 (code B ref 72705); Sun, 25 Aug 2024 15:58:02 +0000 Received: (at 72705) by debbugs.gnu.org; 25 Aug 2024 15:57:07 +0000 Received: from localhost ([127.0.0.1]:43171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siFc3-00021J-1R for submit@debbugs.gnu.org; Sun, 25 Aug 2024 11:57:07 -0400 Received: from fhigh4-smtp.messagingengine.com ([103.168.172.155]:51383) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siFc1-00020m-6X for 72705@debbugs.gnu.org; Sun, 25 Aug 2024 11:57:06 -0400 Received: from phl-compute-04.internal (phl-compute-04.nyi.internal [10.202.2.44]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 8640D114E848; Sun, 25 Aug 2024 11:56:09 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Sun, 25 Aug 2024 11:56:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1724601369; x=1724687769; bh=+D7hU0UsueUbJyiJMGkMi9DQZ6TpCYaaL7mOXglMfmI=; b= ZtsadFwrJ0Ii4UdGXc4xjD7Fkle2OIxTO3Q1pB7eYmMsLEn/VwEtKmn3qN4Tl7eJ CwQjYTGOe2W89dadwP0hGSf12tefO8SCKo5zZjwx7ani2RvBZxGaIbQgSvzpBuGc uP4Ov3/9eZF0dB3wAh/lBfFJoWzMuF/4Pf45YdeitiUeZFbP+/77UYE73Fv38NY+ d3kKVMEHmSj3IX3Dihjyb3C2WtuY1bug5aa+QWCajXtmRRipLH6GI486VJ0dsHQQ lDzX0lp1iv1xnZQOMPtECWydpPDZWeVqXsuBUiQDKkmdt5oiPrBwOPn6iTHfd0lA WD4I6w2xtH28Yl9qgFl7xw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1724601369; x= 1724687769; bh=+D7hU0UsueUbJyiJMGkMi9DQZ6TpCYaaL7mOXglMfmI=; b=F lycnIrBvSI5nwMc0qOhhkXpDvDTwgDTKKNYJasQx5t0E9aFU7J3OsAw2NsUS2kXK 1V0jH3bTmRUnpUFfK821q+HibV39IU9jMQSsItnoF9w5KwQFww9CBmFFMFy8C0rr XTRSofsRznAwMx6NqRg9Gscxjp1x/+QOy1dKmKZfkJJYIO0UY7dP+5Tg20yWvYuv jbLeCTWWjggmtHV+H2+onGVx5sHtu+DzfabAs7vijo40zNONcQVqcRdTXeRvc5kv 0SWgm9nCwVoPFi8aBCxXX9ILVUtweG2I0g5DjrTaB2Qmd9BoAhVxS2A2JNVMknhO 6R1wngioKA06eNGBIjC7Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddviedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveeg tedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho pedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjohgrohhtrghvohhrrgesgh hmrghilhdrtghomhdprhgtphhtthhopeejvdejtdehseguvggssghughhsrdhgnhhurdho rhhg X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 25 Aug 2024 11:56:08 -0400 (EDT) Message-ID: Date: Sun, 25 Aug 2024 18:56:06 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> <87ed6hyg1o.fsf@gmail.com> <06cfce49-33ff-41a2-b999-469c4a0009c0@gutov.dev> <87o75kwl2i.fsf@gmail.com> <87h6bbwn9l.fsf@gmail.com> <874j79vshl.fsf@gmail.com> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <874j79vshl.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 25/08/2024 12:53, João Távora wrote: > Dmitry Gutov writes: > >> On 23/08/2024 13:23, João Távora wrote: >> >> I see what you're saying, but insofar that current completion is >> mostly working out well, adding the special logic for parens would >> improve a lot of cases, and keep others the same degree of broken (the >> email-sending ones, for sure). So it might be worth a try. > > No, it's not. It's the kind of complexity Eglot isn't after. It's a > losing game with the growing number of servers who aren't bound by these > rules in any way. > >> Anyway, stopping any partial completion (at first I didn't understand >> that you meant a more general notion that the partial-completion >> c-style) should be similarly easy to what the current patch does. You >> would just drop the second clause in eglot--dumb-tryc, I think. Or >> maybe both the first and the second. > > If it's easy, then we should definitely do it. The corresponding change probably looks like this: diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index 844fc634be9..fcf4e586ead 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -3147,20 +3147,10 @@ eglot--dumb-flex (defun eglot--dumb-allc (pat table pred _point) (funcall table pat pred t)) (defun eglot--dumb-tryc (pat table pred point) - (let ((probe (funcall table pat pred nil))) - (cond ((eq probe t) t) - (probe - (if (and (not (equal probe pat)) - (cl-every - (lambda (s) (string-prefix-p probe s completion-ignore-case)) - (funcall table pat pred t))) - (cons probe (length probe)) - (cons pat point))) - (t - ;; Match ignoring suffix: if there are any completions for - ;; the current prefix at least, keep the current input. - (and (funcall table (substring pat 0 point) pred t) - (cons pat point)))))) + ;; Match ignoring suffix: if there are any completions for + ;; the current prefix at least, keep the current input. + (and (funcall table (substring pat 0 point) pred t) + (cons pat point))) (add-to-list 'completion-category-defaults '(eglot-capf (styles eglot--dumb-flex))) (add-to-list 'completion-styles-alist '(eglot--dumb-flex eglot--dumb-tryc eglot--dumb-allc)) But I'd prefer to hold off on it until specific issues come up. >> This works: >> >> (when (buffer-live-p "*Completions*") >> (kill-buffer "*Completions*")) >> (completion-at-point) >> (should (looking-back "foo")) >> (should (looking-at "123")) >> (should (get-buffer "*Completions*")) >> >> Is that better? > > It's half-decent, I think. Please use that. Okay. >> 1) Completions are not filtered by suffix, ever. >> 2) Completing count_ones() does not delete the suffix ("1234" >> remains). > > Interesting, I thought deleting the 1234 was part of the edit, but the > user of that bug report was after some Emacs specific behaviour. > Anyway, I don't think the test is too brittle, and I think I'd like to > know anyway if something about that breaks anyway. Maybe you can just > add a comment saying ";; this test might be a bit too brittle, but > interesting nonetheless". Pushed to emacs-30 as two parts: new tests for existing behavior and the fix with its own tests (096730510cd, 713069dd7a8). From unknown Sun Jun 22 00:20:22 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Dmitry Gutov Subject: bug#72705: closed (Re: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much) Message-ID: References: X-Gnu-PR-Message: they-closed 72705 X-Gnu-PR-Package: emacs Reply-To: 72705@debbugs.gnu.org Date: Sun, 25 Aug 2024 23:42:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1724629322-27135-1" This is a multi-part message in MIME format... ------------=_1724629322-27135-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #72705: 31.0.50; eglot--dumb-tryc Filters out too much which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 72705@debbugs.gnu.org. --=20 72705: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D72705 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1724629322-27135-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 72705-done) by debbugs.gnu.org; 25 Aug 2024 23:41:36 +0000 Received: from localhost ([127.0.0.1]:43439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siMrX-00072u-QS for submit@debbugs.gnu.org; Sun, 25 Aug 2024 19:41:36 -0400 Received: from fhigh1-smtp.messagingengine.com ([103.168.172.152]:52111) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siMrV-00072g-Q8 for 72705-done@debbugs.gnu.org; Sun, 25 Aug 2024 19:41:34 -0400 Received: from phl-compute-02.internal (phl-compute-02.nyi.internal [10.202.2.42]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 097771151A25; Sun, 25 Aug 2024 19:40:38 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Sun, 25 Aug 2024 19:40:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1724629238; x=1724715638; bh=ZGqlkX+MD6bkX2Ygk3K/lP0+1xs8vifVZdhXAF294Kk=; b= P0Aq95N5ilHqcCr0gYA1c4XVLttm70NEy93k7W/NcUxziMibv8C6FxkKgFw5cnHZ i0pEYDpjIyWhopCuauCuG+b7ldAuUxUAj6tarBeTHb2faVaYxVE6lPmbK/arUxII DWve74TKN9RkO14YlTHDHNfzCiXH3f8phXQ8Gh3UTiu+MTD1eSWG2MlvBcd1Ff7I 27OLee+ZxtHAwQEcZ/Fm0vcP3IT+oYYazbcipgWMVU3Z98f0pxSvv3rjf0t0Bwrq jaM/BPqB4/n2GsAlEQ7ROQopzP0Mtiwsal+3OEyVrhaaHZRrG9IkXYZP1DScEspH KEnOqv8vfA+ZUHi+MxeYRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1724629238; x= 1724715638; bh=ZGqlkX+MD6bkX2Ygk3K/lP0+1xs8vifVZdhXAF294Kk=; b=S xIGuN9t0ZpLEy3NyvP6JvChBW3eiT3XRgZZrHHGWx651lE3auhVLL73UpH6RhDu+ n6IoFNcgxitDPiB0h77PHC3lowHczvtL8xkCvwj7GGYhpR/tlo9LvcM1L2b1OSmz pCULGQJJgdQd+ledU0snbBLx0IfyYgVQQ48zNgwY3iaXuEqWn29nrENLW7TEv8iz appyGvRheq5MfrxQXfRMXagVOzV9ugsA6jVcdQPjYdHGp6/yR2hhEwXeTsVMh6xy r5ScFpbuk3+zBcC4FG3N81/pDVohDcMGu+8ANZeTistb8VJg879Iu4EB2NnXkb14 z7YxHNnECTLGjnBZZT1AA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddvjedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveeg tedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho pedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjohgrohhtrghvohhrrgesgh hmrghilhdrtghomhdprhgtphhtthhopeejvdejtdehqdguohhnvgesuggvsggsuhhgshdr ghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 25 Aug 2024 19:40:36 -0400 (EDT) Message-ID: Date: Mon, 26 Aug 2024 02:40:34 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <54dacc71-4395-431f-abc4-c60dc070cb03@gutov.dev> <0ff5f767-be87-4d64-964c-0a20fa776acf@gutov.dev> <0632f40f-98fd-4388-aba0-629a32d415eb@gutov.dev> <87ed6hyg1o.fsf@gmail.com> <06cfce49-33ff-41a2-b999-469c4a0009c0@gutov.dev> <87o75kwl2i.fsf@gmail.com> <87h6bbwn9l.fsf@gmail.com> <874j79vshl.fsf@gmail.com> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <874j79vshl.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72705-done Cc: 72705-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 25/08/2024 12:53, João Távora wrote: >>>> Okay, I am seeing a difference too: C-M-i does eat the suffix in the >>>> Rust example (the "1234"). But completion with Company does not :-/ >>> I can't even get Company to appear in those situations. >> You might have an older version installed? > Maybe. Okay, I've tracked this one down to Company adhering to what completion style is being used. When no completions match the suffix, completion-all-completions falls back to c-style 'emacs22' (if it's in completion-styles anyway). And when that style is used, we don't replace the suffix. There is a report for vanilla completion in bug#70968. That seems to cover all related issues I've found so far. Thanks, and closing. ------------=_1724629322-27135-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 19 Aug 2024 01:52:07 +0000 Received: from localhost ([127.0.0.1]:57146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfrZ0-00020s-Lb for submit@debbugs.gnu.org; Sun, 18 Aug 2024 21:52:07 -0400 Received: from lists.gnu.org ([209.51.188.17]:35486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfrYx-00020j-UZ for submit@debbugs.gnu.org; Sun, 18 Aug 2024 21:52:04 -0400 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 1sfrYI-00025y-FJ for bug-gnu-emacs@gnu.org; Sun, 18 Aug 2024 21:51:22 -0400 Received: from fout7-smtp.messagingengine.com ([103.168.172.150]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sfrYG-0000ss-EW for bug-gnu-emacs@gnu.org; Sun, 18 Aug 2024 21:51:22 -0400 Received: from phl-compute-06.internal (phl-compute-06.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id 6D0AD138D5D4 for ; Sun, 18 Aug 2024 21:51:19 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Sun, 18 Aug 2024 21:51:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm2; t=1724032279; x=1724118679; bh=9CjpP5YwIhKVaPmxIDWwezBF1BqQnzvd cIhEJIDuO38=; b=mPGlcpzLPXqRaIkDS74khEUOifXmyS+SH+tvFVcEOOxrlA0P zUqJi4wNd5Bo9a9KHSxmvz6gjwzthS1qkLYyguIlFMOvcvOldm2yQenzxQU0vRvy zlTfTGO8iyekQUW/CY9FXRJVLuIq63vFVmGqmgDm1B/NerDIaPpgiWHipdmetn// WcgJsIS7G3ckDhp7k9PuE4j4gmnhShGKol+Vk6E9QStAtuBsFNtrAYpVvp02aYaw 2sW1p4RYVC66yj2CqbUzTTtBoPWaP5wIHDkEGwwmNcddEHNrjGOlqZEOVyFf0ZPp s6fVdPchQbNKWsvCANM60nxga6iArgWXdB7yIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1724032279; x=1724118679; bh=9CjpP5YwIhKVaPmxIDWwezBF1BqQnzvdcIh EJIDuO38=; b=Q6DTAkxgTXouKuh6HPpgJKvD9MZJC2Qa28KdNMNIiUZ3vlcoHiz 1myiUBbRk9hYRmbDmBlaYMkyp2oeMbqJLskiclAHq6BXlC1uM2Y4OYLuGHNxXVG1 8rHn/f6Qr37CQQJgaiZBKtiRoVE+zng/xJX+nF6WUqpmaMdyz1Qfdh54gmG0FAOy lQnK2UI00pLWgBzEm5a1+g9e0THMqvXDSHMxLEw3hr2hL8JZCUQ/FCZ5NApD6+UD qFubJYaZwmGm3/PXY1acrdaHIiE/X6WuS56Fq+Wra+wGbrjSwZ8ZBohyvWZ+vH6k fE8cv/FCLcAQdCz0rJZ0aoINjx23bx7dX6Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddufedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpegtkfffgg gfvffuhfesmhdtreertddvjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughm ihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeefkeevleeuieegte elheefieeggfffgedtleelhfdvuddtkefgveelieeutdffheenucffohhmrghinhepghhi thhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopedupdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnh hurdhorhhg X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 18 Aug 2024 21:51:18 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------Ne087yXGQwAA5wHdhm38xk7i" Message-ID: Date: Mon, 19 Aug 2024 04:51:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: bug-gnu-emacs@gnu.org Subject: 31.0.50; eglot--dumb-tryc Filters out too much Content-Language: en-US From: Dmitry Gutov Received-SPF: pass client-ip=103.168.172.150; envelope-from=dmitry@gutov.dev; helo=fout7-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) This is a multi-part message in MIME format. --------------Ne087yXGQwAA5wHdhm38xk7i Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Debbugs-Cc: joaotavora@gmail.com 1. Have a project with just one file, test.go (attached). 2. Visit it, enable go-ts-mode, call 'M-x eglot'. 3. Move point right after "math.As", press C-M-i. 4. Code will get completed to "math.Asin" This is a problem because "math.As" has more completions (one can look at them by pressing TAB after "math.A") - such as "Acos", "Acosh" and "Abs" - in other words, "fuzzy" matches. Expected behavior: 1. When input is "math.As" - keep the string as-is. 2. When input is "math.Asi" - complete to "math.Asin". This problem seems older than 65ea742ed5ec (the change that introduced eglot--dumb-tryc itself, bug#68699), but it doesn't reproduce with Eglot from Emacs 29. Branches emacs-30 and master are affected. There is also another issue there: when there are no completions at all, this style still has completion-try-completion return a non-nil value (the last line of the implementation). Both of these issues is something I came across when working on closer 'try-completion' integration for company-mode (https://github.com/company-mode/company-mode/pull/1488) and testing out the new code with Eglot. Not sure what's the best fix, but the patch below seems to address both problems in my limited testing. WDYT? diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index 353877f60c2..e8823a9d2f0 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -3142,8 +3142,14 @@ eglot--dumb-allc (defun eglot--dumb-tryc (pat table pred point) (let ((probe (funcall table pat pred nil))) (cond ((eq probe t) t) - (probe (cons probe (length probe))) - (t (cons pat point))))) + ((and probe + (cl-every + (lambda (s) (string-prefix-p probe s completion-ignore-case)) + (funcall table pat pred t))) + (cons probe (length probe))) + (t + (and (funcall table pat pred t) + (cons pat point)))))) (add-to-list 'completion-category-defaults '(eglot-capf (styles eglot--dumb-flex))) (add-to-list 'completion-styles-alist '(eglot--dumb-flex eglot--dumb-tryc eglot--dumb-allc)) --------------Ne087yXGQwAA5wHdhm38xk7i Content-Type: text/x-go; charset=UTF-8; name="test.go" Content-Disposition: attachment; filename="test.go" Content-Transfer-Encoding: base64 cGFja2FnZSB0ZXN0CgppbXBvcnQgIm1hdGgiCgpmdW5jIG1haW4oKSB7CgltYXRoLkFzCn0K --------------Ne087yXGQwAA5wHdhm38xk7i-- ------------=_1724629322-27135-1--