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

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

bug#61312: closed (Patch for eglot: scala LSP binary name)


From: GNU bug Tracking System
Subject: bug#61312: closed (Patch for eglot: scala LSP binary name)
Date: Thu, 09 Feb 2023 10:19:01 +0000

Your message dated Thu, 09 Feb 2023 12:18:12 +0200
with message-id <83bkm3m9az.fsf@gnu.org>
and subject line Re: bug#61312: Patch for eglot: scala LSP binary name
has caused the debbugs.gnu.org bug report #61312,
regarding Patch for eglot: scala LSP binary name
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
61312: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61312
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Patch for eglot: scala LSP binary name Date: Sun, 05 Feb 2023 21:15:48 +0000
Hello,

It seems that eglot expects the scala metals LSP server binary to be named 
`metals-emacs` instead of `metals`. The included patch fixes this behaviour. At 
least in the nix package manager the `metals` binary is simply call 'metals'. 
However if other package managers distribute an alias for the binary as 
'metals-emacs' as well we could instead do something like:
```
(scala-mode . ,(eglot-alternatives '("metals" "metals-emacs"))
```

Attachment: 0001-Patch-eglot-scala-LSP-server-binary-name.patch
Description: Text Data


--- End Message ---
--- Begin Message --- Subject: Re: bug#61312: Patch for eglot: scala LSP binary name Date: Thu, 09 Feb 2023 12:18:12 +0200
> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 6 Feb 2023 18:45:39 +0000
> Cc: skykanin <skykanin@proton.me>, 61312@debbugs.gnu.org
> 
> As usual, I defer this decision to you. I think it's reasonable to
> support both names, and I also think it's reasonable to stick to 
> just the one we think is most used or representative of the 
> program.
> 
> In this case, I think "metals-emacs" is a contradiction of LSP's
> stated goal, which is to have editor-agnostic servers. But I 
> don't know what the reasons were for doing this, I haven't
> investigated.
> 
> It would be even more reasonable, I think, if distributions 
> settled -- or mostly settled - on names for their binaries they 
> distribute, much like *nix toolchains do. Of course we do not 
> control that process, but maybe we could influence it instead
> of being constantly influenced by it.

Thanks, I went with supporting both names in Emacs 29.  I cannot see
any harm in supporting both, once "metals" is the first name to check.

With that, I'm closing this bug.


--- End Message ---

reply via email to

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