From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#62563: [FR] Expose `interactive' arg handling as an Elisp function Date: Mon, 18 Sep 2023 06:28:14 +0200 Message-ID: <875y486r6p.fsf@web.de> References: <83lejd2wwi.fsf@gnu.org> <87bke1d3nf.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6639"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62563@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 18 06:29:13 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 1qi5sm-0001aN-TE for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Sep 2023 06:29:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qi5sZ-0006Se-0q; Mon, 18 Sep 2023 00:28:59 -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 1qi5sV-0006SQ-1b for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 00:28:55 -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 1qi5sU-0007Ji-Pa for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 00:28:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qi5sc-0000OX-Ng for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 00:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Sep 2023 04:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62563 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 62563-submit@debbugs.gnu.org id=B62563.16950113161474 (code B ref 62563); Mon, 18 Sep 2023 04:29:02 +0000 Original-Received: (at 62563) by debbugs.gnu.org; 18 Sep 2023 04:28:36 +0000 Original-Received: from localhost ([127.0.0.1]:51820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qi5sB-0000Ni-Kb for submit@debbugs.gnu.org; Mon, 18 Sep 2023 00:28:36 -0400 Original-Received: from mout.web.de ([212.227.15.14]:36375) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qi5s5-0000NK-Rx for 62563@debbugs.gnu.org; Mon, 18 Sep 2023 00:28:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1695011295; x=1695616095; i=michael_heerdegen@web.de; bh=8rPGd+V8NfleNwRRqoPqBBkRQCBi51wSPafvNbreNk4=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=KoAWMi37FUkUlbQGHFsPjH0uI3MtFJ8oDxaMh3Y3KlESHt7Sdit+/nbD2eFV9EWiD14AiQTYRbv 2DZNXW+qjuR11gSLOGcpizB3ldnS0G2gsWiYgOlxPT27XvPBYDZ0oCpbFfI4lnAYqNjwxl88fOw25 iwrO5QJfZJohSotQNIMvnB8GRpQPM3D7zaApeIk7dx74fHZSJXIANE08JOlw7KSUa7E+UhkW6WXjx H2oMQ5uqgAQmpQhTnCzpMnpxXeRfShkLCt1LS5cVNs/grPDmOEPTnAMizFpMcqAVVXywzzw2EnRfV s0X//r5dvxlFwt/9YpMhV9TgD5cNC52DZ/ag== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([88.66.201.191]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MOUtm-1r4ZST0xUk-00PzWH; Mon, 18 Sep 2023 06:28:15 +0200 In-Reply-To: (Stefan Kangas's message of "Sun, 17 Sep 2023 04:31:57 -0700") X-Provags-ID: V03:K1:TTmw+6/R0KKBiJ1I2IAYA0t5mo0yx+6fXq37uYNK5fXxpaPEPLS kox4qxQy7GZgqCDSbfYTfSzY1pTwtZeW7LFR1xSaJwBHX6FvpXsalpT5ox7FGRnDlDlTy65 S3FVlEtNn0dMe7vwDdfP9cznOXuDlLDQHUB3YyChOBofA3Vjg2m752gQgWxrrpVbEPvz7vj Fa3OauPhp/YPr9AYCAdQQ== UI-OutboundReport: notjunk:1;M01:P0:z6nRjfEV04E=;qgeWO8SmazaL3gSgW97t+Y16e9e UjHcdGUC+kjVURYBq4vVUZ9+qKzuDRPCfIGDhgT1KrltdLk+NcfhB3z5oXAQETrd6WSTlmrm+ EiQC+/Nle+PVExUBwVGNZZr1l0I+/bFQAPa68pf0a9eg0bT3F3+0D6ECPdf91sMk8MnYBRrD0 Nlvja6HZlVNh9pHBbtxoAhgwhYXwaDHSz3mDGF/I0vKhsUe9fRDKfpu5D2zwht7hc7FRcAIcn zCkomnKB97iL7t+l7Rn21TexIXnv46l+klkGViiOLGg0odFYx2888xC1j8j182y8S/ch+pRur ZfEZmWBY4aTYwXt4v9Zw+k6WGd2egT1xTuBchOba0CeauwT9VVzue68+XLNxo4pOy6vENahfQ a6HvM1Ta+TJ1A5/31e94SHKvBgT+xty98CjNv5Q/xmf1Lwtzj9DfonJGK7rzgLWZSvbgHv5E6 aysj/9G3A4iF+vhGuPCcq5Awd4oScxyFZ6VRKoWBuWJrv63s6e8fC/KMp6ssdUHg5LURsUuw2 uenvgQ4bvPgirNxvsNH30i/B+68dv7uJVW91VEXzO87Z793sbVuJpnAxbUAZJE3wEiiC6WI2k kBui9UfEfjkBEEH7C5XTPUfJxiW98SjlKjCwnc4v2rplJp86XspwHQ1yWLrFMZNXuOsrSfcu9 HsQoAJBhEkJV7ykZy5d63Pp7ZoK0X7dZVYhF9SaquYKL1lII6carful6Dg/rs9Z6GLE4UF0B4 Q4ryhW9QKzfSNJ4rBiefll6oLhKS0i73IA3S4vBGduqjTZ5HjhLO16goxzvddiFIhN7S2zzi 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:270742 Archived-At: Stefan Kangas writes: > Could you point to one (or more) examples of real code that would have > been made significantly simpler by this? The idea sounds good in > theory, but it is important to understand if it will also be useful in > practice. That will give us a better basis for deciding if this is > something we would want to add or not. [ Note I only asked about renaming `advice-eval-interactive-spec' to `eval-interactive-spec', not about adding something new. Because the function is not only useful in nadvice.el. Dunno if I made that clear. ] People can of course already use the name `advice-eval-interactive-spec' - but it is probably not well known. Ehm - examples, ok. Whenever a package or config file wants to define a variant of an existing command that needs to read in the same arguments in the same order (i.e. the user wants to have multiple commands instead of one, an additional definition, not an advice), one has to copy the interactive spec of the original definition. Or one can use `advice-eval-interactive-spec'. The body of the variant also may or may not reuse the other function. This is all very similar to defining advices - only that it doesn't involve an advice, as I described. When the variant of an existing command wants to skip reading one argument, `advice-eval-interactive-spec' is not of much use. But the same is true of advices of interactive functions that want to skip reading an argument. In the Emacs sources it's possible to factor the interactive spec out into its own defun and reuse it in several places. So this kind of use case is mostly relevant for external packages and user configurations. Ok, you wanted a real life example. In my init file I have a command like this: #+begin_src emacs-lisp (defun my-dired-restrict-marks () "Restrict marks using the following command. Only files that are currently marked and are marked again with the subsequent command will be marked afterwards. Thereby only `dired-marker-char' marked files are considered - other marks are not touched. The next key sequence can optionally be prefixed with key ! to mean \"not\" - then only marked files that would _not_ be marked again with the next command keep their mark [...] ... ) #+end_src That way I can combine several marking commands to have files marked fulfill more than one condition. If I bind the above command to `&', I can use * / & * % to mark directories whose name is matched by a certain regexp, for example. The implementation saves the current file marks, reads a key sequence, determines the bound command, then evals the interactive spec to get the arguments (it is better to do this using the original buffer state, this is the important part here). Then all marks are removed, the command is called with the read in arguments (simply using `apply'), then the marks are merged with the remembered marks. A similar case is my command `my-profiler-profile-next-command': It similarly reads in a key sequence and the according arguments using the interactive spec, but only after that starts the profiler and calls the body of the command. This is nice if you want to avoid that the argument reading messes the profiler results of the command's code. Yes, such things, but admittedly, the large majority of calls of `advice-eval-interactive-spec' is still for defining advices. I also want to add that what I describe here is related, but not the same as the request in the original report which, AFAIU, more asked about a convenient way to simulate (interactive "f") conveniently from Lisp. If we would have access to the code reading in the individual arguments that would be even nicer, but it's not possible in the general case because the interactive spec returns a list that is the result of any arbitrary code that returns a list (i.e. there is no separate code for each single argument in every case). I let you decide whether my examples are enough to justify this renaming. There are probably not that many use cases, still, there are a few. Michael.