emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philip Kaludercic
Subject: Re: Making `eglot-server-programs' a custom variable?
Date: Wed, 16 Nov 2022 17:05:22 +0000

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 14:12:39 +0000
>> 
>> >> >  . 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.
>
> I think this variable is way harder to grasp that auto-mode-alist.

This might just be familiarity speaking, (regexp . major-mode) vs
(major-mode . command-list) -- in the simple case, the case that most
users are interested in -- doesn't seem that big of a difference.

>> > 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.
>
> I think adding infrastructure to Custom widgets is much harder than
> writing a :set function which adds an element to the likes of
> eglot-server-programs.  But extensions of Custom in this direction
> will be most welcome, of course.

To clarify, my proposal wasn't to add additional infrastructure to
custom widgets, but to either extend add-to-list or add a similar
command that would defer itself until the package is loaded, to avoid
overriding a variable that has a default value.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]