From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#62116: RFE: eglot: support window.showDocument LSP RPC Date: Sat, 11 Mar 2023 12:56:32 +0000 Message-ID: <87jzznxx8f.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21712"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Felician Nemeth , 62116@debbugs.gnu.org To: Alan Donovan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 11 13:55:16 2023 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 1paykm-0005VZ-54 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Mar 2023 13:55:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1payka-0005M9-1M; Sat, 11 Mar 2023 07:55:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paykY-0005Lw-U7 for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 07:55:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1paykY-00089T-BT for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 07:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1paykX-0001Sf-QO for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 07:55:01 -0500 X-Loop: help-debbugs@gnu.org 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: Sat, 11 Mar 2023 12:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62116 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 62116-submit@debbugs.gnu.org id=B62116.16785392825589 (code B ref 62116); Sat, 11 Mar 2023 12:55:01 +0000 Original-Received: (at 62116) by debbugs.gnu.org; 11 Mar 2023 12:54:42 +0000 Original-Received: from localhost ([127.0.0.1]:56757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paykE-0001S3-5m for submit@debbugs.gnu.org; Sat, 11 Mar 2023 07:54:42 -0500 Original-Received: from mail-wm1-f54.google.com ([209.85.128.54]:42793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paykB-0001Rl-QV for 62116@debbugs.gnu.org; Sat, 11 Mar 2023 07:54:40 -0500 Original-Received: by mail-wm1-f54.google.com with SMTP id o11-20020a05600c4fcb00b003eb33ea29a8so5112498wmq.1 for <62116@debbugs.gnu.org>; Sat, 11 Mar 2023 04:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678539274; 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=/9wlwvORpfYKk7PSOYP2vedOYJXqTEY60rhfUgtXs40=; b=RV95ayDEPebDwOHkIi8EWUhxHqJvD8Q1yvf8jK4nk1KSPbqoroaBRgg0mcf+y12Tol s/IqHe7MfjG6mrPTMn+FyG+0WuGicYDhXH8TXqvPwA70KWQjBiIKuV8/5qqWKg20erda SZ/j/kWoRezn5NJr1zwHaJHxBZE9nsIWoOsUwnYIe2bwaRLO/PtKbCAxe5/7AdCpERi2 JJFk8eIynCv58OZbRogfgvPhMZ8Sx6amsuWClHxo6UYynCdbyjM3j0Zq84SptrGOT6zt DSLcRLwpjckAoBQ6ABE89YvBtaK/nN6w9HJnhXs+fPv3iGetXIYQECPtzhfsy8qd0wbE giXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678539274; 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=/9wlwvORpfYKk7PSOYP2vedOYJXqTEY60rhfUgtXs40=; b=V1n/KrQMTFqXJe26gtuJUcifjyUkELJdBYWsfY8n5YDO/yQ6O5zaWfNx5LcL4l/ba6 nmGZ2MH7Zvc5AkVrFgTzm6QJWaROQTPvsXog4t+VS7/N6cplGdHQFt1MSIwgWAC2lfR5 i2Q0nfdBJR4L3xOXEaR8NgBFk2PdL7ubj2mYIg/cQK5qOX+BPK2XgFJXhITxSc2bXRnf ReldyHixc23sw+qmbSKikbivh6xpUh8H0f2ePirAL5OgNVRegqVey/JqQvtQXVGzj/XI JmqTIDmWQnk3xJsS4jzf33Mzqhns7/B3hCOq+/bi84RzFemv2QvlCfMOPs/hLmoDMVkv qd9g== X-Gm-Message-State: AO0yUKUuA5LSIQU10wZmjyiuI5M8yacd+kO3YeQ/rQPhBDUDjkkNvlZ6 RDilekDkfowDYLq/2A6tFkg= X-Google-Smtp-Source: AK7set/KKKqDf5iH2LKFSIMGO/gB85kIinOaxa5zg+B4rZbi9jIjlhkZZch8ZgYjyhOwL4dMsQQHZw== X-Received: by 2002:a05:600c:190a:b0:3e0:6c4:6a38 with SMTP id j10-20020a05600c190a00b003e006c46a38mr5601264wmq.33.1678539273839; Sat, 11 Mar 2023 04:54:33 -0800 (PST) Original-Received: from krug (87-196-72-142.net.novis.pt. [87.196.72.142]) by smtp.gmail.com with ESMTPSA id r14-20020adff70e000000b002c5804b6afasm2304505wrp.67.2023.03.11.04.54.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Mar 2023 04:54:33 -0800 (PST) In-Reply-To: (Alan Donovan's message of "Fri, 10 Mar 2023 10:40:01 -0500") 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:257790 Archived-At: Hello Alan! > Apologies, that patch contained debugging stuff. Please use this one: No problem. Moderation in this bug tracker took a little bit longer than usual, so this follow up message created a new bug (62116). I've closed the other one (62115). I think future bug reports by you won't suffer from the same problem. >> This patch can be applied to the base commit of 8ee205d. Please let me >> know if you'd like it in some other form. This form is fine. Comments below. > diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el > index 2f8d2002cd3..fb0c5cb1199 100644 > --- a/lisp/progmodes/eglot.el > +++ b/lisp/progmodes/eglot.el > @@ -819,6 +819,7 @@ treated as in `eglot--dbind'." > [,@(mapcar > #'car eglot--tag-faces)]))) > :general (list :positionEncodings ["utf-32" "utf-8" "utf-16"= ]) > + :window '(:showDocument (:support t)) > :experimental eglot--{}))) >=20=20 > (cl-defgeneric eglot-workspace-folders (server) > @@ -2143,6 +2144,44 @@ COMMAND is a symbol naming the command." > (_server (_method (eql window/logMessage)) &key _type _message) > "Handle notification window/logMessage.") ;; noop, use events buffer >=20=20 > +(cl-defmethod eglot-handle-request > + (_server (_method (eql window/showDocument)) &key uri external takeFoc= us selection > + &allow-other-keys) > + "Handle a window/showDocument server->client request by opening the > +URL in a browser or within Emacs." > + ;; Note: browse-url on a "file:" URL will execute open(1) or xdg-open(= 1), > + ;; which may end up opening the file in Emacs (or some other editor th= at > + ;; has registered the *.go extension), ignoring the optional selection. Not fully correct, as browse-url may well open things within Emacs own web browser, eww. I propose you leave just the next line. > + ;; Typically servers send "External: false" for files. In your experience, do servers differentiate between files inside the LSP "workspace" (in Emacs' parlance, the project) and outside it? A file visited by find-file inside the project becomes "managed" by Eglot+server, where a file outside the project becomes just a buffer (that could be managed by a different server). Not saying this is a problem, just interested in how this is used in the wild. > + (if (and external (not (eq external :json-false))) > + (browse-url uri) > + ;; Don't call find-file immediately (within the RPC handler) since > + ;; find-file's go-mode hooks issue more LSP RPCs (e.g. > + ;; textDocument/documentSymbol) from within this one, which then > + ;; gets stuck. (Is that a bug in gopls?) > + ;; So, make the call asynchronously from the idle loop. > + ;; Of course this means we can't respond with the proper success val= ue. Yep, I don't like this, and that's only one of the reasons. I'd only do this if there is no better alternative, and I don't think we've exhausted them yet (even then, you probably want simply 'run-with-timer'). First, I've made some changes to Eglot's usage of find-file-hook recently, and I'd like to ensure you're running the latest eglot from Emacs 29 or Emacs master (there are some pretest binaries for the latter, I think). Then I would ask you to try to find a backtrace of that 'textDocument/documentSymbol call that presumably Eglot sends immediately after visiting the file. Maybe the problem can be fixed there or thereabouts. One way to obtain that backtrace might be to do: (unwind-protect (progn (debug-on-entry 'jsonrpc-request) ;; synchronous find-file logic ) (cancel-debug-on-entry 'jsonrpc-request)) If you can, repeat the process with 'jsonrpc-notify instead of as well which will maybe produce a different backtrace. If it does, show that too. It's quite likely that the problem can be fixed upstream, so that a more naive implementation can work. > + (run-with-idle-timer 0 nil > + #'(lambda (filename noselect selection) Just some notes, since we're probably not going to use a lambda here. First #'(lambda (...) ) is redudant here. Also, since Emacs has lexical scoping (for about a decade now), you can have an argless lambda and access variables from the inside > + (with-current-buffer (if noselect > + (find-file-n= oselect filename) I don't think LSP's understanding of "focus" is the same as in 'find-file-noselect'. In Emacs, I would model it on the concept of selected window. IOW (funcall (if focus #'pop-to-buffer #'display-buffer) (find-file-noselect filename)) might be closer to what you want. But only testing can tell. > + (x-focus-frame= nil) This is going to be problematic for some users, I suspect. Let's leave it for now. What is the use case? An interactive app with a "find definition" interface? That's cool, the Common Lisp IDE's I use all have this. > + (find-file fil= ename)) > + (when selection > + (save-restriction > + (widen) You're saving the user's restriction, widening, then restoring it, but why? If the intended region is outside, it will have no effect, so perhaps just check that 'beg' and 'end' are between 'point-min' and 'point-max'. Alternatively, just nuke the user's restriction (you're moving lots of other stuff anyway). > + (pcase-let ((`(,beg . ,end) (eg= lot--range-region selection))) > + (if (equal beg end) > + (goto-char beg) > + (goto-char end) > + (set-mark-command nil) > + (goto-char beg)) > + (recenter)))))) If you can show me how, I'd like to test this myself. i have gopls installed, and a minimal toolchain, but I'm missing a project where I can exercise this (and probably I'm also missing the mandatory "server configuration" options). So a simple recipe with the smallest project possible would be nice. We're probably also going to need some user-confirmation UI for this. But that can come later. Jo=C3=A3o