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#58790: Eglot URI parsing bug when using clojure-lsp server Date: Wed, 16 Nov 2022 10:21:34 +0000 Message-ID: References: <87ilk5xq01.fsf@gmail.com> <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: multipart/alternative; boundary="00000000000076e85805ed93d210" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25462"; mail-complaints-to="usenet@ciao.gmane.io" Cc: felician.nemeth@gmail.com, Danny Freeman , 58790@debbugs.gnu.org, stefankangas@gmail.com, dgutov@yandex.ru, Eli Zaretskii To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 16 11:21:25 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 1ovFXp-0006P5-NB for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Nov 2022 11:21:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovFXU-0006bE-D8; Wed, 16 Nov 2022 05:21: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 1ovFXS-0006ag-UE for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2022 05:21: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 1ovFXS-0006DS-Lv for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2022 05:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ovFXS-0001Ym-9i for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2022 05:21:02 -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: Wed, 16 Nov 2022 10:21: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.16685940395936 (code B ref 58790); Wed, 16 Nov 2022 10:21:02 +0000 Original-Received: (at 58790) by debbugs.gnu.org; 16 Nov 2022 10:20:39 +0000 Original-Received: from localhost ([127.0.0.1]:56190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovFX4-0001Xe-Kg for submit@debbugs.gnu.org; Wed, 16 Nov 2022 05:20:39 -0500 Original-Received: from mail-oa1-f50.google.com ([209.85.160.50]:33414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovFX2-0001XP-3j for 58790@debbugs.gnu.org; Wed, 16 Nov 2022 05:20:37 -0500 Original-Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-13bd2aea61bso19567232fac.0 for <58790@debbugs.gnu.org>; Wed, 16 Nov 2022 02:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RC2CzmCYDhDZBItRBCcTNOOqBiAMYMQaXxKroCp12iQ=; b=SeQxb7OYQBu1Bga5cirQN2ai4GnecM6ZirnPR6fIu43PD8At53p20KHtkVa/0vI2R8 bwTfzaLAQ8LzWEPktT1E9yu1I52Yaa3u6f64V07dSflSuJfIq9kDPh8GyObBrHfHoFIj kKWoYr8keeEyOVGpMHWo5kWW0DcXX4ff4ass/T220pIDM3PaNwDpyRrmpEYQgDep8zEi PN+i6bgwGTQqO7imVJ6uySjebuAoeu0tsPflyf+MeQiWYUoapU11l397iPfAgBlpjV91 qBsdxhc3F+TYMuLqEa7YOhwIvydUeZdNRqhwEUMbLyRhRfJ/FArXKjgtiLIRX0kAZqB6 AAyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=RC2CzmCYDhDZBItRBCcTNOOqBiAMYMQaXxKroCp12iQ=; b=tZXiy7mu1YA/WOLO9gA81Ph3B48PSOM8fFXnneWu0FK39KWmd5oOAWbM1MEH+ZzQkf SWOGz4gtKxUYOclsNhmIv15L3vKfIPHJjVTfenjA4CzxqoaCcSW7xh1AzpD5pqgkEKuf DbnmDCwo3Vgsxa976yimUUBqqSvRVOZT6FghP3zLqVTePZWeDo489fdnOAtAFiQzXmQt jxivIKS/ivC3gpAPHCKldFrKh2UqWjIR2PtBE2rxOuE0xAPYtzmfcGR+aPrU+Gy5i7TA XV4mI9VZnbjucs7oJKpu5cUqQE1IMpxw9Sx/3K082YG3kBLeuFXW/nTDYDuQXg5Tmc61 O7cA== X-Gm-Message-State: ANoB5pmvjQo6UcBD3jqmSouCh7a9DgNn3Qmpbzdc86SzLBlVsv8/RkRv BfcKBE6vNdFIA3ARTjbTgYKJbdmZlB0fLtnUy2s= X-Google-Smtp-Source: AA0mqf6XDI8M06qy4hNcXR97c+2/NMTnOdikYcvg+3ElH+5LxOi8D6mwL7G5UZt9KH4dnJbvHoWMqTXMN+qQCmi7NJw= X-Received: by 2002:a05:6870:b1a:b0:132:a103:ae22 with SMTP id lh26-20020a0568700b1a00b00132a103ae22mr1296507oab.215.1668594030535; Wed, 16 Nov 2022 02:20:30 -0800 (PST) In-Reply-To: <87iljf72ua.fsf@gmx.de> 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:248000 Archived-At: --00000000000076e85805ed93d210 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't want to derail de discussion, which seems interesting. I just want to make a few points: * Eglot catches `file://` URI references coming from the LSP server and converts those -- and only those -- to file names. It uses 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? Can `url-handlers` simplify the functions `eglot--uri-to-path` and `eglot--path-to-uri`? * I didn't mention that sometimes the "file names" are actually "trampish" file names, depending on whether the M-x eglot command was invoked 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. * This is (or was) what Danny is asking for: A simple, robust way, for Eglo= t code to ask the current Emacs session if this URI scheme is supported downstream, and warn the user preemptively. * 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. Jo=C3=A3o On Wed, Nov 16, 2022 at 7:53 AM Michael Albinus wrote: > Danny Freeman writes: > > Hi Danny, > > >> Another approach is to simply require url-handlers in eglot.el, when i= t > >> comes to handle a URI. It shall do what you want. > > > > That is a really interesting idea. I didn't know about the url-handlers > > package. I think we would want the user to turn on that mode themselves > > if they were expecting those types of URLs (http, ftp, etc). > > You could control this by a user option. > > > There are other URI schemes we have seen come through this function tha= t > > are outside the scope of the url-handlers package. The ones in this > > particular thread are `jar` and `zipfile` URIs. I've seen other obscure > > URIs as well that aren't really even standardized and only used by one > > particular LSP server. > > url-handlers.el supports already non-canonical schemes, see > `url-tramp-protocols'. We could add "jar" and "zipfile" to another user > option, `url-archive-protocols', and let tramp-archive.el do the job. > > The current restriction is, that tramp-archive.el works only on > GNU/Linux systems. When this is replaced by a native integration of > libarchive(3) into Emacs, it would work everywhere. > > Best regards, Michael. > --=20 Jo=C3=A3o T=C3=A1vora --00000000000076e85805ed93d210 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't want to derail de discussion, which seems= interesting.

