From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#66908: Exposing more public nadvice API Date: Sat, 04 Nov 2023 11:58:39 +0530 Message-ID: <87wmuydobs.fsf@gmail.com> References: <878r7fw802.fsf@posteo.net> <87msvufz8n.fsf@gmail.com> <875y2ifd2c.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29918"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Philip Kaludercic , 66908@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 04 07:29:39 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 1qzAA6-0007gh-TG for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Nov 2023 07:29:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qzA9x-0005tx-44; Sat, 04 Nov 2023 02:29:29 -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 1qzA9w-0005td-1O for bug-gnu-emacs@gnu.org; Sat, 04 Nov 2023 02:29:28 -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 1qzA9v-0006qk-Pf for bug-gnu-emacs@gnu.org; Sat, 04 Nov 2023 02:29:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qzAAU-0004Iv-Df for bug-gnu-emacs@gnu.org; Sat, 04 Nov 2023 02:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Nov 2023 06:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66908 X-GNU-PR-Package: emacs Original-Received: via spool by 66908-submit@debbugs.gnu.org id=B66908.169907936616477 (code B ref 66908); Sat, 04 Nov 2023 06:30:02 +0000 Original-Received: (at 66908) by debbugs.gnu.org; 4 Nov 2023 06:29:26 +0000 Original-Received: from localhost ([127.0.0.1]:60265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzA9t-0004Hh-V8 for submit@debbugs.gnu.org; Sat, 04 Nov 2023 02:29:26 -0400 Original-Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]:51532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzA9s-0004HT-FE for 66908@debbugs.gnu.org; Sat, 04 Nov 2023 02:29:25 -0400 Original-Received: by mail-pl1-x644.google.com with SMTP id d9443c01a7336-1cc0d0a0355so22397715ad.3 for <66908@debbugs.gnu.org>; Fri, 03 Nov 2023 23:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699079322; x=1699684122; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RZpRzbUF26a4ncBhSTx2CUcKM+s6QvMT05MrXKxnlGc=; b=PnLEBNXZeIR1Df3oXKq263fC7w4KDasCBYubXEICU8XET47m40YgLB/NBipIDI03ox 47PjTvuLbDCXJMQD6x+49gFrM3ZPYuHTyj3j2JypWuuu033OJ++qSLoLdHpxWiUyYO1h Z7Mdsxie6W+o6GiiskdrHQJVRnpPEE3RHnsmjWIhtuEAmvJELw5coMqdnjiYu0fuf7Xg F5RmeAmyP6/mDU7r5tE5ECSccd4ZsyEBMMhgnkHtQmIYIpiAtGaQfyMkfGOyWTHDLamT 95vWL4p9D+Zk2inyDOIWf2vd9xZGcA+dBmJlYDV7Qc2z//MzTTMf3lsr4YSYdnlpmoaT nH4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699079322; x=1699684122; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=RZpRzbUF26a4ncBhSTx2CUcKM+s6QvMT05MrXKxnlGc=; b=bbtNKe6h/rVs6FZXc9jKqNaptYN4A9HK2GhmUDJ5tNFZzWS/TBHjNYNeIjp5BS5I2V q0K4Mpwr31mt2bgitTDwVjlCgVLh262Jde8UAVnErEM/m592g05IvgngcLJNI/u1STn1 iTZZ00ByLvqwGnEwHFd5/Cr9Yssf/hD8JP7UmFAmzoWHtxGxaKeR73A/ok8Zw/2K8bGA g+/TazYIQU4/zwtOjVNH85v2CEvopa9Ls/mvg8BdxruosNDv1Gvt9bASy8IS6Yzp1Vbb 6XgTbgw/SiWvKZ0b2sHwr9YHh8rNvfsGWrXpWhbuAbohzSFEH5n9ACmVZVtPZH+bvS3E JZPA== X-Gm-Message-State: AOJu0Yzkj4/tzeH9zIybJt163rXyMHcso8+uQGfvVuP3Hl5jNmUPooSu RcIMnYPAlW/6Bkq1di41jUA= X-Google-Smtp-Source: AGHT+IGqOIIFTBFVetx7qil0B4emy3ziXw9A6fqOq/7Cqe2irw/ss5qjNwsZR/WvwkPsr58ZavYPMw== X-Received: by 2002:a17:902:f682:b0:1cc:7d96:3fe7 with SMTP id l2-20020a170902f68200b001cc7d963fe7mr10707746plg.28.1699079322405; Fri, 03 Nov 2023 23:28:42 -0700 (PDT) Original-Received: from localhost ([115.240.90.130]) by smtp.gmail.com with ESMTPSA id j15-20020a170902da8f00b001c5fe217fb9sm2269057plx.267.2023.11.03.23.28.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Nov 2023 23:28:41 -0700 (PDT) In-Reply-To: (Stefan Monnier via's message of "Sat, 04 Nov 2023 02:14:46 -0400") 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:273743 Archived-At: [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=A8=E0=AE=B5=E0=AE=AE=E0=AF=8D=E0=AE=AA= =E0=AE=B0=E0=AF=8D 04, 2023] Stefan Monnier via "Bug reports for GNU Emacs,= the Swiss army knife of text editors" wrote: >>> Could you describe the circumstance where you need it? >> We need to get the func-arity of the original function and not its >> advice. > > That's the part I'd been (indirectly) told already. What I meant was > why do you need to find the arity of that(those) function(s)? Sure, in Philip's package do-at-point, a function defined to "act" on the `thing' at point are given different arguments depending on the minimum number of arguments required by the function: (let* ((thing (overlay-get do-at-point--overlay 'do-at-point-thing)) (options (do-at-point--actions thing)) (choice ...) (func (cadr (alist-get (car choice) options))) (bound (cons (overlay-start do-at-point--overlay) (overlay-end do-at-point--overlay)))) (when func (pcase (car (func-arity func)) ^^^^^^^^^^^^^^^^^ (0 (funcall func)) (1 (funcall func (buffer-substring (car bound) (cdr bound)))) (2 (funcall func (car bound) (cdr bound))) (_ (error "Unsupported signature: %S" func))))) Currently the func-arity call fails when the function is adviced. This is a nice format to follow since it 1. allows reuse of existing functions to be executed as actions without the need for wrapper functions=20 [ i.e., (lambda (str) (xref-find-definitions str)) ] 2. allows the "action" function to specify what it ends by changing its required arguments. I hope this is clear. >> (func-arity (advice--cd*r (indirect-function 'xref-find-definitions)= )) ;; =E2=87=92 (1 . 1) >> >> which is the right return value. It might be nice to not have to call >> `indirect-function' here for the "global" function but you can be a >> better judge of that. > > Don't know what you mean by "global" function. By "global", I mean the new global function advice-cd*r or somesuch that might eventually be added from this discussion. > Side note: an advice may also be installed specifically to change the > arity, e.g. to add support for some new calling convention. Ahhhhhh... now we have a complication that I never thought about. >> In our case, the functions that will be checked for its arity should be >> defined at the time of func-arity call. Or at least auto-loaded AFAIU. > > By "autoloaded" do you mean "setup to be loaded on demand but not yet > loaded", or do you mean "had been setup to be loaded on demand and has > been loaded already"? The former obviously. > The second case is "irrelevant" in the sense that it doesn't matter if > the function had been autoloaded before it was defined. > > > Stefan