From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#65797: `buffer-match-p` should not use `func-arity` Date: Tue, 19 Sep 2023 08:34:57 +0000 Message-ID: <87y1h2blxq.fsf@posteo.net> References: <87v8cmct9b.fsf@breatheoutbreathe.in> <87sf7o38g1.fsf_-_@posteo.net> <871qf1rbdo.fsf@posteo.net> <87o7hz4zg2.fsf@posteo.net> <87sf7b8ker.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5297"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65797@debbugs.gnu.org, Joseph Turner To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 19 10:36:09 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qiWDJ-000182-PL for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Sep 2023 10:36:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiWD5-0008Mi-So; Tue, 19 Sep 2023 04:35:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qiWD3-0008MV-Uv for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2023 04:35:54 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qiWD3-00057w-Lk for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2023 04:35:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qiWDC-00043k-0f for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2023 04:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Sep 2023 08:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65797 X-GNU-PR-Package: emacs Original-Received: via spool by 65797-submit@debbugs.gnu.org id=B65797.169511251815504 (code B ref 65797); Tue, 19 Sep 2023 08:36:01 +0000 Original-Received: (at 65797) by debbugs.gnu.org; 19 Sep 2023 08:35:18 +0000 Original-Received: from localhost ([127.0.0.1]:55346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiWCU-000420-62 for submit@debbugs.gnu.org; Tue, 19 Sep 2023 04:35:18 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:49397) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiWCP-00041Y-NG for 65797@debbugs.gnu.org; Tue, 19 Sep 2023 04:35:17 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id E8663240105 for <65797@debbugs.gnu.org>; Tue, 19 Sep 2023 10:34:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695112498; bh=e5OPt+4foVd8gNduhr4ieCXRTqLSX/vvIVyOMSFrnXY=; h=From:To:Cc:Subject:Autocrypt:Date:Message-ID:MIME-Version:From; b=BBpbGVb2efB7SF4xduIndGoVqpmuKRq6Ny2xJY2wcte5tD33cl7sYj/eMmQe5dFDH g6BhyHLJU59kqvhSWpqBYjd+7ZhGThY/v4TcA1/9M3A0TGkjNkUeOYquZ5OpoZihNm Vtx9EoAuQ9qMgdu4pR64KZz1S9ea9RTVDk2odl5TUhcdQvNdh6ZbaSZKroj6syXdxn 0mb/oN7YRC5oN36lzr9G4G43W10846gRi9PURiOL1d65vGYzsoUtvNBsYnWXO+ittP 4I9sNtDRyha+ZBD9xioP+j/SO+VhBlDk2Ee+8V7E0SFpCX58Fu7gTWof4oBTuc+PkX Qlwylb+2ZwDtA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RqZjF5R0kz9rxg; Tue, 19 Sep 2023 10:34:57 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Mon, 18 Sep 2023 14:05:48 -0400") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270854 Archived-At: Stefan Monnier writes: >>> - 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. >> >> I would be disappointed to see this path taken, since part of my hope >> with buffer-match-p was that it could be used in project.el as well >> (allowing this to be a thing is one of the reasons I started working on >> Compat). > > I don't understand: you just told me you have no examples of places > where single-arg functions are concretely useful. My apologies, to clarify: I don't know of any example where it is currently used (project.el has a separate implementation), but this would be one example where a single-argument invocation would be useful. > So, assuming `buffer-match-p` is used in many other things, like > `project.el`, do you have examples where the feature of choosing between > calling sometimes with one arg and sometimes with two would be > useful/handy? That is a different matter. Usually if buffer-match-p is not passed an argument via ARG, then all the function calls would also just have a single argument. But in other examples, such as display-bufffer-alist where ARG is non-nil, the user might want to fall back onto ignoring ARG. OTOH the difference between (lambda (buf) ...) and (lambda (buf _) ...) is not that great either. So one could invoke the function with two arguments if ARG is non-nil, and otherwise just with one. > [ BTW, changing the code to use `&rest args` instead of `&optional arg` > would help for this, right? ] How come? >>> - 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). >> >> So `(arg1 ,(lambda (x) ...)) and `(arg2 ,(lambda (x y) ...))? > > No, I was more thinking of `(pred1 FOO)` vs `(pred FOO)` or using just > `FOO` for those functions which take all the arguments and `[FOO]` for > those functions which only accept a single argument, or any other > suitable "annotation". > Or you could use an OClosure which carries some explicit user-provided > arity info with it. How would that look like? >>> - Live with the occasional breakage and bug reports like the current one. >> The issue here was related to advising a function. And you are saying >> there is no way around this, not even by annotating the function symbol >> with the initial arity before it is advised. > > No, we can fix this case with some ad-hoc hack. > But we can't fix every case once and for all, so the hack ends up being > very costly compared to its benefit. > > The general rule is that you should never look at a function to decide > how to call it (more generally, you should never look at a function > beyond testing `functionp` or `commandp` (other than for debugging and > the like), you should only call it). OK, I see, I was not familiar with this principle. > > Stefan