From: "João Távora" <joaotavora@gmail.com>
To: Augusto Stoffel <arstoffel@gmail.com>
Cc: 61868@debbugs.gnu.org
Subject: bug#61868: 29.0.60; Eglot: setting "workspace" configurations should be easier
Date: Wed, 01 Mar 2023 02:02:00 +0000 [thread overview]
Message-ID: <87v8jlns9z.fsf@gmail.com> (raw)
In-Reply-To: <87sfepa5pz.fsf@gmail.com> (Augusto Stoffel's message of "Tue, 28 Feb 2023 21:35:20 +0100")
Augusto Stoffel <arstoffel@gmail.com> writes:
> I see this differently. Emacs doesn't have deeply nested namespaces for
> variables and user options. It's all pretty flat, so there is almost
> surely never going to be a variable that is nearly as tricky to set.
Oh but no :-) there are even scary DSLs in Emacs variables. See
project-kill-buffer-conditions for example. And customize-variable
groks it.
In effect you want something like customize-variable, but different UI
and with support for saving to .dir-locals.el. I sympathize with the
idea, I really do, for two distinct reasons:
* I agree learning about dir-locals.el and its relation to a project's
configuration is confusing for newcomers
* I personally get extremely confused, even intimidated, by the Custom
UI.
So if this UI appears elsewhere, like a separate package, Eglot can take
advantage. But I'm afraid I don't like the idea of starting this in
Eglot, so it's probably not going to happen as long as I am maintainer.
> [ Incidentally, when I suggested to allow such syntax:
>
> ((python-mode
> . ((eglot-workspace-configuration
> . (("pylsp.plugins.jedi_completion.include_params" . t)
> ("pylsp.plugins.jedi_completion.fuzzy" . t)
> ("pylsp.plugins.pylint.enabled" . :json-false))))))
>
> you said it was un-Lispy or something, but I really think it's rather
> the opposite. Emacs has flat names pretty much like the above. ]
It's indeed un-Lispy, but it's not very hard to write a helper function
to turn that into a plist, is it?
>> (defun eglot-edit-workspace-configuration () (interactive)
>> (find-file (expand-file-name ".dir-locals.el" (project-root (project-current)))))
>>
>> My bet is that that two-liner would go a long way.
>
> No, this is not enough. At the very least I need a history variable to
> look at the previous configurations. This feature has to be a thing on
> top of of `eglot-show-workspace-configuration'.
That idea is the best I can offer for now. You'd have undo for history,
which is not bad. And Git, since it's a file after all.
João
next prev parent reply other threads:[~2023-03-01 2:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 12:49 bug#61868: 29.0.60; Eglot: setting "workspace" configurations should be easier Augusto Stoffel
2023-02-28 19:33 ` João Távora
2023-02-28 20:35 ` Augusto Stoffel
2023-02-28 21:16 ` Augusto Stoffel
2023-03-01 2:02 ` João Távora [this message]
2023-03-01 7:39 ` Augusto Stoffel
2023-03-01 13:20 ` João Távora
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v8jlns9z.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=61868@debbugs.gnu.org \
--cc=arstoffel@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).