Avoiding invoking "error" in eglot-alternatives

[shipmints]

I'm using eglot 1.17 and I see the code is the same in the latest git.

When habitually running Emacs with debug-on-error enabled and loading a buffer that enables eglot but in a directory tree that has no lsp support, eglot-alternatives calls error, vs. just a warning, that no lsp support is available and is pretty jarring. Due to the differences in Emacs runtime behavior between the interpreter and byte compiler, it is not possible to advise eglot-alternatives with either (let ((debug-on-error)) or (with-demoted-errors to avoid error.

Would you consider an option to report lack of lsp support without invoking error?

Thank you.

[joaotavora]

debug-on-error is for debugging Elisp (either for developers or users debugging an error). My opinion is that you shouldn't "habitually" run Emacs with it on. My opinion is also that you shouldn't spam eglot-ensure everywhere - which I suspect you do: as the manually states, you should reserve it for hooks where you can be quite sure M-x eglot would succeed.

Due to the differences in Emacs runtime behavior between the interpreter and byte compiler, it is not possible to advise eglot-alternatives with either (let ((debug-on-error)) or (with-demoted-errors to avoid error.

No, the "differences" make absolutely no difference here, you're just advising the wrong function. eglot-alternatives is a higher order function: it returns a function. You shouldn't be advising eglot-alternatives , you should be advising its return value.

[shipmints]

Thank you for your thoughts, Joao. While I'm not a core Emacs developer, I am working on Emacs packages and it is exceptionally helpful to have debug-on-error enabled. I believe I am using eglot-ensure as intended, in this case in a python-mode-hook, during which I cannot tell in advance if sufficient lsp support infrastructure is present. I could alter the hook and disable debug around the eglot-ensure call this is easier than advising the function returned by eglot-alternatives. [I just realized this won't work so need to figure out how to wrap alternatives return functions.]

I asked the original question partially motivated by not understanding general Emacs package error policy. I tried to find formal guidance on errors vs. warnings or mere messages but was unable to. A user can still successfully edit a buffer where eglot could not successfully start and an error vs. an advisory message was an option that seemed potentially appropriate.

Thanks, again, for your software and your direct engagement.

Follow up:

I wound up advising eglot--guess-contact to disable debug-on-error and it's fine for now. I did realize that byte compiled in this case wouldn't be the issue as it is for byte code singletons like upcase.

[joaotavora]

While I'm not a core Emacs developer, I am working on Emacs packages and it is exceptionally helpful to have debug-on-error enabled

Yes, it's useful when developing Elisp. But when developing Elisp you're probably not using Eglot. At least I'm not, except when hacking on Eglot itself. This is just my opinion of course. Errors happen all the time and all of them are caught at top level and I don't let them interfere with my work.

in this case in a python-mode-hook, during which I cannot tell in advance if sufficient lsp support infrastructure is present.

Then, in my honest opinion, you shouldn't be using eglot-ensure in a mode hook, because it will attempt to invoke a language server program and start communicating with it every time you open a file of a given type file, which could have unintended consequences, the least of which is getting an error. More sever consequences involve inadvertently starting a language server in a very large project (or something that Emacs thinks is a very large project), and answering very taxing server requests about that project. That could hang your Emacs. Presumably, the language server you're using doesn't do this: great. But that doesn't make eglot-ensure a good idea.

I asked the original question partially motivated by not understanding general Emacs package error policy. I tried to find formal guidance on errors vs. warnings or mere messages but was unable to. A user can still successfully edit a buffer where eglot could not successfully start and an error vs. an advisory message was an option that seemed potentially appropriate.

An error is just a condition that says some Elisp function couldn't do the job with what it was given. That's it. When it bubbles up to the top, you can choose to briefly see it or start a debugger to understand whence the error came (in more advanced Lisps you can change the conditions and invoke so-called restarts, interactively or autoamtically). You choose to always start a debugger. I think that's a mistake, but who am i to tell you what to do :-)

[shipmints]

It's pretty hard to avoid eglot when working on holistic programming mode work while needing to check for errors...

So far, eglot has been reliable, and the automation afforded by calling eglot-ensure in language-mode hooks gets Emacs into the realm of "IDE" for me and the people around me who share my Emacs config. We almost always work on several projects simultaneously and eglot works well in a complex automated work flow. My config work aims to avoid unintended consequences as best I can. (In the Python world, we're looking forward to ruff's LSP efforts to help performance.)

I might consider adding an option to allow my config users to manually start eglot if things prove to be troublesome in some way (in fact, I'll do that right now).

I did an informal survey of other people's eglot-ensure usage in their prog-mode hooks and it seems like an almost universal pattern.

Thanks, again, João.

[joaotavora]

It's pretty hard to avoid eglot when working on holistic programming mode work while needing to check for errors...

"holistic mode"? Is this an Elisp project? if is, there's no Eglot for Elisp, I'm afraid. If it isn't, why do you need to know about the details of Elisp errors?

I did an informal survey of other people's eglot-ensure usage in their prog-mode hooks and it seems like an almost universal pattern.

yeah there's little I can do little against ignorant ChatGPT suggestions of it... I'm always suprised about the number of people that don't know that M-x eglot is also a one time per session & project thing. You don't need to retype it for each file you open in the same project.

[shipmints]

Holistic as stuff I'm working on is integrated automation that needs to work smoothly across prog-modes, eglot, custom elisp, third-party packages. The recent evolution of native Emacs tooling is quite welcome but still evolutionary and with sufficient rough edges that need tender loving care. I will contribute more to Emacs as we go. I've already been submitting fixes to core (not yet hardcore).

I feel for you having embarked on eglot with the widely varying reliability of lsp servers and way more widely varying user experience and skill. My own elisp skill has become decent but not (yet? ever?) amazing. My engineering skill, in general, is likely expert and that saves me and makes me quite in demand among my crew. Hence my volunteer effort to craft and hone our tools. I can't even express how much I disdain the javascript world and want to stay far away from VSCode and Node and all that. JS is the new BASIC. It is inevitable, though. Up next this week or next is Emacs tooling work for the "web world." Deep breath.