From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#65797: `buffer-match-p` should not use `func-arity` Date: Mon, 18 Sep 2023 14:05:48 -0400 Message-ID: References: <87v8cmct9b.fsf@breatheoutbreathe.in> <87sf7o38g1.fsf_-_@posteo.net> <871qf1rbdo.fsf@posteo.net> <87o7hz4zg2.fsf@posteo.net> <87sf7b8ker.fsf@posteo.net> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29676"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 65797@debbugs.gnu.org, Joseph Turner To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 18 20:08:44 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 1qiIfo-0007O3-8U for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Sep 2023 20:08:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiIf6-0002Hz-DA; Mon, 18 Sep 2023 14:07:56 -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 1qiIf4-0001xa-31 for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 14:07: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 1qiIf3-0004V0-Nh for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 14:07:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qiIfC-0002aB-0W for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 14:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Sep 2023 18:08: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.16950604419880 (code B ref 65797); Mon, 18 Sep 2023 18:08:01 +0000 Original-Received: (at 65797) by debbugs.gnu.org; 18 Sep 2023 18:07:21 +0000 Original-Received: from localhost ([127.0.0.1]:54528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiIeX-0002ZH-Ct for submit@debbugs.gnu.org; Mon, 18 Sep 2023 14:07:21 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiIeU-0002Z4-TK for 65797@debbugs.gnu.org; Mon, 18 Sep 2023 14:07:20 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AC2471000A3; Mon, 18 Sep 2023 14:07:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1695060423; bh=xefT8ftJeCPDKTIfoeFcSJtbOl43cGC35yLCX1Xh7fI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OulUMkeC0f0qlkHz5VkvVxJJ1K/zfDSi1+amIQpSyQHUVNmUD55pT1cq/InWU7W28 cZACzq2Tu5Q/65ZtSCrENs8wvbIbPNGcRlQ+keMQ42JJFjFx2Iq60pKw95X24QvuWx tQeBnM+WwD8vfLsbDlhLWe0l/JVwJNaqB1v8N0ph76hDQ/EprIafuYx+2LwXv+K4UK u3ZHytotSb1cgCJUuFMMYOzfyxahOJvPSLH2tCCHpaGSzf+vblpIX7SuNC3C9emvCV 2k7cYIdiYFzFcVNbJnnGblGx/87DkGiOyj61sAP9yW6lc5mU8ul+L/TqmJapaRAXHh WocQ2EAcp2Y9A== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A38C5100046; Mon, 18 Sep 2023 14:07:03 -0400 (EDT) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 953841202E4; Mon, 18 Sep 2023 14:07:03 -0400 (EDT) In-Reply-To: <87sf7b8ker.fsf@posteo.net> (Philip Kaludercic's message of "Mon, 18 Sep 2023 17:23:56 +0000") 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:270835 Archived-At: >> - 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. 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? [ BTW, changing the code to use `&rest args` instead of `&optional arg` would help for this, right? ] >> - 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. >> - 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). Stefan