bug#54296: Add buffer-matching functionality

[Augusto Stoffel]

Coincidentally, I've been discussing with Stefan a similar mini-language
for the 'font-lock-ignore' feature.  Here are some thoughts

On Thu, 10 Mar 2022 at 13:53, Eli Zaretskii <eliz@gnu.org> wrote:

>> +- 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 eq to the cons-cell's cdr
>> +  * `derived-mode': the buffer matches if the buffer's major
>> +    mode is derived from the major mode denoted by the cons-cell's
>> +    cdr
>
> Do we really need both major-mode and derived-mode?

It seems handy to allow (mode MODE) to match a buffer with major mode
derived from MODE or if MODE is bound and true as a variable in that
buffer (say, it's the name of a minor mode).

>> +  * `not': the cdr is interpreted as a negation of a condition.
>> +  * `and': the cdr is a list of recursive condition, that all have
>> +    to be met.                            ^^^^^^^^^
>
> Typo: should be "conditions".
>
>> +  * `or': the cdr is a list of recursive condition, of which at
>> +    least one has to be met."            ^^^^^^^^^

In 'font-lock-ignore' you can prefix an or-condition with !, with the
gitignore semantics.  This seems very appropriate for a buffer-matching
functionality.

But then `or' is not the familiar short-circuiting
operation, and you need to evaluate the conditions backwards...

On a more bikesheddy note, I'm also debating a bit what is more
readable:

    (or cond1 cond2 ! cond2)

or else
  
    (or cond1 cond2 (except cond2))