Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: jporterbugs@gmail.com, arash@gnu.org, emacs-devel@gnu.org,
>> joaotavora@gmail.com
>> Date: Wed, 16 Nov 2022 13:05:46 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > (defvar eglot-server-programs `((rust-mode . ,(eglot-alternatives
>> > '("rust-analyzer" "rls")))
>> > (cmake-mode . ("cmake-language-server"))
>> > (vimrc-mode . ("vim-language-server"
>> > "--stdio"))
>> > (python-mode
>> > . ,(eglot-alternatives
>> > '("pylsp" "pyls" ("pyright-langserver"
>> > "--stdio") "jedi-language-server")))
>> > ((js-json-mode json-mode) .
>> > ,(eglot-alternatives '(("vscode-json-language-server" "--stdio")
>> > ("json-languageserver" "--stdio"))))
>> >
>> > Here we have:
>> >
>> > . a multi-level list
>> > . elements that are alists
>> > . a "backquote construct" with evaluated parts in
>> >
>> > How much Lisp do we require a user to know? Imagine a user who just
>> > wants to add one more server, either for an existing mode or for a new
>> > mode not in the list. Do we really expect him or her to understand
>> > all that?
>>
>> For a simple modification, it appears that
>>
>> (add-to-list 'eglot-server-programs '(foo-mode "foo-lsp" "--stdio"))
>>
>> is enough.
>
> And we expect a random user to know this how?
I believe it to be no more or less reasonable to know than how to
manipulate `auto-mode-alist', and that involves Elisp regular
expressions.
If something like this is mentioned in the manual, I think that should
suffice for a "learning-by-template" approach, which is my impression of
how most people use Emacs.
>> >> > Alternatively, it requires adding infrastructure to Custom to make
>> >> > these aspects safer and more easily understandable (something I'm not
>> >> > even sure is feasible).
>> >>
>> >> Like `setopt' does with primitive type checking?
>> >
>> > Yes, but much more complex. Essentially, display the above list in a
>> > form that is easy to understand, and allow updating it in that form.
>>
>> I agree that that would be a good thing to have, but that appears to be
>> something that would require reworking the widget framework, right?
>
> Probably. Which is why I think my original proposal, not to ask users
> to customize such variables directly, is much easier to implement.
I don't think that either or differs too much in difficulty, this is
more a question of approach.
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