[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
bug#65797: `buffer-match-p` should not use `func-arity`, Philip Kaludercic, 2023/09/08
- bug#65797: `buffer-match-p` should not use `func-arity`, Stefan Monnier, 2023/09/12
- bug#65797: `buffer-match-p` should not use `func-arity`, Philip Kaludercic, 2023/09/14
- bug#65797: `buffer-match-p` should not use `func-arity`, Stefan Monnier, 2023/09/14
- bug#65797: `buffer-match-p` should not use `func-arity`, Philip Kaludercic, 2023/09/18
- bug#65797: `buffer-match-p` should not use `func-arity`,
Stefan Monnier <=
- bug#65797: `buffer-match-p` should not use `func-arity`, Philip Kaludercic, 2023/09/18
- bug#65797: `buffer-match-p` should not use `func-arity`, Stefan Monnier, 2023/09/18
- bug#65797: `buffer-match-p` should not use `func-arity`, Philip Kaludercic, 2023/09/19
- bug#65797: `buffer-match-p` should not use `func-arity`, Dmitry Gutov, 2023/09/19
- bug#65797: `buffer-match-p` should not use `func-arity`, Philip Kaludercic, 2023/09/19
- bug#65797: `buffer-match-p` should not use `func-arity`, Dmitry Gutov, 2023/09/19
bug#65797: `buffer-match-p` should not use `func-arity`, Dmitry Gutov, 2023/09/14
bug#65797: `buffer-match-p` should not use `func-arity`, Stefan Monnier, 2023/09/14
bug#65797: `buffer-match-p` should not use `func-arity`, Dmitry Gutov, 2023/09/15
bug#65797: `buffer-match-p` should not use `func-arity`, Joseph Turner, 2023/09/15