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#54802: OClosure: Make `interactive-form` a generic function Date: Mon, 18 Apr 2022 18:59:28 -0400 Message-ID: References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> <83wnfq1fzg.fsf@gnu.org> 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="9430"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 19 01:00:13 2022 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 1ngaLq-0002DF-JI for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Apr 2022 01:00:10 +0200 Original-Received: from localhost ([::1]:49496 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ngaLp-0002Vr-AA for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Apr 2022 19:00:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ngaLj-0002Vf-3k for bug-gnu-emacs@gnu.org; Mon, 18 Apr 2022 19:00:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47165) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ngaLi-0002xn-QP for bug-gnu-emacs@gnu.org; Mon, 18 Apr 2022 19:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ngaLi-0005Vs-KG for bug-gnu-emacs@gnu.org; Mon, 18 Apr 2022 19:00: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 Apr 2022 23:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54802 X-GNU-PR-Package: emacs Original-Received: via spool by 54802-submit@debbugs.gnu.org id=B54802.165032277921138 (code B ref 54802); Mon, 18 Apr 2022 23:00:02 +0000 Original-Received: (at 54802) by debbugs.gnu.org; 18 Apr 2022 22:59:39 +0000 Original-Received: from localhost ([127.0.0.1]:41062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngaLK-0005Us-Ow for submit@debbugs.gnu.org; Mon, 18 Apr 2022 18:59:39 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngaLJ-0005Ue-0z for 54802@debbugs.gnu.org; Mon, 18 Apr 2022 18:59:37 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 45218100184; Mon, 18 Apr 2022 18:59:31 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B53AC10002F; Mon, 18 Apr 2022 18:59:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1650322769; bh=nawPIIWVt3Ki7HQPPRH2j7+ZoSpeH+2/OMftddq1Nfc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=RvM0LRg36ssvY2NGDsASJNfD0fKtFc/qosn9+q06DAt6z2nS9csYC7GEGnSBSYjGj jyfq97LFSJsA4xFY8bQPb8G9o6xkmhaT5ABE33H8qUA+w2lnFHViYz6F3uagrJKrml 9z2Tyn/kUqXJ0c7DRMpFtZII+nrkhwlE6NCh9wLEsRRLAvzwF3C041e2CSbtBoJVWr fuVdTKUXq7lSm0GEinT6DV02VsI06UvYWeCOffnPUy5PXqve3CvozbtuRsMZd2+LGi bMeXkVVrqVhbS8JzcWLamhIOTuXxANPs0jeQMKy6+KS2IFmu6zagE7TTNferRUYdnC 532jMT8p/6vCg== Original-Received: from alfajor (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7CFD6120680; Mon, 18 Apr 2022 18:59:29 -0400 (EDT) In-Reply-To: <83wnfq1fzg.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Apr 2022 19:14:11 +0300") 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" Xref: news.gmane.io gmane.emacs.bugs:230209 Archived-At: Eli Zaretskii [2022-04-15 19:14:11] wrote: > As I said up-thread, I don't understand why we need to touch > interactive-form at all. In my experience, OClosures fall into two camps: - Those, like `advice`, where their interactive form depends on some of the data carried by the OClosure. - Those, like `kmacro`, where all the OClosures of that type have the same, constant, interactive form. For the second group, we can use the current `interactive-form`, with the only downside that every OClosure of that type will have to carry its own reference to that same interactive form. For the first, it's much more problematic: see for example the function `advice--make-1`. There we build a new byte-code function with is a composition of a base function with an advice function. We currently do it by hand out of its actual bytecode string, constant vector, ... The interactive form of the composed function should be a combination of the interactive forms of the two functions (so that an advice can advise also the interactive form of a function), which is computed by `advice--make-interactive-form`. When working at that level, the interactive form can be computed dynamically fairly easily, but there are some problems: - This is messy because we have to dig inside the representation of byte code objects. The use of OClosures would be able to save us from that. - `oclosure.el` can't use the same trick we currently use in `advice--make-1` because it lets the byte compiler build the byte-code objects for us and the byte-compiler's code doesn't know how to build a bytecode object whose interactive-spec is not just an immediate constant. - Doing it like we do in `advice--make-1` computes the interactive form too early: if the base function (or the advice function, but that's less likely) is an autoloaded function, it will eagerly load the file when the advice is applied. Also if that base function is an alias, it will use the interactive form of the current definition of the alias and won't be updated if the alias is later redefined. There are various ways to work around those problems, but the cleanest fix is to delay the computation of the interactive form to the moment `interactive-form` is called. Stefan