Stefan Monnier <monnier@iro.umontreal.ca> writes: >> 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. > > I have 4 uses of it in my ~75kB init file. Heh, I have it in almost every one of my ~75-750 small elisp files, each one more or less dedicated to configuring a package that I may or may not use for 7500 years. > That doesn't mean we have to find a way to avoid its use, just that it > would be nice to find such a way. I think with-eval-after-load sits nicely at the intersection of lazy autoloads and user Elisp snippets. Is there another tool that does this? use-package, maybe? But won't that use the same thing underneath? Anyway I tend to prefer things that do one thing well and don't make me learn new DSLs. with-eval-after-load hasn't let me down. > "Choose an LSP server" seems to me like a very poor way to customize the > behavior of the server. > > IOW the design of the LSP protocol is not "Emacs-y" enough :-) Ah. Yes. You're probably right about that, how could you not be ;-) ? I also think it's more about these servers using different backend strategies themselves. Last I looked at the C++ server landscape, all of them provided more or less the same, but consuming different amount resources. There's also lots of forking going on. I think this is good. >>> 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'm just suggesting directions. I don't claim they're the right answer. > My impression is that this variable is currently both "too complex" and > "not flexible enough". Don't get me wrong, it's good enough for now. > > But no, I don't have a good replacement to suggest. My gut just tells > me that there is a better arrangement. It's not a very pretty variable, I admit, but it's good enough for now and could be a lot worse :-) I once thought it would be a good idea to have a buffer-local variable eglot-server-program (singular) that major-modes could set as a stronger suggestion of what to use. So a future smc++-mode could be based entirely on tree-sitter for syntax-highlighting and some good C++ server for everything else, including some LSP-backed smc++-frob-kittens command that isn't in eglot.el. The "good C++ server" would be set in eglot-server-program, called from smc++-mode. Maybe that "good server" would even be bundled with the smc++-mode package so that M-x smc++-mode would probably start Eglot by default. Can you ask your gut if this is an acceptable arrangement? João
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