> From: Philip Kaludercic <philipk@posteo.net>
> Cc: jporterbugs@gmail.com, arash@gnu.org, emacs-devel@gnu.org,
> joaotavora@gmail.com
> Date: Tue, 15 Nov 2022 17:50:25 +0000
>
> > The problem is only with user options that have complex structures.
> > Letting users edit such data structures directly is wrought with
> > unnecessary risks, and requires users to understand very well the
> > semantics of the data structure and the effect of every change in it.
>
> Where do you draw the line to what is "complex" and what isn't?
Basically, anything that is not an atom is "complex" for this purpose,
in my book.
> `eglot-server-programs' is complex in the trivial sense that it is made
> up of multiple parts, but each entry is relatively independent, and
> pretending an element to the beginning of the list shouldn't involve any
> unexpected surprises.
Let's look at this from the user's POV, okay?
(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?
> > 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.
> FWIW I agree that user options shouldn't be too complicated, but knowing
> how to simplify a user option is an art in itself.
Yes, but IMO we should bite that bullet every time.
> > The proliferation of user options with complex values we have
> > currently in Emacs is a bad tendency that is at least in part due to
> > the fact that the developers have no problems dealing with such data
> > structures. IMNSHO, we don't think enough about our users when we
> > introduce such options.
>
> Again, I am uncertain what you mean by complex. Is `auto-mode-alist'
> complex?
To some extent, yes.
> Or `display-buffer-alist'?
Definitely!
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