bug#70036: a fix that

[Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

> On Fri, Apr 19, 2024 at 7:14 PM Theodor Thornhill <theo@thornhill.no> wrote:
>>
>> João Távora <joaotavora@gmail.com> writes:
>>
>> Open main.go in emacs and M-x eglot. Observe error:
>> ```
>> compiler [DuplicateDecl]: main redeclared in this block (this error: other declaration of main)
>> ```
>
> Reproduced, but that's not Eglot's fault, couldn't be.  Eglot told
> gopls _nothing_  about mainlink.go.  Check your events buffer!  No
> didOpen for mainlink.go! In fact you probably don't even need to didOpen
> any file for that  problem to be reported as a project-wide diagnostic.
> A simple  initialize will do, I bet.  IOW, you barely need a client.
> Gopls decided to do some out-of-band  (meaning out-of-LSP) analysis
> of the code, bumped into its own  ignorance (or policy, who knows?)
> re. symlinks, and decided to  issue diagnostics.  Seems something a
> Go compiler would do.  Maybe it does?  Are symlinks even supported in
> Go projects?
>
> Bottom line is Eglot wasn't ever the hindrance for this to work and it
> should not suddenly become one. Not without a very good reason, which
> this performance matter clearly isn't (not least because there are lots
> of alternative solutions as we've seen)
>

Sure. I think it locates this file from the globbing in file
watchers. Because it matches a pattern it is allowed to read it. But
it's not important, mostly an example of how symlinks and lsps are
difficult.

As another point of reference, lsp-mode behaves the same as Eglot.

Theo