emacs-devel
[Top][All Lists]
Advanced

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

Re: Making `eglot-server-programs' a custom variable?


From: João Távora
Subject: Re: Making `eglot-server-programs' a custom variable?
Date: Thu, 10 Nov 2022 15:38:32 +0000
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Thu, 10 Nov 2022 12:07:30 +0000
>> Cc: arash@gnu.org, theophilusx@gmail.com, emacs-devel@gnu.org
>> 
>>  > That said, I have no objection to converting eglot-server-programs into
>>  > a defcustom, if someone will commit to translating and maintaining all
>>  > the complex combination of options into "widget" form.  I don't have the 
>>  > time or inclination for this task, but maybe someone has.
>> 
>>  It is not a good idea to have a defcustom whose value should be such a
>>  complex data structure. 
>> 
>> I agree, but a command is a not a solution IMO: this belongs in the 
>> user's configuration file. 
>
> ??? The user init file can call the command, cannot it?

Yeah, but then why make it a command, i.e. an interactive function?  If
whatever you're proposing is going to be called interactively, it won't
persist through sessions.  So if you're proposing a simple function, I
think there's no need to for a function that simply calls add-to-list.

> And adding a command is not a replacement for having a variable:
> people who know enough Lisp can do what they want with the variable.
> The command is proposed as a replacement for a defcustom, because
> interactively customizing such a complex variable with a very long
> value is problematic at best.

Again I cannot see the point of a interactive command.  If you mean a
simple non-interactive function to be called from the user's init file,
I can't see much advantage of using that over using add-to-list, other
than auto-loading.  And auto-loading isn't necessarily an advantage: I
break out many Emacs sessions where I don't M-x eglot at all.
with-eval-after-load is the tool for the job here.

>> A good docstring (can it  be improved?) containing good descriptions 
>> and some ready-made recipes is the current and best approach to these 
>> things.
>
> Sorry, but I disagree.  No doc string can reasonably teach users
> advanced Lisp.  That's a non-starter.

Funny, that's how I learned all my Elisp until I learned of the Elisp
manual a few years ago.  And this is not "advanced" stuff at all.  This
is all that's needed:

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 204121045a0..a6df8371425 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -298,7 +298,10 @@ eglot-server-programs
   the call is interactive, the function can ask the user for
   hints on finding the required programs, etc.  Otherwise, it
   should not ask the user for any input, and return nil or signal
-  an error if it can't produce a valid CONTACT.")
+  an error if it can't produce a valid CONTACT.  This option can
+  be combined with the helper function
+  `eglot-alternatives' (which see) to define more than one
+  alternative server for a given MAJOR-MODE.")
 
 (defface eglot-highlight-symbol-face
   '((t (:inherit bold)))

Throwing in an example 3-line snippet in the manual for
eglot-alternatives is also fine:

(with-eval-after-load 'eglot
  (add-to-list 'eglot-server-programs
               `(foo-mode .
                  ,(eglot-alternatives '("fools" ("bazls" "--foo"))))))



reply via email to

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