[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65797: `buffer-match-p` should not use `func-arity`
From: |
Eli Zaretskii |
Subject: |
bug#65797: `buffer-match-p` should not use `func-arity` |
Date: |
Sun, 15 Oct 2023 09:13:27 +0300 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dmitry@gutov.dev, joseph@breatheoutbreathe.in, philipk@posteo.net,
> mattias.engdegard@gmail.com, 65797@debbugs.gnu.org
> Date: Sat, 14 Oct 2023 10:31:29 -0400
>
> > What bad things will happen if we leave emacs-29 with no changes?
>
> Nothing too serious.
> `buffer-match-p` is new in Emacs-29 and it is documented (in the Texinfo,
> not in the docstring) to provide a behavior we're unable to implement.
> So the main aim of the patch is to "fix" this new API so it can be
> implemented as documented.
>
> But the problem is somewhat corner-case, so it's not super urgent to fix it.
>
> OTOH, the change is minor and fairly safe.
> Basically the patch replaces an &optional with a &rest in the API.
> Besides allowing more cases (which is mostly a non-issue in terms of
> backward compatibility), this introduces just 1 potential problem:
>
> When `buffer-match-p` is called without the formerly optional arg, it
> will call the predicate functions with one fewer arg than before.
>
> The Emacs-29.1 code has a hack that tries to detect when the predicate
> expects "one fewer arg" and if so calls it without the optional arg, so
> I just extended that hack to also handle that reverse problem (when
> there is one fewer arg than expected by the function).
>
> If we put it into `master`, I guess we can stick to the original hack
> and hope the above "just 1 potential problem" won't bite us, but it
> seems we may as well use the more backward compliant option and put it
> into `emacs-29`.
>
> See below my current "safe" choice.
Sigh. I guess we can install this on emacs-29 and cross the
fingers...
- bug#65797: `buffer-match-p` should not use `func-arity`, Joseph Turner, 2023/10/08
- bug#65797: `buffer-match-p` should not use `func-arity`, Dmitry Gutov, 2023/10/08
- bug#65797: `buffer-match-p` should not use `func-arity`, Stefan Monnier, 2023/10/09
- bug#65797: `buffer-match-p` should not use `func-arity`, Joseph Turner, 2023/10/12
- bug#65797: `buffer-match-p` should not use `func-arity`, Dmitry Gutov, 2023/10/12
- bug#65797: `buffer-match-p` should not use `func-arity`, Stefan Monnier, 2023/10/13
- bug#65797: `buffer-match-p` should not use `func-arity`, Eli Zaretskii, 2023/10/14
- bug#65797: `buffer-match-p` should not use `func-arity`, Stefan Monnier, 2023/10/14
- bug#65797: `buffer-match-p` should not use `func-arity`,
Eli Zaretskii <=
- bug#65797: `buffer-match-p` should not use `func-arity`, Stefan Monnier, 2023/10/16
- bug#65797: `buffer-match-p` should not use `func-arity`, Joseph Turner, 2023/10/16
- bug#65797: `buffer-match-p` should not use `func-arity`, Eli Zaretskii, 2023/10/19
- bug#65797: `buffer-match-p` should not use `func-arity`, Stefan Monnier, 2023/10/20