bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58790: Eglot URI parsing bug when using clojure-lsp server


From: Michael Albinus
Subject: bug#58790: Eglot URI parsing bug when using clojure-lsp server
Date: Wed, 16 Nov 2022 16:45:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

João Távora <joaotavora@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]