bug#54296: closed (Add buffer-matching functionality)

[GNU bug Tracking System]

Your message dated Fri, 15 Apr 2022 10:57:02 +0000
with message-id <875yna398h.fsf@posteo.net>
and subject line Re: bug#54296: Add buffer-matching functionality
has caused the debbugs.gnu.org bug report #54296,
regarding Add buffer-matching functionality
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
54296: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=54296
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: Add buffer-matching functionality Date: Mon, 07 Mar 2022 22:33:29 +0000

Tags: patch


Project.el currently has a small language for matching buffers, used by
project-kill-buffers and project--read-project-buffer.  As mentioned in
[0], this could be generalised, as done in the patch below.  As to what
file this should be added to, should be discussed.

Either way I would consider these functions useful and would have wanted
to use them in my own code many times before.  While difficult, it might
also be useful for things like display-buffer-alist (the issue is that
a function as a condition in display-buffer-alist has to accept two
arguments, while the proposed patch only takes one).

To match functions such as string-match, the argument of buffer-match
could be reversed so that the function can be used as a testfn to
assoc/alist-get.

<tangent>
The reason this was not immediately done when project-kill-buffers was
implemented, was that this would raise the "emacs" dependency of the
ELPA package "project" to the latest release or even the current
development version.

To solve issues like these, I have been working on "compat", a
yet-unreleased library added to GNU ELPA a while back that could be
added as a dependency to project.  That way newer functions, such as the
ones propose below could be used, without breaking ELPA compatibility.

To make this work properly in the near future, compat would have to
follow the upstream development, before a release is made.  If there is
any interest in this kind of an arrangement, I could start a thread on
emacs-devel to discuss the details.
</tangent>

[0] https://mail.gnu.org/archive/html/emacs-devel/2020-09/msg00082.html
[1] https://elpa.gnu.org/devel/compat.html


In GNU Emacs 29.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, 
cairo version 1.16.0)
 of 2022-02-24 built on viero
Repository revision: bd17fa2c7565f180cedbfa396c0b159e144178cb
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000

0001-Generalise-buffer-matching-from-project.el.patch
Description: Text Data

-- 
        Philip Kaludercic

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#54296: Add buffer-matching functionality
>
>
>
>
> Date: 
>
> Fri, 15 Apr 2022 10:57:02 +0000
>
>
>
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: larsi@gnus.org,  54296@debbugs.gnu.org
> >> Date: Thu, 14 Apr 2022 08:25:58 +0000
> >> 
> >> >> > I suggested to "clarify" that by not providing the 'major-mode'
> >> >> > predicate at all.  I still don't think I understand why it is so
> >> >> > important that we should provide a special case for it.
> >> >> 
> >> >> It is not inherently important, it is just that if the predicate would
> >> >> also be used in project.el, then compatibility would have to be broken,
> >> >> as the distinction between `major-mode' and `derived-mode' exists there.
> >> >
> >> > Then project.el could use the predicate route, right?  It's quite a
> >> > special case, AFAIU, so having a special solution is OK.
> >> 
> >> I have updated the commits as you recommended, and add a commit
> >> deprecating the use of `derived-mode' in project.el.
> >
> > Thanks, LGTM.
>
> Great!  The commits have been pushed.
>
> -- 
>         Philip Kaludercic
>
>
> --- End Message ---