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:

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

I just meant to give an example where and how the argument is used.

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

I see, but I don't agree.  My main objection here is that the conditions
aren't introspectable (e.g. when using ECI) any more and that it all
becomes more verbose.

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

That is not the case to begin with, as the "mini-language" is just a
super-set of Emacs Lisp, seeing as any function is a legal word of the
language.  As I have said before, it just makes it easier to write
common operations like matching buffer names or major modes.

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

I have not much elese to say on the issue here, that hasn't already been
said.  If you think it is such a mistake, please report a bug or post on
emacs-devel and we can clarify the issue there.

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

I don't see any disadvantage from following best practices, even if it
is not immediately relevant.  There is no reason why `buffer' ought to
be a special symbol, so I would like to avoid the possibility of this
leading to issues that hack to be back-hacked at some point in the
future.

But this is just a matter of personal style.  I have seen you write
documentations strings like "[...] This docstring appeases checkdoc,
that's all.", while I insist on documenting every function I commit,
even if I am the only one who uses the package.  We just have different
principles.

> João