[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails whe
From: |
João Távora |
Subject: |
bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running |
Date: |
Wed, 02 Nov 2022 09:52:50 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, (continued)
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/11/01
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/11/01
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/11/01
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/11/01
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/11/02
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/11/02
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/11/02
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/11/02
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/11/02
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/11/02
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running,
João Távora <=
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/11/02
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Dmitry Gutov, 2022/11/01
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/11/01
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Dmitry Gutov, 2022/11/01
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/11/01
- bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Dmitry Gutov, 2022/11/01
bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, Philip Kaludercic, 2022/11/01
bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running, João Távora, 2022/11/01