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

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 58790 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>, Danny Freeman <danny <at> dfreeman.email>
Subject: bug#58790: Eglot URI parsing bug when using clojure-lsp server
Date: Sat, 29 Oct 2022 03:02:56 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> We don't provide a setter for 'project-root', so I don't understand
> the expectation of being able to modify project-external-roots for an
> arbitrary project type either.

I think I understand your confusion.  I'm not suggesting that Eglot
modifies it.  I'll explain better below.

>>> Dmitry: Or create an Eglot-specific project backend.
>> I don't understand this suggestion either.  Normally Eglot is a
>> client
>> of project information maintained by other project.el backends.  Very
>> commonly VC projects, but not always necessarily so.  That clashes with
>> the idea of making Eglot simultaneously a supplier of this information.
>
> There is indeed certain tension, but if Eglot wants to decide stuff
> about the project (which, as I said in the past, could be a reasonable
> idea), then it could provide its own project backend. We're not
> necessarily at that point, though, because...

Eglot doesn't want to decide anything about project. Eglot justs wants
to go into user visible projects and answer the question:
(project-current).  It wants this because it maps project/major-mode
pairs to server connections. 

Eglot doesn't care if the project is of type 'vc, 'transient,
'visual-studio-solution-file, 'joes-complicated-project, etc.  

So Eglot providing a project backend doesn't make sense.  Maybe you
think I'm suggesting that Eglot that could collect these references to
jars coming from the LSP server and add them to project-external-roots
somehow.  I'm not suggesting that.  

It's just that an arbitrary project backend, other than 'vc or
'transient, could add a method to project-external-roots.  That would be
the user's job.  I suppose Clojure packages declare somewhere which jars
they use.  They probably store this information in a file.  Java used
some ghastly .xml Ant file or Maven or whatever.  A specialized project
backend could read the file and use it in an implementation of
project-external-roots.  At this this is how I interpret project.el's
CLOS-like protocol for defining new project backends.

>> Please read the summary of the outlined above.  Maybe there's nothing to
>> be done in project.el if eglot-extend-to-xref is to be used.
>
> ...indeed you could stop at that.

Maybe.  eglot-extend-to-xref works very well for non-jars, at least for
C++ and clangd.  Subsequent M-. work very well, too.

The downside is that once a system file discovered by the LSP server, it
is associated with a given server (_not project_) in Eglot.  I don't
know what happens if another server also points to the same file.
Probably nothing very bad, but there may be some suprising behavior: I
haven't tested.

> Having the jars in project-external-roots could enable the users
> (after certain integration work) to search across their contents with
> project-or-external-find-regexp, or jump to files inside with
> project-or-external-find-file.

That's a very nice point.  I don't use Java fortunately, but when I did
a long time ago, I think I remember Eclipse let me do this.

> But as for xref-find-definitions, item 4 in your list should be enough
> (with either of the alternatives as underlying implementation).

Let's see what Danny says.

João

Previous Next

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