A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg00580.html below:

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

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 10 Nov 2022 10:15:41 +0000
> Cc: emacs-devel <emacs-devel@gnu.org>
>
> Arash, I think your suggestion of recommending `with-eval-after-load`
> is pertinent and should be added to the manual.

How about adding a command to add servers to the list instead?  See


below.

> Eli, even though we provide a healthy dose of built-in server invocations


> in that variable, we can't and shouldn't aim at being exhaustive.
>
> Eglot's manual is meant to be a go-to guide for knowing how to resolve
> simple problems such as this one, which is very common.  The problems
> solved by eglot-workspace-configuration and other variables are also
> very common. The manual should be reasonably self sufficient, not too
> terse or relying on the user's knowledge.

IMNSHO, it is not the mission of the Eglot manual to teach people


with-eval-after-load and in general how to update lists that aren't
autoloaded or preloaded.  This is a slippery slope.

I understand your opinion, and I share it mostly.  But this is not that slippery.

We also have short mentions in passing of directory-local variables because

they are essential to setting up eglot-workspace-configuration.  Short mentions

of Emacs's facilities and links to other documentation deepening those

concepts is the best strategy. I've used it in the README.md and MANUAL.md

that preceded this manual and I can attest that it worked well.

If making the variable autoloaded can make use skip the with-eval-after-load,

and has no other pitfalls, then I'm OK with that too.  Whatever works and

makes the manual self-sufficient in this very simple and common task.

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

A good docstring (can it  be improved?) containing good descriptions

and some ready-made recipes is the current and best approach to these

things.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4