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: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
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 17:54:23 +0300

On 29.10.2022 05:02, João Távora wrote:

> 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.

That was my impression, yes.

> 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.

Okay: some new project type. Or a new feature that parses build files. 
Or etc. All of that could be reasonable, but is yet for somebody to 
design and implement.

IMHO a feature that takes up the goal of providing comprehensive IDE 
support could take up that responsibility too. But I'm fine either way.

That would also depend on whether the LSP protocol is ever going to be 
extended toward providing build file information, running build tasks, etc.

>>> 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.

The dilemma of having external files associated with just the latest 
server seems unavoidable.

Of course you could collect the full list of servers which the external 
file "belongs to", and then flat_map the requests through them all. But 
it's probably not what the user expects most of the time.

>> 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.

Maybe it's covered by existing LSP functionality, though.

Previous Next

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