From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#58790: Eglot URI parsing bug when using clojure-lsp server Date: Wed, 16 Nov 2022 16:45:04 +0100 Message-ID: <87a64qykcf.fsf@gmx.de> References: <87r0yrwfn3.fsf@gmail.com> <37716e41-5955-99f6-5204-e760a716fbf6@yandex.ru> <9bb290c8-f000-31d8-265d-b5441c33eb38@dfreeman.email> <4d50b820-7053-75eb-5b11-d3d36a02b013@dfreeman.email> <87v8nxsrq6.fsf@gmail.com> <87cza40xgs.fsf@dfreeman.email> <83edubrvf0.fsf@gnu.org> <87cz9v9irh.fsf@gmail.com> <83o7terf9a.fsf@gnu.org> <87k042tqze.fsf@dfreeman.email> <87fseqtpiu.fsf@dfreeman.email> <875yfm8lzf.fsf@gmail.com> <83wn82osoo.fsf@gnu.org> <871qq8xfzr.fsf@gmx.de> <87mt8uwo2q.fsf@dfreeman.email> <87zgcs6nvb.fsf@gmx.de> <87r0y3luad.fsf@dfreeman.email> <87iljf72ua.fsf@gmx.de> 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="2059"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: felician.nemeth@gmail.com, Danny Freeman , 58790@debbugs.gnu.org, stefankangas@gmail.com, dgutov@yandex.ru, Eli Zaretskii To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 16 16:46:18 2022 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 1ovKcA-0000It-71 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Nov 2022 16:46:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovKc1-0001hx-1o; Wed, 16 Nov 2022 10:46:05 -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 1ovKbz-0001e6-A9 for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2022 10:46:03 -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 1ovKby-0008B6-Vu for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2022 10:46:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ovKby-0006DW-Cb for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2022 10:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Nov 2022 15:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58790 X-GNU-PR-Package: emacs Original-Received: via spool by 58790-submit@debbugs.gnu.org id=B58790.166861351918879 (code B ref 58790); Wed, 16 Nov 2022 15:46:02 +0000 Original-Received: (at 58790) by debbugs.gnu.org; 16 Nov 2022 15:45:19 +0000 Original-Received: from localhost ([127.0.0.1]:57903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovKbG-0004tB-LM for submit@debbugs.gnu.org; Wed, 16 Nov 2022 10:45:19 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:46505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovKbB-0004II-QS for 58790@debbugs.gnu.org; Wed, 16 Nov 2022 10:45:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1668613506; bh=9J5mHM2z2QNn4ZunBqxnoVgbWpTC5G6eRjYNFtJMLto=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=M8HrZAz9CEVfHyh2WdD213PI9xdFQyk3+RloESytMcjoSLNVKCUPM/GYLBsOSifiu OZs6TzGDf54kkPyFAaSiaGM71vu3HTfml4fjcMc4Hv1spSn6+pPS1dpCPf/451RgLM FVO018vXwhWMES7XoxzM5DxOChxuDIfT8o9z/wiNJTyefvz5EsfSnb7DvqsibKObms qP1AtQms1Wcs7rMJHeGnysP4/8HUYnNmgqLeBRK1/KxrtAipi7VqevN8aM7gmUUY3V GXdpEal9CYJOQR0elYLOqcgXtaR2q4k2BrgTXq5dL6c/EMjn7kQFjMP56tAGdfczTu iOe32KElaSnVw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from gandalf.gmx.de ([185.89.39.6]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MS3mz-1oXWMT09YB-00TQjs; Wed, 16 Nov 2022 16:45:06 +0100 In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 16 Nov 2022 10:21:34 +0000") X-Provags-ID: V03:K1:z045vpnip63UL4qPFY/66n6+OyYb5Qi1V96PbLUekPtDrcJz4ZT 9hnLMvRBvf+hzHnrISZtx34nkksCFXIb27vojZ4GF68v7a+LsiT7ve0LDPC7BSwfmURQ8Ly 0r+6/xLfzV37wDNfLFO0uIeESAGnwu5nH8mbW5XJ9jEHZWZXF95KLUuCGOXh7LWfI6DmNwo rYukRIXnMZ/58ZnS5M6lA== UI-OutboundReport: notjunk:1;M01:P0:gYjLXp9i9gE=;QW4CQS+nfgiwhUBH90jq3dO1cKs XmhfaVzVmaQICwZHIR2julN+o05YVLbw9j5WBNxzkfoGQ34XpBbmD6fCjazhTDe9qxkzf2/aD 5SG+G3wlAKO05c4QltlV7pM4/LvwjtEOjDT3Mzy1IdP60YjU/KW3auXjgSRAYRW1CFJca0wN9 0iA2Qx9mxCkmKercjnmEKNGF5d49/DjbXtkSAhm2K5GVvr+0fFLt7lW2j8KrmmGa/+tdc2x+z 8KYmBUzNFMtFjtxGlu7A52FHwNJJk5LXXpYnRunt6a7kBEVKjXryZHS/CGXlY6YerrOAwqCTJ d3oLcDg0Ilp+TfKBtcvNFW6rDIK/vyf6S6rhgrSZOm45Cv9+BaHH5arRBNrRiQoN2xspN91kF 9Ai1k9TRDGdI4w8Ih9Olz7ShKDC7oBk7pNbxxiPTHWQHZIMY2qluqcuCodAosurQPZc4OHhqr uFV5rfWgCcrOAITkW/21Mm9tkOwRjms7exD6ljUxG810FV93xEE5tLs9FLQygX8Zrtnj4Q38a xNTqB9L+XRc89B5lswDlbJek3YoFNvOV9NnUGlqD4mFMtmqhwwSIOrDESvDvOax8m9fwbfsBt Ae1CE1SWy318wD7jcjzMfizSUEUYB/vUVKAIGBGDuIYFxtRe8yyBjodw0v/WXRZHzYyqF4Xot KGEdruH5LN2zVaoH0pZspgINC3eNvNepbCEmeCGn83Xxejzx1Fss4TFBIaH4OusN7yHZ+mY0x egLm1MCD5uZkOLP+tMeD/G22j12SlSIbk6A5d5xERDGzZcdpx+BU64s9UTj+ID6QQAcXXOE6 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:248023 Archived-At: Jo=C3=A3o T=C3=A1vora writes: Hi Jo=C3=A3o, I must admit that I don't use eglot (except some basic tests to understand how it works), so my comments might be not accurate. > * Eglot catches `file://` URI references coming from the LSP server > and converts those -- and only those -- to file names. It uses=20 > url-generic-parse for this. The function eglot--uri-to-path handles > a few more quirks but is not extraordinarily complex (about 15LOC). > > * Eglot converts file names to URIs when it needs to tell the LSP > about the files it is managing. Here, too, conversion only happens > if the PATH argument is not already an URI, in which case nothing > happens. > > * This logic is fairly simple. Do you see anything to simplify in it, > Michael? Both seem to be OK, although I'm not sure that it is the right approach in eglot--path-to-uri just to concat "file://" and the file-local-name part of a remote file name. > Can `url-handlers` simplify the functions `eglot--uri-to-path` and=20 > `eglot--path-to-uri`? url-handlers do not convert between the different syntaxes. It is just a package to implement a file name handler for URIs. > * I didn't mention that sometimes the "file names" are actually > "trampish" > file names, depending on whether the M-x eglot command was invoked=20 > in file being visited remotely by the TRAMP facility. > > * The only thing that's outstanding in the discussion, as I follow it, > is that someone suggested that Eglot **warn the user** when the LSP > server communicates to us (Eglot) a URI scheme that is not known > by the current Emacs session, and as such `find-file` on it will > fail. Yes, I understand it. But I don't understand why it is needed: if a URI scheme is not supported, there will be an error, visible to the user. No need to apply a check before, I believe. But I haven't read the whole bug report, so I don't know why this check is in place. > * This is (or was) what Danny is asking for: A simple, robust way, for > Eglot > code to ask the current Emacs session if this URI scheme is > supported > downstream, and warn the user preemptively.=20=20 > > * If there's no excellent way to do the above, I think the code > shouldn't > be changed. The user will eventually be confronted with the > failure, > and once could argue that this moment is when she should be made > aware of the URI scheme that doesn't have a handler. Hmm, yes. All what I have commented about is the fact, that other schemes but file:// could be handled by url-handlers. And if there is a scheme not supported yet, it could be added. It would be great if I could see a real use case of a URI not starting with the file:// scheme. In that case I could try to debug and understand what happens. Do you (or Danny) have a recipe I could follow? > Jo=C3=A3o Best regards, Michael.