GNU bug report logs - #58839
29.0.50; project-kill-buffer fails when Eglot is running

Previous Next

Full log

Message #131 received at 58839 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, manuel.uberti <at> inventati.org,
 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
 fails when Eglot is running
Date: Tue, 1 Nov 2022 10:59:41 +0000

[Message part 1 (text/plain, inline)]

On Tue, Nov 1, 2022 at 10:48 AM Philip Kaludercic <philipk <at> posteo.net>
wrote:

>
> BTW, if there are major objections to the language, I should point out
> that the new `buffer-match-p' in Emacs 29 uses the same language and has
> already found usage in a number of spots in core Emacs.  There would
> still be time to address any issues you might have, and avoid a
> long-term mistake.
>

For me, it looks like match-buffers is reinventing
cl-remove-if-not and match-buffer-p is reinventing ... unary predicate
function of a buffer?

I'm not fond of these mini-languages because they're less expressive, they
end up being only minimally less complicated and bug-prone, they can't
automatically be byte-compiled for efficiency, and they can't automatically
be byte-compiled for correctness/diagnostics.  If one makes a mistake,
the backtrace is much more complicated.

So these mini-languages may make sense to define filters in thunderbird or
something, but throwing Elisp away here generally doesn't make sense to me.

But there may be exceptions (although this project.el one doesn't seem one
of them) so why don't you show examples of use of these new helpers and
so we can compare side by side with the Elisp-only alternative.

João

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.