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

["João Távora" <joaotavora@gmail.com>]

Philip Kaludercic <philipk@posteo.net> writes:

>> I couldn't figure out where this argument arise or who should provides
>> it (the condition?).  It wasn't clear.  At any rate, if you understand
>> this you can probably re-add it and I'm sure it won't make any
>> difference to the time.
>
> See `display-buffer-assq-regexp' in window.el.

Sorry, I'm not following.  Anyway, as I said, this seems to be a detail:
feel free to add back arg wherever it is needed.

>>                                          More importantly, you're
>> forcing the byte-compilation process to run every one of those 100000
>> repetitions, which is not something we want to measure: the point of any
>> code compilation is to do it once and then reuse the results of
>> compilation many times.
>
> Exactly, but if the byte-compilation would take place in buffer-match-p,
> then the measurement is relevant.

But then you're throwing away the benefits of compilation.  But my
suggestion is for you to get rid of "buffer-match-p".  Rather, make a
'buffer-matcher' that does the compilation, and then place the return
value of that, which is a plain old (possibly very fast, if compiled)
function object in the display-buffer-alist variables and everywhere
where you can put functions.

That way you still get your mini-language, you get a much faster version
of it, and you don't force your mini-language to other people who prefer
just typing plain old Elisp.

>> (and I'm still confused by the purpose of the hash table usage)
>
> The rationale is the same as for regular expressions in the core.  They
> are also compiled and stored, to avoid the need for them to be
> interpreted over and over again.
>
> This should all be explained in the bug report I pointed you to, and
> where this discussion should continue.

Well, I think you're overcomplicating this.  If you insulate
display-buffer-alist from the mini-language (i.e. you keep it the way it
was), then you don't need this hash table, and you can still use the
mini-language.

(add-to-list 'display-buffer-alist
             `(,(philips-mini-language-buffer-matcher
                  '(and (mode . x) (or (not (and "123")))))
               . display-buffer-in-side-window))

Again: you keep your mini-language and you can suggest people use
philips-mini-language-buffer-matcher in many other library APIs in
Emacs, not just window.el, but without needing to ever touch those
libraries.

It's a much more modular design, less impositive, much smaller and much
faster.

> This is currently not the case, but if the language extended in the
> future, there is the possibility that naming conflicts could arise.  I
> am just following the same principle used when writing macros that
> avoids name capturing.

You don't need to cargo cult that principle blindly.  This kind of macro
hygiene you are talking about is for macros that take arbitrary lisp
forms, which is not the case of the mini-language.  If it ever is, add
the hygiene then and likely not in a top-level defvar.

João