From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Philip Kaludercic <philipk@posteo.net>
Cc: 65797@debbugs.gnu.org, Joseph Turner <joseph@breatheoutbreathe.in>
Subject: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 18 Sep 2023 07:55:32 -0400 [thread overview]
Message-ID: <jwv1qevpurs.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87o7hz4zg2.fsf@posteo.net> (Philip Kaludercic's message of "Mon, 18 Sep 2023 09:12:45 +0000")
>>>>> 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
next prev parent reply other threads:[~2023-09-18 11:55 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 7:53 bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-07 12:35 ` Mattias Engdegård
2023-09-07 15:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-07 15:17 ` Mattias Engdegård
2023-09-07 13:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-07 15:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 4:40 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 6:46 ` Eli Zaretskii
2023-09-08 15:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 16:37 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 17:18 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 18:16 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 18:20 ` Eli Zaretskii
2023-09-11 16:57 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-11 18:58 ` Eli Zaretskii
2023-09-12 18:30 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 17:01 ` bug#65797: `buffer-match-p` should not use `func-arity` Philip Kaludercic
2023-09-12 18:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 21:50 ` Philip Kaludercic
2023-09-14 13:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-18 9:12 ` Philip Kaludercic
2023-09-18 11:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-09-18 17:23 ` Philip Kaludercic
2023-09-18 18:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-19 8:34 ` Philip Kaludercic
2023-09-19 10:06 ` Dmitry Gutov
2023-09-19 13:56 ` Philip Kaludercic
2023-09-19 16:13 ` Dmitry Gutov
2023-10-08 9:10 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 10:25 ` Dmitry Gutov
2023-10-09 21:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 4:53 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 11:34 ` Dmitry Gutov
2023-10-13 15:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-14 6:13 ` Eli Zaretskii
2023-10-14 14:31 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-15 6:13 ` Eli Zaretskii
2023-10-16 16:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-16 20:16 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-19 12:18 ` Eli Zaretskii
2023-10-21 2:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-15 0:45 ` Dmitry Gutov
2023-09-15 1:38 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-15 16:38 ` Dmitry Gutov
2023-09-15 17:54 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-15 18:00 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv1qevpurs.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=65797@debbugs.gnu.org \
--cc=joseph@breatheoutbreathe.in \
--cc=monnier@iro.umontreal.ca \
--cc=philipk@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).