[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: |
Philip Kaludercic |
Subject: |
bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running |
Date: |
Wed, 02 Nov 2022 09:06:20 +0000 |
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
- 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, 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/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 <=
- 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, 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