Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> 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).
>
> Hm...  how would this be used with display-buffer-alist, then?  (And
> perhaps Martin has some comments; added to the CCs.)

See below.

>> 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.
>
> I think I'd prefer to have the parameters reversed -- the condition is a
> kind of predicate, and these days we seem to prefer to have the
> predicate first.

I agree, it makes more sense.

>> +(defun buffer-match (buffer condition)
>> +  "Return non-nil if BUFFER matches CONDITION.
>> +CONDITION is is either:
>> +- a regular expression, to match a buffer name,
>> +- a predicate function that takes a buffer object as argument
>> +  and returns non-nil if the buffer should be killed,
>
> Killed?

That was a typo from copying the docstring.  Here is the updated patch: