From: Philip Kaludercic <philipk@posteo.net>
To: "João Távora" <joaotavora@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
58839@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>
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 [thread overview]
Message-ID: <87v8nxafoz.fsf@posteo.net> (raw)
In-Reply-To: <87r0ylsq7o.fsf@gmail.com> ("João Távora"'s message of "Wed, 02 Nov 2022 08:41:47 +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
next prev parent reply other threads:[~2022-11-02 9:06 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 12:56 bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Philip Kaludercic
2022-10-28 17:17 ` bug#58839: [Patch] " João Távora
2022-10-28 17:28 ` Philip Kaludercic
2022-10-28 17:36 ` João Távora
2022-10-28 18:14 ` Dmitry Gutov
2022-10-28 18:20 ` Philip Kaludercic
2022-10-28 18:30 ` João Távora
2022-10-28 18:40 ` Dmitry Gutov
2022-10-29 0:15 ` João Távora
2022-10-29 1:09 ` Dmitry Gutov
2022-10-29 1:39 ` João Távora
2022-10-29 11:27 ` Dmitry Gutov
2022-10-29 12:16 ` João Távora
2022-10-29 14:32 ` Philip Kaludercic
2022-10-29 20:38 ` João Távora
2022-10-29 22:01 ` Philip Kaludercic
2022-10-29 22:49 ` João Távora
2022-10-30 6:28 ` Eli Zaretskii
2022-10-30 12:40 ` João Távora
2022-10-30 15:58 ` Dmitry Gutov
2022-10-30 16:39 ` Eli Zaretskii
2022-10-30 19:13 ` Dmitry Gutov
2022-10-30 19:54 ` Eli Zaretskii
2022-10-30 21:15 ` Dmitry Gutov
2022-10-31 9:53 ` João Távora
2022-10-31 11:56 ` João Távora
2022-10-31 17:11 ` Dmitry Gutov
2022-10-31 20:36 ` João Távora
2022-10-31 22:26 ` Dmitry Gutov
2022-10-31 22:51 ` João Távora
2022-10-31 14:35 ` Philip Kaludercic
2022-10-31 17:33 ` Dmitry Gutov
2022-10-31 23:19 ` João Távora
2022-11-01 10:51 ` Philip Kaludercic
2022-11-01 13:22 ` Dmitry Gutov
2022-11-01 13:39 ` João Távora
2022-10-31 17:24 ` Dmitry Gutov
2022-10-31 20:58 ` João Távora
2022-10-31 22:51 ` Dmitry Gutov
2022-11-01 10:48 ` Philip Kaludercic
2022-11-01 10:59 ` João Távora
2022-11-01 11:23 ` Dmitry Gutov
2022-11-01 11:39 ` João Távora
2022-11-01 15:27 ` Dmitry Gutov
2022-11-01 16:23 ` João Távora
2022-11-01 22:24 ` Dmitry Gutov
2022-11-02 7:40 ` João Távora
2022-11-01 11:27 ` Philip Kaludercic
2022-11-01 11:59 ` João Távora
2022-11-01 13:03 ` Philip Kaludercic
2022-11-01 13:37 ` João Távora
2022-11-01 14:00 ` Philip Kaludercic
2022-11-01 14:11 ` João Távora
2022-11-01 14:36 ` Philip Kaludercic
2022-11-02 7:19 ` João Távora
2022-11-02 7:29 ` Philip Kaludercic
2022-11-02 7:48 ` João Távora
2022-11-02 8:21 ` Philip Kaludercic
2022-11-02 8:41 ` João Távora
2022-11-02 9:06 ` Philip Kaludercic [this message]
2022-11-02 9:52 ` João Távora
2022-11-02 11:31 ` Philip Kaludercic
2022-11-01 15:26 ` Dmitry Gutov
2022-11-01 18:44 ` Philip Kaludercic
2022-11-01 19:50 ` Dmitry Gutov
2022-11-01 20:10 ` Philip Kaludercic
2022-11-01 22:40 ` Dmitry Gutov
2022-11-01 11:36 ` João Távora
2022-11-01 22:23 ` Dmitry Gutov
2022-11-02 7:34 ` João Távora
2022-11-02 8:36 ` Philip Kaludercic
2022-11-02 8:50 ` João Távora
2022-11-02 9:13 ` Philip Kaludercic
2022-11-02 14:00 ` João Távora
2022-11-02 14:42 ` Philip Kaludercic
2022-11-02 17:32 ` Juri Linkov
2022-11-03 17:30 ` Juri Linkov
2022-11-03 18:19 ` João Távora
2022-11-02 18:16 ` João Távora
2022-11-04 1:13 ` Dmitry Gutov
2022-11-04 11:21 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-05 0:53 ` Dmitry Gutov
2022-10-29 6:38 ` Philip Kaludercic
2022-10-29 10:59 ` Dmitry Gutov
2022-10-29 11:12 ` João Távora
2022-10-29 11:05 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v8nxafoz.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=58839@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=joaotavora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.