GNU bug report logs - #65797
`buffer-match-p` should not use `func-arity`

Previous Next

Full log

Message #124 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, dmitry <at> gutov.dev, philipk <at> posteo.net,
 mattias.engdegard <at> gmail.com, joseph <at> breatheoutbreathe.in
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Sat, 14 Oct 2023 09:13:19 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Joseph Turner <joseph <at> breatheoutbreathe.in>,  Philip Kaludercic
>  <philipk <at> posteo.net>,  Mattias Engdegård
>  <mattias.engdegard <at> gmail.com>,
>   Eli Zaretskii <eliz <at> gnu.org>,  65797 <at> debbugs.gnu.org
> Date: Fri, 13 Oct 2023 11:57:59 -0400
> 
> >> Then how 'bout something like the patch below which changes the
> >> `&optional` into an `&rest` but tries to preserve compatibility with the
> >> old calling convention.
> > Personally, I figured that using &rest would already help with backward
> > compatibility to an extent.
> 
> I don't have a good intuition for how important backward compatibility
> is here, so I went for the "safe" choice.  But maybe we don't need to go
> that far.  The patch below keeps the same compatibility hack as we
> currently have but doesn't add any new compatibility, so it will break
> those uses where `buffer-match-p` is called without additional args but
> the predicate function still expects 2 args (where the second is always
> nil).  Indeed, that case seemes extremely unlikely.
> 
> Eli, Stefan, WDYT?

TBH, I have no way of assessing the risks in such a change.

Do we have to make this change on the release branch?  What bad things
will happen if we leave emacs-29 with no changes?  The discussion
thread is quite long, but my personal take from it is that the
arguments for making any changes in the current code are largely
theoretical and aesthetic.  Am I wrong?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.