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:

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

If you want introspection, i.e. see the translated Elisp code when
inspecting the value of display-buffer-alist, then pass another argument
to buffer-matcher which makes it return an uncompiled function.

Furthermore, as debugging goes, the buffer-matcher idea is much better:
if the user does a mistake in his mini-language program, that mistake
can be caught when buffer-matcher is called, i.e. during her init.  Not
when display-buffer-alist is about to run the program.  And if your
mini-language ever evolves, you can also issue warnings at this point.
This is what compilation and compilers have always existed for.  Lisp
gives you this power in a few lines (something which takes a lot of hard
in other languages).

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

That's not what a super-set is.  A super-set language is C++ to C,
because C++ can compile (almost any) C program.  The mini-language is a
DSL.  In my opinion, one that brings very few advantages, but there's no
accounting for taste.  So the common way to do DSL's in Elisp is use the
approach I provided.  You make them more useful, and you don't force
people to use them.

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

OK.  It's not so much a mistake as lost opportunity to make a more
reusable, less britlle piece of software using less code, less
docstrings, less manual writing, etc.  Cuts down on the mental overload,
potentially teaches some people Elisp instead of mini-language, and
reduces CPU usage and laptop battery time.

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

This is not a best practice, really it's not. MAKE-SYMBOL and GENSYM are
for macro that take forms hygiene: this is simply not that case.

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

Ahaha, that was just a joke.  Keep documenting all your functions,
you're very right to do so.  Trust me, don't make defvar's for
(make-symbol).  Noone does this: it's just cruft.