bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#65797: `buffer-match-p` should not use `func-arity`


From: Stefan Monnier
Subject: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 18 Sep 2023 07:55:32 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

>>>>> FWIW The intention here was to be able and specify simpler conditions
>>>>> that don't have to handle the alist.
>>>> You mean for `display-buffer-alist`?
>>>> Do you have examples that rely on this?
>>> From the core?  No, I cannot think of an example, but any user
>>> configuration may make use of this feature.
>> From the core would have been good, but from elsewhere (including
>> random .emacs config you may find on the web) would be helpful to gauge
>> how important that could be.
> I don't know of any examples.

In that case I suggest we deprecate this feature (i.e. the fact that
the function can take a single arg).

>>> I am not sure if I just missed it, but is there no technical solution
>>> around the advice issue?  Couldn't `func-arity' check if the actual
>>> function and the advice function have the same arity, and return the
>>> right value in that case?  My impression is that in 99% of the cases,
>>> advice isn't used to increase or decrease the arity of a function.
>> There are various 99% solutions, yes.
>> There is no 100% solution, OTOH :-(
>> So the documented behavior is inherently unreliable.
> So what are the options then?

Alternatives I can see:

- Deprecate the feature with no replacement (i.e. users will have
  to use a (lambda (x y) (foo x)) wrapper to drop the second arg if they
  were using the feature).  That's my favorite option at this point.
- Replace it with some alternative (e.g. provide two different syntaxes
  for functions, one for functions that expect all args and one for
  functions that only take a single arg).
- Live with the occasional breakage and bug reports like the current one.

> Does one have to pick a 99% solution?

Hopefully not.  The 99% solution (whichever one is used) should
hopefully only be used temporarily for backward compatibility while the
feature is phased out.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]