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

Previous Next

Full log

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: João Távora <joaotavora <at> gmail.com>
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 16:45:04 +0100

João Távora <joaotavora <at> gmail.com> writes:

Hi João,

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 
>   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 
>   `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 
>   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.  
>
> * 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ão

Best regards, Michael.

Previous Next

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