I just want to make a few points:

* Eglot catches `file://` URI references coming from= the LSP server
=C2=A0 and converts those -- and only those -- to= file names.=C2=A0 It uses
=C2=A0 url-generic-parse for this= .=C2=A0 The function eglot--uri-to-path handles
=C2=A0 a few more= quirks but is not extraordinarily complex (about 15LOC).

* Eglot converts file names to URIs when it needs to tell the LSP
=C2=A0 about the files it is managing.=C2=A0 Here, too, conversion= only happens
=C2=A0 if the PATH argument is not already an URI, = in which case nothing happens.

* This logic is fai= rly simple.=C2=A0 Do you see anything to simplify in it, Michael?
=C2=A0 Can `url-handlers` simplify the functions `eglot--uri-to-path` and =
=C2=A0 `eglot--path-to-uri`?
=C2=A0
=
* I didn't mention that sometimes the "file names" are a= ctually "trampish"
=C2=A0 file names, depending on = whether the M-x eglot command was invoked
=C2=A0 in file bei= ng visited remotely by the TRAMP facility.

* The o= nly thing that's outstanding in the discussion, as I follow it,
=C2=A0 is that someone suggested that Eglot **warn the user** when = the LSP
=C2=A0 server communicates to us (Eglot) a URI scheme tha= t is not known
=C2=A0 by the current Emacs session, and as such `= find-file` on it will fail.

* This is (or was) wha= t Danny is asking for: A simple, robust way, for Eglot
=C2=A0 cod= e to ask the current Emacs session if this URI scheme is supported
=C2=A0 downstream, and warn the user preemptively.=C2=A0
<= br>
* If there's no excellent way to do the above, I think th= e code shouldn't
=C2=A0 be changed.=C2=A0 The user will event= ually be confronted with the failure,
=C2=A0 and once could argue= that this moment is when she should be made
=C2=A0 aware of the = URI scheme that doesn't have a handler.

Jo=C3= =A3o




On Wed, Nov 16, = 2022 at 7:53 AM Michael Albinus <michael.albinus@gmx.de> wrote:
Danny Freeman <danny@dfreeman.email> writes:=

Hi Danny,

>> Another approach is to simply require url-handlers in eglot.el, wh= en it
>> comes to handle a URI. It shall do what you want.
>
> That is a really interesting idea. I didn't know about the url-han= dlers
> package. I think we would want the user to turn on that mode themselve= s
> if they were expecting those types of URLs (http, ftp, etc).

You could control this by a user option.

> There are other URI schemes we have seen come through this function th= at
> are outside the scope of the url-handlers package. The ones in this > particular thread are `jar` and `zipfile` URIs. I've seen other ob= scure
> URIs as well that aren't really even standardized and only used by= one
> particular LSP server.

url-handlers.el supports already non-canonical schemes, see
`url-tramp-protocols'. We could add "jar" and "zipfile&q= uot; to another user
option, `url-archive-protocols', and let tramp-archive.el do the job.
The current restriction is, that tramp-archive.el works only on
GNU/Linux systems. When this is replaced by a native integration of
libarchive(3) into Emacs, it would work everywhere.

Best regards, Michael.


--
Jo=C3=A3o T=C3=A1vora
--00000000000076e85805ed93d210--