bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running

[Philip Kaludercic <philipk@posteo.net>]

João Távora <joaotavora@gmail.com> writes:

> I haven't studied your code in depth, but it seems like you're giving
> `match-buffers/compiled` benchmark 10 times the work you're giving to
> the other function, which would explain why it's 10x slower.
>

You are absolutely right, I re-ran the tests the right way and got these
results:

--8<---------------cut here---------------start------------->8---
(benchmark-run 1000
  (match-buffers sample-condition))
;; => (25.052781603 265 16.678798381999997)

(benchmark-run 1000
  (match-buffers/compiled sample-condition))
;; (30.021295067 335 21.01291473699999)
--8<---------------cut here---------------end--------------->8---

> The byte-compiler (or the native compiler) can't really optimize the
> mini-language more magically.  It can only optimize elisp.

Of course, I don't get why it should?

> My idea of using the byte-compiler to do this is different: it entails
> translating the mini-language to elisp first and then byte-compiling
> that.  But it is a technique that I think your code isn't applying
> or at least not correctly (though I haven't read all of it: I will soon).

What I am doing is translating it into lambda expressions, but I could
also try out translating it into an s-expression and passing that to
`eval'...

> You can see eglot's "glob matching" section for the application of
> such a technique the "glob" minilanguage that is required by LSP (iow
> it wasn't "invented by me" ;-) )