bug#54296: Add buffer-matching functionality

[Dmitry Gutov <dgutov@yandex.ru>]

On 13.06.2022 15:04, Eli Zaretskii wrote:
>> Date: Mon, 13 Jun 2022 03:21:13 +0300
>> Cc: 54296@debbugs.gnu.org, larsi@gnus.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>> On 14.03.2022 15:38, Philip Kaludercic wrote:
>>> The issue isn't that the default value couldn't be updated, but that if
>>> anyone has e.g. been using `project-kill-buffer-conditions' over the
>>> last 1½ years and has relied on the specific distinction between
>>> `major-mode' and `derived-mode', they would run in to unexpected
>>> results, that might result in more buffers being killed than intended,
>>> potentially data being lost that the user might not expect because of an
>>> update.
>>
>> I see that this point hasn't been addressed at all.
>>
>> Eli?
> 
> Do you agree with Philip that deprecating or removing major-mode would
> be a problem for users of project-kill-buffer-conditions etc.?

Yes. I also mentioned that here: 
https://lists.gnu.org/archive/html/emacs-devel/2022-06/msg00650.html

Not for all users, only for some of those who customized the value, 
etc... but we're usually more concerned about backward compatibility 
than the present development seems to have indicated.

If we can argue over several days (or weeks?) about removing a key 
binding that nobody uses, changing DSL in an incompatible way has to be 
considered a problem.

> I kinda gave up because Philip felt extremely uneasy with dropping
> major-mode, leaving us with just derived-mode, but I still think we
> shouldn't encourage Lisp programs to use major-mode.  So if you don't
> think it would be a problem, I'd be happier if we removed major-mode
> and used derived-mode instead.

If I didn't think Philip's point had merit, I wouldn't have brought it 
up now.

The idea of discouraging the (eq major-mode ...) semantics (instead of 
derived-mode-p) has merit, but so far we have one complex prior art for 
this functionality, and it did find a use for this distinction. Two 
uses, to be exact.

Another example where we might migrate to buffer-matches-p is 
'turn-on-font-lock-if-desired'. And that one also currently uses

   (memq major-mode font-lock-global-modes)

rather than derived-mode-p. There probably are reasons for this as well.

We could try some methods that discourage the use of 'major-mode' as 
opposed to 'derived-mode'. Maybe by calling them 'major-mode-eq' and 
'major-mode' (where the longer version feels more awkward and thus less 
desirable). But FWIW I like the current couple of 'derived-mode' and 
'major-mode' because it feels "transparent" for an experienced Elisp 
programmer. Rather than having one guess that 'major-mode' uses the 
derived-mode-p predicate or search for that info in the docs.

And if we change the keywords in project-kill-buffer-conditions, I 
suppose it will require some migration strategy. Which is going to be a 
pain.