Re: Eglot tests fail on emba

Hi Michael,

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).

Until then, consider that Eglot has worked problem-free with file
notifications for many major versions, so this is very clearly a breakage
introduced subtly by your changes to filenotify.el.

So my advice is to bisect that change "from the inside" while you're still
familiar with it and it's in your mental cache.

IOW try to understand exactly what seemingly innocent detail you changed
that made Eglot usage break, by disabling parts of the change, recompiling
and re-testing.

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?

João

On Mon, Aug 24, 2026, 15:24 Michael Albinus <[email protected]> wrote:

> João Távora <[email protected]> writes:
>
> > Hi Michael,
>
> Hi João,
>
> > I'm sure it's related to the problem you saw, because if you bisect with
> > this other canary:
> >
> >    make && make -C test eglot-tests SELECTOR='"rust"'
> >
> > it blames that very same commit 07925d7070 of yours and with what seems
> > to be 100% the same problem you get on EMBA.  This test needs
> > rust-analyzer, presumably already installed on those machines.
>
> I ran the eglot tests in the emba containers for emacs-31 and master. As
> selector, I've taken eglot-test-rust-on-type-formatting. For the test
> runs, I've enabled file notification debug messages.
>
> The resulting eglot-tests.log files are filtered by occur with the
> regexp '^file-notify-\(add\|rm\|handle\)'. I append both filtered log
> files as occur.31 and occur.32.
>
> Both event queues look very similar. In occur.31, some stopped events
> aren't traced due to a bug I've fixed with my last filenotify.el
> patch. I have also replaced your callback lambda with '...'.
>
> What's surprising is, that Eglot opens always two file notification
> watches for the same target. Like
>
> --8<---------------cut here---------------start------------->8---
>       8:file-notify-add-watch (1 . 0)
> "/tmp/eglot--fixture-OWy2ZN/on-type-formatting-project/" (change) ...
>      17:file-notify-add-watch (1 . 1)
> "/tmp/eglot--fixture-OWy2ZN/on-type-formatting-project/" (change) ...
> --8<---------------cut here---------------end--------------->8---
>
> Is this intended? I believe there is a logic twist in the code, one
> watch shall be sufficient.
>
> Otherwise, everything looks very the same until the end. *But* in
> occur.32, the very last action is
>
> --8<---------------cut here---------------start------------->8---
>     445:file-notify-handle-event (file-notify ((1 . 0) (create)
> ".#main.rs" 0) file-notify--callback-inotify)
> --8<---------------cut here---------------end--------------->8---
>
> Neither 'main.rs' nor '.#main.rs' is mentioned in occur.31. Where does
> this come from?
>
> > João
>
> Best regards, Michael.
>
>