From: Eli Zaretskii <eliz@gnu.org>
To: "Augusto Stoffel" <arstoffel@gmail.com>,
"João Távora" <joaotavora@gmail.com>
Cc: 58894@debbugs.gnu.org
Subject: bug#58894: Comments on Eglot manual
Date: Thu, 03 Nov 2022 15:51:51 +0200 [thread overview]
Message-ID: <83sfj06t8o.fsf@gnu.org> (raw)
In-Reply-To: <87a65dtvuw.fsf@gmail.com> (message from Augusto Stoffel on Sun, 30 Oct 2022 12:05:27 +0100)
> From: Augusto Stoffel <arstoffel@gmail.com>
> Date: Sun, 30 Oct 2022 12:05:27 +0100
>
> Find below some comments on the "Customizing Eglot" section of the manual:
>
> > [...] via the variable ‘eglot-workspace-configuration’. Eglot sends the
> > portion of the settings contained in this variable to each server for
> > which such settings were defined in the variable.
>
> This is not true. The entire `eglot-workspace-configuration' is sent to
> the server; presumably, severs ignore everything which is not under its
> own prefix, but that's just a convention.
>
> > JSON values ‘true’, ‘false’, ‘null’ and ‘{}’ are represented by the
> > Lisp values ‘t’, ‘:json-false’, ‘nil’, and ‘eglot-{}’, respectively.
>
> Unless something has been renamed recently, it's `eglot--{}', not
> `eglot-{}'.
>
> > Alternatively, the same configuration could be defined as follows:
> >
> > ((nil
> > . ((eglot-workspace-configuration
> > . (:pylsp (:plugins (:jedi_completion (:include_params t
> > :fuzzy t)
> > :pylint (:enabled :json-false)))
> > :gopls (:usePlaceholders t))))))
>
> This is more or less obvious, if you know how dir-local variables work.
> So I would suggest mentioning a different configuration method:
>
> Alternatively, you can set a default workspace configuration globally by
> adding the following to your init file:
>
> (setq-default
> eglot-workspace-configuration
> '(:pylsp (:plugins (:jedi_completion (:include_params t
> :fuzzy t)
> :pylint (:enabled :json-false)))
> :gopls (:usePlaceholders t))
>
>
>
> > This is an equivalent setup which sets the value for all the
> > major-modes inside the project; Eglot will use for each server only the
> > section of the parameters intended for that server.
>
> Again, this is not true. Rather, each sever will presumably ignore any
> settings not under its own "namespace".
João, any comments?
next prev parent reply other threads:[~2022-11-03 13:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-30 11:05 bug#58894: Comments on Eglot manual Augusto Stoffel
2022-11-03 13:51 ` Eli Zaretskii [this message]
2022-11-03 16:08 ` João Távora
2022-11-06 7:47 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83sfj06t8o.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=58894@debbugs.gnu.org \
--cc=arstoffel@gmail.com \
--cc=joaotavora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.