Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Arash, I think your suggestion of recommending `with-eval-after-load` >> is pertinent and should be added to the manual. > I don't have an objection to that but I consider uses of > `with-eval-after-load` as hints that maybe we should do things > differently. Why? This is in a user's init file. I can more or less see that argument for inter-library dependencies. But here, w-e-a-load is exactly what's needed. I use it all the time in my config. The reason people probably didn't need this earlier is because they were using Eglot from a package and were simply adding (require 'eglot) (add-to-list ...) Or they were doing that use-package magic, which probably does the same something similar to the require or the w-e-a-load strategy. > The suggestion to split the var in two (one plain var and a custom var > that defaults to nil) is such a possible solution. That would just break user's configurations and complicate things for no reason. add-to-list is the way to go, and with-eval-after-load (or use-package if you must) is just there for that. Composing existing pieces that do one job well is better than inventing and maintaining new pieces. >> Eli, even though we provide a healthy dose of built-in server invocations >> in that variable, we can't and shouldn't aim at being exhaustive. > Seeing the wild number of LSP servers available for some languages, I'd > agree, sadly. I don't think this is sad :-) > Maybe to reduce the problem we should allow multiple entries per > major mode and use the first that works, without needing to go through > `eglot-alternatives`? Again, why? Why add more semantics to an already complicated variable when the functional eglot-alternatives plugin works fine? Furthermore, I'd like to this particular configuration for a future multiple-simultaneous-server-in-one-mode idea. > [ I'll note in passing that it's common to use strings for TCP port > numbers, especially once they are standardized enough to appear in > /etc/services, so maybe the syntax for that TCP connection should > replace (HOST PORT ...) with something like (:tcp HOST PORT ...). ] If you can make that change without breaking backward compatibility, I have no objections.
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