GNU bug report logs - #58790
Eglot URI parsing bug when using clojure-lsp server

Previous Next

Full log

Message #125 received at 58790 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: felician.nemeth <at> gmail.com, Danny Freeman <danny <at> dfreeman.email>,
 58790 <at> debbugs.gnu.org, stefankangas <at> gmail.com, dgutov <at> yandex.ru,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#58790: Eglot URI parsing bug when using clojure-lsp server
Date: Wed, 16 Nov 2022 10:21:34 +0000

[Message part 1 (text/plain, inline)]

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 Eglot
  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ão




On Wed, Nov 16, 2022 at 7:53 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:

> Danny Freeman <danny <at> dfreeman.email> writes:
>
> Hi Danny,
>
> >> Another approach is to simply require url-handlers in eglot.el, when 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-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 that
> > 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.
>


-- 
João Távora

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.