Re: Eglot tests fail on emba

On Tue, Aug 25, 2026, 11:43 Michael Albinus <[email protected]> wrote:

> João Távora <[email protected]> writes:
>
> > Hi Michael,
>
> Hi João,
>
> > I'll not be in front of a laptop for about  two weeks, so you'll have
> > to debug this yourself or enlist others to help you. I suspect this
> > affects not only the tests but actual Eglot usage by whomever is
> > building Emacs from trunk, which IME is a non-negligible group of
> > people.
> >
> > Maybe Eglot does some less than optimal usage of file notification
> > watchers, and I'm happy to take a look at it when I come back and put
> > in a perfectly tested and safe backward-compatible patch to eglot.el
> > that works both with master and older Emacs < 32 down to Emacs 26.3.
> > If no one beats me to it if course (which unfortunately is unlikely
> > IME).
>
> Use of file notification itself doesn't seem to break eglot, as much as
> I understand. There are two questions:
>
> - Why does file notification speaks about creation of .#main.rs now?
>   This file wasn't mentioned before, and I don't understand where it
>   comes from.
>

I don't know. All I can say as I said before is that Eglot and its
immediate neighbors haven't changed.


> - Which process sentinel is it that the broken test speaks abouut?
>
> --8<---------------cut here---------------start------------->8---
> error in process sentinel: Process EGLOT
> (on-type-formatting-project/(rust-mode)) not running: finished
> --8<---------------cut here---------------end--------------->8---
>
>   file notification doesn't use processes.
>
> I have no idea where to get the answer, and I believe somebody with
> eglot knowledge should be involved.
>

As I said, I'm not with a laptop for two weeks.

> Then either fix Eglot (again, if you're confident and can give it some
> > testing somehow and it's backward compatible to older versions of
> > Emacs, as I explained above) or revert/fix that bit of your change
> > inside your commit. Is your change to filenotify.el urgent, or somehow
> > laying essential groundwork for other changes?
>
> I won't revert the change until I know what's up.
>

I think that's an irresponsible stance that unjustly holds hostage the
users of Emacs master. What would you say if I put something in that broke
TRAMP in some subtle way and refused to revert it until it my understanding
of the issue met some arbitrarily high bar?

You know you broke something. You don't know exactly what you broke, and
you definitely didn't do it on purpose. And that happens, it's a part of
dev life. Happens to me all the time. But it's pretty clear your actions,
not anyone else's, are responsible for this breakage. Act in accordance
with this established fact.

There is a much of high-minded talk in this list about strict backward
compatibility and how valuable it is and what it means, so let's act
accordingly.

So imo opinion it's fine to give it some time while you analyse, and to
enlist whoever you think can help (I can't as I've explained) but if you
find yourself blocked, I think the responsible thing to do is to put your
work to the side until you the reasons that led to this breakage are known.
I promise to help when I get back in September.

Also, have you tried my suggestion to micro-bisect your change, the commit
I pointed to, and which we know broke things? I think it could yield
insight!

João