bug#54296: Add buffer-matching functionality

[Eli Zaretskii]

> Date: Tue, 14 Jun 2022 22:36:55 +0300
> Cc: 54296@debbugs.gnu.org, philipk@posteo.net, larsi@gnus.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 14.06.2022 21:47, Eli Zaretskii wrote:
> 
> > So then everything is okay, AFAIU, because eventually Philip left that
> > in the code.  Right?
> 
> No, he didn't.
> 
> He tried to migrate project-kill-buffer-conditions to the new format, 
> with predicted unfortunate side-effects. And an unpredicted one (which 
> is easier to fix, though).
> 
> See commit 1a3bad431d.

Which part?

AFAICT, major-mode is still in the code:

  (defun buffer-match-p (condition buffer-or-name &optional arg)
    "Return non-nil if BUFFER-OR-NAME matches CONDITION.
  CONDITION is either:
  - a regular expression, to match a buffer name,
  - a predicate function that takes a buffer object and ARG as
    arguments, and returns non-nil if the buffer matches,
  - a cons-cell, where the car describes how to interpret the cdr.
    The car can be one of the following:
    * `major-mode': the buffer matches if the buffer's major
      mode is derived from the major mode denoted by the cons-cell's
      cdr
  [...]
                       ((eq (car-safe condition) 'major-mode)
                        (provided-mode-derived-p
                         (buffer-local-value 'major-mode buffer)
                         (cdr condition)))


> > OK, but I didn't press my POV, so where's the problem, and why the
> > emotions?
> 
> Your POV was the one that got implemented. buffer-match-p has 
> 'major-mode' but not 'derived-mode'. And 'major-mode' behaves like 
> 'derived-mode' behaved in project-kill-buffer-conditions.

This seems to be some misunderstanding.  I wanted us to have only
'derived-mode', not 'major-mode'.  But Philip was unhappy about that,
due to existing usage of 'major-mode', and eventually 'major-mode' was
left in the code.  Or at least this is my recollection of the
discussion and its resolution.