From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#70724: 29.2.50; eglot-reconnect errors when the project is deleted Date: Sat, 4 May 2024 04:09:48 +0300 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25458"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: app-emacs-dev@janestreet.com To: Spencer Baugh , 70724@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 04 03:11:08 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s33vf-0006Qx-7m for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 May 2024 03:11:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s33vG-0008Ko-9j; Fri, 03 May 2024 21:10:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s33vE-0008KO-2f for bug-gnu-emacs@gnu.org; Fri, 03 May 2024 21:10:40 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s33vD-00052L-QW for bug-gnu-emacs@gnu.org; Fri, 03 May 2024 21:10:39 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s33va-0008GV-FE for bug-gnu-emacs@gnu.org; Fri, 03 May 2024 21:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 May 2024 01:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70724 X-GNU-PR-Package: emacs Original-Received: via spool by 70724-submit@debbugs.gnu.org id=B70724.171478502831744 (code B ref 70724); Sat, 04 May 2024 01:11:02 +0000 Original-Received: (at 70724) by debbugs.gnu.org; 4 May 2024 01:10:28 +0000 Original-Received: from localhost ([127.0.0.1]:50257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s33v1-0008Fw-PU for submit@debbugs.gnu.org; Fri, 03 May 2024 21:10:28 -0400 Original-Received: from wfout8-smtp.messagingengine.com ([64.147.123.151]:57181) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s33uw-0008Fm-Kc for 70724@debbugs.gnu.org; Fri, 03 May 2024 21:10:26 -0400 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfout.west.internal (Postfix) with ESMTP id 9551C1C0008D; Fri, 3 May 2024 21:09:53 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 03 May 2024 21:09:53 -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=1714784993; x=1714871393; bh=WeH2tSAPkcnEzOjFQnscZUyfcwtixcbalfXJgcZdHI8=; b= A1xAgLSWk1Eh4SWBMlVbKHoQZ8z+MnVLTxZ67zXqLeFdb0HvNG2mSl7FMNKVxMd4 8EY265Hkey2QlKZ6+0teJOF+bfpuvFnGBC1LOl7sTr9JsHeSxSYmaMoPN50BVwwx 9NdIfJTtN2dHhRscnq1PilRWzscSIpNNTxmnL8L0VQ0ayCr5LcSlKWzAC7o8hQRW pn7cHsJJ/rr+LtRKaC1b4tiTsLhWiYOUnZ53PWRisI2Agsf0u7Fq0zaBWOEcSBze 4FOnbyYewefkbsCjk5GkOb9mZ6hZdBswfQ6gmOnIOukuK5+Ud50oJBMhTmKaJF3i RvTDhveyHgvWHuM7yK8yqg== 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=fm3; t=1714784993; x= 1714871393; bh=WeH2tSAPkcnEzOjFQnscZUyfcwtixcbalfXJgcZdHI8=; b=l JFr4jieXyU/wj6+IuJDfMK0T7PjmR7UmpKq9zrtznZFgK8+q0p3f1ch+KcP3wKKW Xh/MxOEbdtRG3WjMFRRAHaM0XA9jAWHkCBkjCit3DddO11l7xWUpKq3l8CxLqmXD SC3FoaHdwSWAgJNPSEUBvrT86ILM8NmbL9xUhG1Zj9w+Gg/1oG/PAVhmqvf5oFiW oq3JfPUJFeH+wks/DQGBZ+6pM8QqxxnN57SZUoc+cheBRphdaQraV1QtgQ13E9xL CXHo8WTLViUN5J71MI4tvycdVykdSjWU38rDe90fQaUwIUGKsc2kwkg/WBjMDd7B NSuX8Y7uFgC/OVN/1hvCA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvddvuddggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 3 May 2024 21:09:51 -0400 (EDT) Content-Language: en-US In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284397 Archived-At: Hi Spencer, On 02/05/2024 22:37, Spencer Baugh wrote: > > In some project /home/foo/proj, with pretty much any LSP server: > > 1. In /home/foo/proj, M-x eglot, starting some LSP server > > 2. Delete the directory /home/foo/proj > > 3. The LSP server will crash/exit > > 4. The process sentinel for the server will run, running > eglot--on-shutdown which by default will call eglot-reconnect > > 5. eglot-reconnect extracts the saved project instance out of the > server, which has a root directory which no longer exists, and calls > eglot--connect with it > > 6. eglot--connect calls project-name on a nonexistent project instance, > which may fail with an error depending on the project implementation > (I have a custom project implementation, but I think this can happen > with project-vc too) > > 7. This causes the process sentinel to error. > > I think the right fix is probably for eglot--on-shutdown (or maybe > eglot-reconnect) to call (project-current nil (project-root pr)) to find > the new project instance. If that returns nil, the project has > disappeared, and eglot should just not try to reconnect. This also > would make eglot behave better if the project layout changes (e.g. if > there are nested projects). I think I like this solution (as long as the nil value returned by project-current on this step is appropriately handled). Something like: diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index 6896baf30ce..7b2461c3ce6 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -1426,11 +1426,15 @@ eglot-reconnect (interactive (list (eglot--current-server-or-lose) t)) (when (jsonrpc-running-p server) (ignore-errors (eglot-shutdown server interactive nil 'preserve-buffers))) - (eglot--connect (eglot--major-modes server) - (eglot--project server) - (eieio-object-class-name server) - (eglot--saved-initargs server) - (eglot--language-ids server)) + (let* ((root (project-root (eglot--project server))) + (project (project-current nil root))) + (if (not project) + (eglot--error "Project in `%s' is gone!" root) + (eglot--connect (eglot--major-modes server) + project + (eieio-object-class-name server) + (eglot--saved-initargs server) + (eglot--language-ids server)))) (eglot--message "Reconnected!")) (defvar eglot--managed-mode) ; forward decl Though it also raises a question about the caching strategy for VC-Aware project backend. At the moment is associates a project with a directory more or less indefinitely, and this is a case to watch out for. > Alternatively, maybe eglot--on-shutdown shouldn't automatically > reconnect in the first place? Maybe reconnection should happen > automatically only when some specific buffer tries to interact with the > LSP - then it can run project-current in the context of that specific > buffer, and see there's no project, and fail. Plus, if the user kills > all the buffers in the project (possibly with project-kill-buffers) > before deleting it, this approach would entirely avoid the unnecessary > eglot reconnection attempt. This also sounds good, though it'd probably require more changes overall. Additionally, perhaps I'd change the association from (server -> project) to (server -> project-root), relying on the project backends' internal caches to fetch the project value whenever it's needed. That might be the most reliable approach. Perhaps the slowest in theory, but hopefully not noticeably so.