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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: monnier <at> iro.umontreal.ca, 65797 <at> debbugs.gnu.org
Subject: bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially
Date: Mon, 11 Sep 2023 21:58:26 +0300

> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 65797 <at> debbugs.gnu.org
> Date: Mon, 11 Sep 2023 09:57:51 -0700
> 
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I think one of the alternatives you proposed was backward-compatible
> > (albeit not very elegant).  So my vote is for that alternative.
> 
> I'm in favor of the solution in the patch (from Stefan's suggestion):
> 
> > - Replace `&optional arg` with `&rest args` and pass those args via
> >   `apply`, so the number of args passed doesn't depend on the function
> >   but on the caller.
> 
> The "&rest args" solution is clean and hack-free. It breaks
> compatibility, but in unlikely cases:
> 
> - CONDITION pred accepts only a buffer argument, but additional ARG was
>   passed (why would you do this?)
> 
> - CONDITION pred accepts two arguments, and no ARG was passed (this code
>   would be broken anyway, right?)
> 
> Since buffer-match-p is new in Emacs 29, is it acceptable to assume that
> code affected by this breakage can be updated?

We have an alternative that doesn't break any compatibility, so I
think it is preferred.

Previous Next

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