GNU bug report logs -
#58790
Eglot URI parsing bug when using clojure-lsp server
Previous Next
Full log
Message #29 received at 58790 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Yes, i think that makes sense. Can't look at that pull request right now,
but my current thinking is to leave the URI unprocessed if the scheme is
anything other than file://.
Then file-name-handler-alist can decide what to do with it.
But warning the user on such occasions sounds a bit too noisy. Maybe a
one-time warning.
The only other thing to watch out for is that wherever find-file lands is,
its buffer-file-name should probably be left with the unchanged URI, so
that eglot--path-to-uri can return it and tell the LSP server that we're
now managing the buffer using the original URI.
João
On Sat, Oct 29, 2022, 16:36 Felician Nemeth <felician.nemeth <at> gmail.com>
wrote:
> > The problem occurs when using `xref-find-defintions` while eglot is
> > managing a clojure buffer with clojure-lsp. If the symbol that
> > xref-find-definitions is activated on is defined in a jar file,
> > clojure-lsp by default will provide a location with a response like
> > the following
> >
> > (:jsonrpc "2.0" :id 14 :result
> > (:uri
> >
> "zipfile:///Users/andreperictavares/.m2/repository/org/clojure/tools.namespace/0.3.1/tools.namespace-0.3.1.jar::clojure/tools/namespace/find.clj"
> > ... ))
> >
>
> Can you, please, consider merging something like github#854?
> https://github.com/joaotavora/eglot/pull/854
>
> Currently, Eglot assumes that the uri-scheme is always "file". I think
> Eglot should at least warn the user if this assumption is false instead
> of silently failing as it currently does.
>
> Thanks.
>
[Message part 2 (text/html, inline)]
This bug report was last modified 2 years and 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.