From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 08 16:34:09 2022 Received: (at submit) by debbugs.gnu.org; 8 Apr 2022 20:34:09 +0000 Received: from localhost ([127.0.0.1]:36058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncvJ2-0006xe-MD for submit@debbugs.gnu.org; Fri, 08 Apr 2022 16:34:09 -0400 Received: from lists.gnu.org ([209.51.188.17]:35098) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncvJ0-0006xW-Mo for submit@debbugs.gnu.org; Fri, 08 Apr 2022 16:34:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38074) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncvJ0-0000iC-Gn for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2022 16:34:06 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56733) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncvIw-0004o9-Ml for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2022 16:34:05 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 54190807BA for ; Fri, 8 Apr 2022 16:34:00 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D147480664 for ; Fri, 8 Apr 2022 16:33:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1649450037; bh=KkyrUsE97Pf9aY2agftDjnoEk+hNj+jdHxpGMlAdfbQ=; h=From:To:Subject:Date:From; b=VbHdiV3dBG5uUTxQPy6Urh7EabqHfBWzoHamFLO/w6RCJ5oKFYQC9Nb89p9C9ZwUJ jkmm3t15Bf55rqIUa/nZPfVOk5/4nASmcVUAX+gtWpZrfjvfglksiQKMo/kHsT/ICM Wlg0jLjQsu4cLBLv4A+0hWZo1XK1PnwwcRr15Szb1KJKNA32tH287DHwOVOMPXYC/5 nyQ+O37738k+NFvgKSvl4EDVerL+8sO3YB77Kd56I/XozYbnizAVapRzb5JdKgywDd SMl5XJQS2SbLTlkX06AaJCJSEsLPuPQrlM8cOlHDUA5tLOXPJXXf/pw6NsRvYYZrAW ryqN0GGZiFFxQ== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ABC561204B0 for ; Fri, 8 Apr 2022 16:33:57 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: OClosure: Make `interactive-form` a generic function Date: Fri, 08 Apr 2022 16:33:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.059 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Package: Emacs Version: 29.0.50 `nadvice.el` needs to build commands whose interactive spec is computed. This currently can't be done with `lambda` (see also bug#51695 for a related problem) but `nadvice.el` is unaffected because it assembles its byte-code functions all by hand. In order for `nadvice.el` to be able to use OClosures, we need to address this limitation. The patch below does it by making `interactive-form` a generic function, so OClosures can compute their interactive specs from their slots. Maybe it should be `call-interactively` that's turned into a generic function (which would also open up the possibility to do more than just compute the args to pass to the function, such as also printing the return value or things like that), but that would be a more significant change. While the performance of `call-interactively` and `interactive-form` are not critical, `commandp` is a function that is occasionally used in tight loops (typically when filtering completions from `obarray`) so I refrained from making it into a generic function, and instead I make it defer to `interactive-form` when we counter what looks like an OClosure. That keeps the common code as fast as before, tho it makes `commandp` slow(ish) when applied to interactive OClosures. Making `commandp` into a generic function would apparently slow down a loop like (mapatoms (lambda (s) (if (commandp s) (cl-incf count)))) by a factor around 2x or 3x, which is not the end of the world but doesn't seem justified. The patch below also includes a use of this new generic function by moving the interactive spec of kmacros from the kmacro objects themselves to the generic function. The gain is that each `kmacro` is now 1 word smaller (negligible, in the grand scheme of things, but I included it for illustration and testing purposes). Any commment? Objection? Stefan diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi index 74bf0f48692..eb29fd0044c 100644 --- a/doc/lispref/commands.texi +++ b/doc/lispref/commands.texi @@ -312,6 +312,8 @@ Using Interactive specifies how to compute its arguments. Otherwise, the value is @code{nil}. If @var{function} is a symbol, its function definition is used. +This is a generic function, so additional methods can be used +for specific function types, e.g. for advice and keyboard macros. @end defun =20 @node Interactive Codes diff --git a/etc/NEWS b/etc/NEWS index 1043873f2d7..3728f9a9231 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1341,6 +1341,11 @@ Can dynamically generate a raw docstring depending o= n the type of a function. Used mainly for docstrings of OClosures. =20 ++++ +** 'interactive-form' is now a generic function. +This allows specific OClosure types to compute their interactive specs +on demand rather than precompute them when created. + +++ ** Base64 encoding no longer tolerates latin-1 input. The functions 'base64-encode-string', 'base64url-encode-string', diff --git a/lisp/kmacro.el b/lisp/kmacro.el index 8a9d89929eb..9aaf90e0f5a 100644 --- a/lisp/kmacro.el +++ b/lisp/kmacro.el @@ -820,13 +820,14 @@ kmacro (counter (or counter 0)) (format (or format "%d"))) (&optional arg) - (interactive "p") ;; Use counter and format specific to the macro on the ring! (let ((kmacro-counter counter) (kmacro-counter-format-start format)) (execute-kbd-macro keys arg #'kmacro-loop-setup-function) (setq counter kmacro-counter)))) =20 +(cl-defmethod interactive-form ((_ kmacro) &optional _) '(interactive "p")) + ;;;###autoload (defun kmacro-lambda-form (mac &optional counter format) ;; Apparently, there are two different ways this is called: diff --git a/lisp/simple.el b/lisp/simple.el index eb657018039..f14da3d6d74 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -2389,6 +2389,39 @@ function-documentation (cl-defmethod function-documentation ((function accessor)) (oclosure--accessor-docstring function)) ;; FIXME: =CE=B7-reduce! =20 +(cl-defgeneric interactive-form (cmd &optional original-name) + "Return the interactive form of CMD or nil if none. +If CMD is not a command, the return value is nil. +Value, if non-nil, is a list (interactive SPEC). +ORIGINAL-NAME is used internally only." + (pcase cmd + ((pred symbolp) + (let ((fun (indirect-function cmd))) ;Check cycles. + (when fun + (or (get cmd 'interactive-form) + (interactive-form (symbol-function cmd) + (or original-name cmd)))))) + ((pred byte-code-function-p) + (when (> (length cmd) 5) + (let ((form (aref cmd 5))) + (list 'interactive + (if (vectorp form) + ;; The vector form is the new form, where the first + ;; element is the interactive spec, and the second + ;; is the "command modes" info. + (aref form 0) + form))))) + ((pred autoloadp) + (interactive-form (autoload-do-load cmd original-name))) + ((or `(lambda ,_args . ,body) + `(closure ,_env ,_args . ,body)) + (let ((spec (assq 'interactive body))) + (if (cddr spec) + ;; Drop the "command modes" info. + (list 'interactive (cadr spec)) + spec))) + (_ (internal--interactive-form cmd)))) + (defun command-execute (cmd &optional record-flag keys special) ;; BEWARE: Called directly from the C code. "Execute CMD as an editor command. diff --git a/src/callint.c b/src/callint.c index 31919d6bb81..92bfaf8d397 100644 --- a/src/callint.c +++ b/src/callint.c @@ -315,7 +315,7 @@ DEFUN ("call-interactively", Fcall_interactively, Scall= _interactively, 1, 3, 0, Lisp_Object up_event =3D Qnil; =20 /* Set SPECS to the interactive form, or barf if not interactive. */ - Lisp_Object form =3D Finteractive_form (function); + Lisp_Object form =3D call1 (Qinteractive_form, function); if (! CONSP (form)) wrong_type_argument (Qcommandp, function); Lisp_Object specs =3D Fcar (XCDR (form)); diff --git a/src/data.c b/src/data.c index f06b561dcc6..888e3f66b27 100644 --- a/src/data.c +++ b/src/data.c @@ -1065,29 +1065,12 @@ DEFUN ("native-comp-unit-set-file", Fnative_comp_un= it_set_file, =20 #endif =20 -DEFUN ("interactive-form", Finteractive_form, Sinteractive_form, 1, 1, 0, - doc: /* Return the interactive form of CMD or nil if none. +DEFUN ("internal--interactive-form", Finternal__interactive_form, Sinterna= l__interactive_form, 1, 1, 0, + doc: /* Return the interactive form of FUN or nil if none. If CMD is not a command, the return value is nil. Value, if non-nil, is a list (interactive SPEC). */) - (Lisp_Object cmd) + (Lisp_Object fun) { - Lisp_Object fun =3D indirect_function (cmd); /* Check cycles. */ - - if (NILP (fun)) - return Qnil; - - /* Use an `interactive-form' property if present, analogous to the - function-documentation property. */ - fun =3D cmd; - while (SYMBOLP (fun)) - { - Lisp_Object tmp =3D Fget (fun, Qinteractive_form); - if (!NILP (tmp)) - return tmp; - else - fun =3D Fsymbol_function (fun); - } - if (SUBRP (fun)) { if (SUBR_NATIVE_COMPILEDP (fun) && !NILP (XSUBR (fun)->native_intspe= c)) @@ -1099,21 +1082,6 @@ DEFUN ("interactive-form", Finteractive_form, Sinter= active_form, 1, 1, 0, (*spec !=3D '(') ? build_string (spec) : Fcar (Fread_from_string (build_string (spec), Qnil, Qnil))); } - else if (COMPILEDP (fun)) - { - if (PVSIZE (fun) > COMPILED_INTERACTIVE) - { - Lisp_Object form =3D AREF (fun, COMPILED_INTERACTIVE); - if (VECTORP (form)) - /* The vector form is the new form, where the first - element is the interactive spec, and the second is the - command modes. */ - return list2 (Qinteractive, AREF (form, 0)); - else - /* Old form -- just the interactive spec. */ - return list2 (Qinteractive, form); - } - } #ifdef HAVE_MODULES else if (MODULE_FUNCTIONP (fun)) { @@ -1123,24 +1091,6 @@ DEFUN ("interactive-form", Finteractive_form, Sinter= active_form, 1, 1, 0, return form; } #endif - else if (AUTOLOADP (fun)) - return Finteractive_form (Fautoload_do_load (fun, cmd, Qnil)); - else if (CONSP (fun)) - { - Lisp_Object funcar =3D XCAR (fun); - if (EQ (funcar, Qclosure) - || EQ (funcar, Qlambda)) - { - Lisp_Object form =3D Fcdr (XCDR (fun)); - if (EQ (funcar, Qclosure)) - form =3D Fcdr (form); - Lisp_Object spec =3D Fassq (Qinteractive, form); - if (NILP (Fcdr (Fcdr (spec)))) - return spec; - else - return list2 (Qinteractive, Fcar (Fcdr (spec))); - } - } return Qnil; } =20 @@ -4255,7 +4205,7 @@ #define PUT_ERROR(sym, tail, msg) \ DEFSYM (Qbyte_code_function_p, "byte-code-function-p"); =20 defsubr (&Sindirect_variable); - defsubr (&Sinteractive_form); + defsubr (&Sinternal__interactive_form); defsubr (&Scommand_modes); defsubr (&Seq); defsubr (&Snull); diff --git a/src/eval.c b/src/eval.c index a1cebcd0257..35a9f70d7b5 100644 --- a/src/eval.c +++ b/src/eval.c @@ -2032,8 +2032,7 @@ DEFUN ("commandp", Fcommandp, Scommandp, 1, 2, 0, (Lisp_Object function, Lisp_Object for_call_interactively) { register Lisp_Object fun; - register Lisp_Object funcar; - Lisp_Object if_prop =3D Qnil; + bool genfun =3D false; /* If true, we should consult `interactive-form`.= */ =20 fun =3D function; =20 @@ -2041,52 +2040,92 @@ DEFUN ("commandp", Fcommandp, Scommandp, 1, 2, 0, if (NILP (fun)) return Qnil; =20 - /* Check an `interactive-form' property if present, analogous to the - function-documentation property. */ - fun =3D function; - while (SYMBOLP (fun)) - { - Lisp_Object tmp =3D Fget (fun, Qinteractive_form); - if (!NILP (tmp)) - if_prop =3D Qt; - fun =3D Fsymbol_function (fun); - } - /* Emacs primitives are interactive if their DEFUN specifies an interactive spec. */ if (SUBRP (fun)) - return XSUBR (fun)->intspec ? Qt : if_prop; - + { + if (XSUBR (fun)->intspec) + return Qt; + } /* Bytecode objects are interactive if they are long enough to have an element whose index is COMPILED_INTERACTIVE, which is where the interactive spec is stored. */ else if (COMPILEDP (fun)) - return (PVSIZE (fun) > COMPILED_INTERACTIVE ? Qt : if_prop); + { + if (PVSIZE (fun) > COMPILED_INTERACTIVE) + return Qt; + else if (PVSIZE (fun) > COMPILED_DOC_STRING) + genfun =3D true; + } =20 #ifdef HAVE_MODULES /* Module functions are interactive if their `interactive_form' field is non-nil. */ else if (MODULE_FUNCTIONP (fun)) - return NILP (module_function_interactive_form (XMODULE_FUNCTION (fun))) - ? if_prop - : Qt; + { + if (!NILP (module_function_interactive_form (XMODULE_FUNCTION (fun))= )) + return Qt; + } #endif =20 /* Strings and vectors are keyboard macros. */ - if (STRINGP (fun) || VECTORP (fun)) + else if (STRINGP (fun) || VECTORP (fun)) return (NILP (for_call_interactively) ? Qt : Qnil); =20 /* Lists may represent commands. */ - if (!CONSP (fun)) + else if (!CONSP (fun)) return Qnil; - funcar =3D XCAR (fun); - if (EQ (funcar, Qclosure)) - return (!NILP (Fassq (Qinteractive, Fcdr (Fcdr (XCDR (fun))))) - ? Qt : if_prop); - else if (EQ (funcar, Qlambda)) - return !NILP (Fassq (Qinteractive, Fcdr (XCDR (fun)))) ? Qt : if_prop; - else if (EQ (funcar, Qautoload)) - return !NILP (Fcar (Fcdr (Fcdr (XCDR (fun))))) ? Qt : if_prop; + else + { + Lisp_Object funcar =3D XCAR (fun); + if (EQ (funcar, Qautoload)) + { + if (!NILP (Fcar (Fcdr (Fcdr (XCDR (fun)))))) + return Qt; + } + else + { + Lisp_Object body =3D CDR_SAFE (XCDR (fun)); + if (EQ (funcar, Qclosure)) + body =3D CDR_SAFE (body); + else if (!EQ (funcar, Qlambda)) + return Qnil; + if (!NILP (Fassq (Qinteractive, body))) + return Qt; + else + { + Lisp_Object first =3D CAR_SAFE (body); + if (!NILP (CDR_SAFE (body)) + && (STRINGP (first) || FIXNUMP (first) || + FIXNUMP (CDR_SAFE (first)))) + genfun =3D true; + } + } + } + + /* By now, if it's not a function we already returned nil. */ + + /* Check an `interactive-form' property if present, analogous to the + function-documentation property. */ + fun =3D function; + while (SYMBOLP (fun)) + { + Lisp_Object tmp =3D Fget (fun, Qinteractive_form); + if (!NILP (tmp)) + error ("Found an `interactive-form` property!"); + fun =3D Fsymbol_function (fun); + } + + /* If there's no immediate interactive form but there's a docstring, + then delegate to the generic-function in case it's an FCR with + a type-specific interactive-form. */ + if (genfun + /* Avoid burping during bootstrap. */ + && !NILP (Fsymbol_function (Qinteractive_form))) + { + Lisp_Object iform =3D call1 (Qinteractive_form, fun); + return NILP (iform) ? Qnil : Qt; + } else return Qnil; } From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 09 01:58:04 2022 Received: (at 54802) by debbugs.gnu.org; 9 Apr 2022 05:58:05 +0000 Received: from localhost ([127.0.0.1]:36566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nd46m-0006aH-Jj for submit@debbugs.gnu.org; Sat, 09 Apr 2022 01:58:04 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nd46k-0006Zk-B8 for 54802@debbugs.gnu.org; Sat, 09 Apr 2022 01:58:03 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39800) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd46e-0001rY-AH; Sat, 09 Apr 2022 01:57:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=yRCkC2niwfMtCRHxbdTPSmc3FYgaBYs1zsJrHPwT7Ts=; b=PzAG5AVMrEPX LeE+b7SFe9LuC7vynxCgNepCswRDsOOi7lhI5Z9HyBFywGcCfXy3XzTH/FJ19ffxCMn4XzGMAVYr1 bom1neKieySmodFg2A0b/s4lgdgGyFJhq3nsGN4qi9WZQWP/PjX/mifC5sz0JoHsML7CqZZUyCFvM HJ925CqqYry09EVfRkU7YC/jg5aNLUzU4pYFBRYaEuhq8wghJvuBAzW+H9ynap5fpMSGt7qSxMtrn 3WOAohP31v8qR5NtPMQX2LFdzSHNYtV/b4tqT9HaldljyoFtTrCv8j61PF/EgxYIFrXHGThWBKNsw vi9Wxjhb2zG6FOqwX5vZsg==; Received: from [87.69.77.57] (port=1079 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd46d-0006Wa-PZ; Sat, 09 Apr 2022 01:57:56 -0400 Date: Sat, 09 Apr 2022 08:58:09 +0300 Message-Id: <83czhqajda.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 08 Apr 2022 16:33:51 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > `nadvice.el` needs to build commands whose interactive spec is computed. > This currently can't be done with `lambda` (see also bug#51695 for > a related problem) but `nadvice.el` is unaffected because it assembles > its byte-code functions all by hand. In order for `nadvice.el` to be > able to use OClosures, we need to address this limitation. > > The patch below does it by making `interactive-form` a generic function, > so OClosures can compute their interactive specs from their slots. > > Maybe it should be `call-interactively` that's turned into a generic > function (which would also open up the possibility to do more than just > compute the args to pass to the function, such as also printing the > return value or things like that), but that would be a more significant > change. > > While the performance of `call-interactively` and `interactive-form` are > not critical, `commandp` is a function that is occasionally used in > tight loops (typically when filtering completions from `obarray`) so > I refrained from making it into a generic function, and instead I make > it defer to `interactive-form` when we counter what looks like an OClosure. > > That keeps the common code as fast as before, tho it makes `commandp` > slow(ish) when applied to interactive OClosures. > > Making `commandp` into a generic function would apparently slow down > a loop like > > (mapatoms (lambda (s) (if (commandp s) (cl-incf count)))) > > by a factor around 2x or 3x, which is not the end of the world but > doesn't seem justified. > > The patch below also includes a use of this new generic function by > moving the interactive spec of kmacros from the kmacro objects > themselves to the generic function. The gain is that each `kmacro` is > now 1 word smaller (negligible, in the grand scheme of things, but > I included it for illustration and testing purposes). > > Any commment? Objection? My comment is that when you introduced OClosures, you never said that the plan was to go over every place in Emacs where they can be used and reimplement those places based on OClosures. It sounds like this is what's happening, and next we will see another round of churn of the code we old-timers are familiar with to make it utterly unfamiliar and dependent on stuff that needs to be carefully studied before it can even be understood? Including basic internals such as interactive-form and its ilk? All that to solve some minor issues with nadvice, which itself is a minor feature as Emacs features go? Doesn't that sound excessive? I'm okay with having OClosures, yet another new feature of Emacs Lisp, but I don't think I like seeing stuff like interactive-form rewritten to be generics or having OClosures in general permeate our internals. And speed is only one (important) aspect of that: I'd also like to keep those internals easier understandable by people like myself, who aren't and will never be CS professionals with special interest in functional languages. If that means bug#51695 must be solved some other way, or even remain unsolved, I think I'd prefer that if this is the price. I'm sorry to sound like keeping progress from happening, but it lately becomes more and more hard to do Emacs maintenance due to excessive use of new features whose tricky and hard-to-debug code makes finding the reasons for problems harder and harder. We already have areas where no one can suggest safe solutions for problems. Do we really want those areas to grow and multiply? IMNSHO, Emacs is not a platform for programming language development, it is mainly a platform for writing useful applications. Let's not go overboard with new Lisp features in a way that makes our main task harder than it has to be. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 09 09:50:12 2022 Received: (at 54802) by debbugs.gnu.org; 9 Apr 2022 13:50:12 +0000 Received: from localhost ([127.0.0.1]:37008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ndBTg-00012F-IO for submit@debbugs.gnu.org; Sat, 09 Apr 2022 09:50:12 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ndBTe-00011x-67 for 54802@debbugs.gnu.org; Sat, 09 Apr 2022 09:50:10 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 39E8A805CC; Sat, 9 Apr 2022 09:50:04 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B87918005E; Sat, 9 Apr 2022 09:50:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1649512202; bh=Tl3bpGMaeUvJbU14D/wDZjfwU+WAmdqSmdFFUBe+Asc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hFs+VdBKw05VJhNRXDtCMjSg6SvsC5kXN9bYBph3yjKMV9wS5EhQfxbkHq9iAgx2R n9q9nmxFy5DcMcqSQne1/BN+++svGrjeNVF/K+1n0nWzlQeC9I6fxTO2R6d0qM1fDi UDHH2eZPuVEKl44Ey+nVW89RiXx13TlEJ8nXJP2a9e1R57tnAOzWMfFjwCyIMh9oxC cCkgiKypgfcqE7ZMlT9MBXBgH6wz26co6xnC1qMM69AnI0ScdmnzBHTgag1LkW6fxN JlhF6JSzBNDylmMH+Mvkvp7am8SQMrfN5zWW3D7kpH0q1bB17dL461vN/2sD4glU2/ jmqGwSjxpZH/Q== Received: from alfajor (modemcable034.207-20-96.mc.videotron.ca [96.20.207.34]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 896511204A5; Sat, 9 Apr 2022 09:50:02 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function In-Reply-To: <83czhqajda.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Apr 2022 08:58:09 +0300") Message-ID: References: <83czhqajda.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Date: Sat, 09 Apr 2022 09:50:01 -0400 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.059 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > My comment is that when you introduced OClosures, you never said that > the plan was to go over every place in Emacs where they can be used > and reimplement those places based on OClosures. I don't understand the above because this patch doesn't make use of OClosures. Instead it adds a bit of flexibility to OClosures (the ability to compute their `interactive-form`). OT1H if I was given a chance to go back in time I probably would define `lambda` as a macro that expands to a (trivial) `oclosure-lambda` and then define `function-documentation` as a function that simply extracts the `documentation` slot of its OClosure argument (and same for `interactive-form`). But given where we are I don't think this will happen and I don't think my patches "go over every place in Emacs where [OClosures] can be used". Instead, I see OClosures only used at a few places where they are beneficial. So far these places are: `kmacro.el`, `nadvice.el`, and `cl-generic.el`. The original motivation behind OClosures was `nadvice.el`. Currently on `master` we use OClosures in `cl-generic.el` and in `kmacro.el`. For `nadvice.el` there is one remaining hurdle which is the handling of the interactive specs, i.e. the subject of this bug report. > All that to solve some minor issues with nadvice, which itself is > a minor feature as Emacs features go? That's the core question, yes (tho I think the improvements in `kmacro.el` and the slight speed up of `cl-generic.el` are a nice side effect for end users). Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 10 08:45:54 2022 Received: (at 54802) by debbugs.gnu.org; 10 Apr 2022 12:45:54 +0000 Received: from localhost ([127.0.0.1]:39726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ndWx0-0006i8-0S for submit@debbugs.gnu.org; Sun, 10 Apr 2022 08:45:54 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ndWwy-0006a2-2G for 54802@debbugs.gnu.org; Sun, 10 Apr 2022 08:45:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=fTak7vkZcHSuPTwC7sNOvR414F+dTTLdjTzcCWrJJkc=; b=QK0vPzvZl6dFs385CKyakMVRJ4 lWtE/srLPppC9edtnlmEZ7tO8lgMsnsa7V0fyjRQ2YW6CxNyxOjHOr4B1QKQUFtPk1mXlkxMRBP5u z7fBq3st5vF8Ujk79qDR2Dna2RNNxkeys0jS4tPMBN2vlMEXZYHWTuHAfRoZe3aox5bc=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ndWwo-0006cw-Gy; Sun, 10 Apr 2022 14:45:44 +0200 From: Lars Ingebrigtsen To: Stefan Monnier Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: X-Now-Playing: Arto Lindsay's _Cuidado Madame_: "Seu pai" Date: Sun, 10 Apr 2022 14:45:41 +0200 In-Reply-To: (Stefan Monnier's message of "Fri, 08 Apr 2022 16:33:51 -0400") Message-ID: <87k0bxp0ne.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stefan Monnier writes: > While the performance of `call-interactively` and `interactive-form` are > not critical, `commandp` is a function that is occasionally used in > tight loops (typically when filtering completions fro [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: > While the performance of `call-interactively` and `interactive-form` are > not critical, `commandp` is a function that is occasionally used in > tight loops (typically when filtering completions from `obarray`) so > I refrained from making it into a generic function, and instead I make > it defer to `interactive-form` when we counter what looks like an OClosure. Makes sense to me. > That keeps the common code as fast as before, tho it makes `commandp` > slow(ish) when applied to interactive OClosures. > > Making `commandp` into a generic function would apparently slow down > a loop like > > (mapatoms (lambda (s) (if (commandp s) (cl-incf count)))) > > by a factor around 2x or 3x, which is not the end of the world but > doesn't seem justified. Yeah, we loop on commandp in a lot of contexts, so keeping it fast is good. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 13 03:54:20 2022 Received: (at 54802) by debbugs.gnu.org; 13 Apr 2022 07:54:20 +0000 Received: from localhost ([127.0.0.1]:51494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1neXpT-0000tP-MW for submit@debbugs.gnu.org; Wed, 13 Apr 2022 03:54:19 -0400 Received: from sonic306-20.consmr.mail.ne1.yahoo.com ([66.163.189.82]:43723) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1neXpR-0000tA-94 for 54802@debbugs.gnu.org; Wed, 13 Apr 2022 03:54:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649836451; bh=+LNjI89JXopt4D3/vnYDi7fVq01RJkPMDUDF3TwmqsE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=hnmsHLNFHnXR2kskbxSxM9XVIWaN6BnKfotx/Yrnor+fF1Iwy4EON9V6hdLivI+ZboNo6gmdyvxFbQrU+G6bQRohBsWy7rT9SXcTD62Qt5sBiCzQskIAhXpwazQ3CfaltHgVL1qE8VPrUcdWSyPzmNXrGpAHeyWC/KdCtrJL0Swxn2azK0/eLdjSSExvKq7gkfndFCiMH7Wwo/qm4bxD8RTJvPQB8XImDzehK1LVUwId3awNKGekw0wTbvB7GGfFLEVg9pTfvEIBCIzKAhunKgCSikv0yAB2ByPEgOfDnBjGm6BNK7AsqRJuMXk95oPf4rTOxEI70QsvikNIgLLigg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649836451; bh=4TI5r+TZk4Y2WIHL0uEm/o/NMhaFLRu5mxcobhUAjwa=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=SBGiH3VfqK30RZlV/RgLEBcsDQuZIPVy00FeH5ucR0lEOWx7TaPe7nZGIEORuk0EX1Jr4nYS8J+eBkJIJuwoyVghfHaJ+DLBc4qjXhhUNII34GF8UEbWYZMFUu3iGpGLD1bgczS7RDq5bzMqP/f4JXyJaiEgseaYP1dU5Od/1n1mheQvngVkH1YWWnehGMO/RhAO6/md0dZfrs9y6WbX1rvkVEq5njxb8yvg46nMXhuDpFAPqTv5MVXo+LnoOnIY3J7/e6l4Tv1twkB4aGEuuuqSNeTbr9y+z42wRhUOkWKJ1SZTMguTKNpzmrgWj+gafH/mVBPTH+DAgQL1j33MIg== X-YMail-OSG: VY9Ds4kVM1l_Z22zBHq4joA_XJgMkr8GVnRkTr6WcBy7yITPFx2eNKyXB8ypkuS HxCqREL3d5PiFQykQOKZcZTXyPfxxYKln91qS9OsMMmzKqHAVXoQ0Sp5M1yAOa2X3YDxLgEDIiMo 6Vq_KJMwx7xOpoo87wYfR.9GKwJTB_REoyXbK0OT8a7SR_ZG.rgZVRDJZX0vyw0GIhub_uzh4im0 P0G6v8dUPs_lBmPWKn3DAzUfMxhBRxhkBLZjH4b7QjagmFSRs1J2OSIj34Mel2NnZxqWV0oAL0aP yI..LdkcGVIHjggekAPQlJTgWVMyDFkQeX_iPSBstZt5Fq2R6snAdgTVGPulofSfvBbe.VL3E8Y6 b9XgjF78BKM_BnY4CGGF5HbrF2buXsStckeyTQEEH8Yt0HQXIBhMPq.MAue1ZQ4gIwOO.osTJRku jfSXX.Dt_SkB2lKkdrtFaY0HPBLz7rdja_uYeGkld9wxkqv1Vg2FLheASHAhrA9EvUSgcS5T8zxB alRzOGymjbDu9gYqIyB6ff5ghTZ6pG.O.QoRbzPjS9RrOfj7yHlg46uP0BM3TZeWaGcKL69GcBeq kWQ7ja7rpHZDfiVagicqM.6EFuey0JLaNa_rO0TJFgoF6eFLwYvIxoxrcDE2rybYbFX0z2sAoEEG StoFpZ8eORzBkRzswWLqdSzZjrH_acu1K8m47OY_2YqD_ZFwFccHZPuyCOKK.zS4.3992hLoZv4a VHcM92VcxiE8d6uXTSukNdxJG76c._jIapn633UI6dNUTkqrb_XAYtCx0CcMubuCN2.x1mNlPQ57 k.fePyBxqNRFUilVLrTegb22_IfTYpY7vWYwmAPl95W0q6rOR3sXd_lMRYkabPTiKpfnlagE47yy M67T9CiwqAAwM2gvFut76jZZXw.YncadgOK0j8lcIc2h3s6t27BPc_3Y2T23zDv9OF0LjULjVoPF 4nMKTVjDNNItFVdNXgOkbQSE1DW0C2p4btMX35x3ZpIMZ.1oYCSwdG7146Y.uolgNTxLU1f8POx2 KxJuA2k6upP3at4qsMNS6q2gLW83JrpKXobw5rdJkkgIvufWVuamKYLWvhVZY1i9COrNRpumh1hE qANqGhtnnM3HCJttIcVnQfs7g5HnqIjSuySkLt5xi_Bd4zBQ_DCgfEUq7P8kk5.Y8nTWohVz.Vb5 IaD3dvJDFgPaPQwflJ0uJgkpv6Rl0p7ZnnemlH2wj1siqYiwOda.pOb0A6eNrQ.3skeHg8C3lHxR iDypdUDZeaT9BC.pG2JCvjt0tS.kqvCkARLoYz1ktkaZOUbBJR3t6wJrhDUTAr8P4_OOEMpaBukL k3XFDXTXvso.HEDWrzMtv3cTa4SRWv_UQ1WsrEyGcAdcFjSfCN.ekwDI0UqImiY6BMZzHYTKzepZ Job4hdGNIN2VqGdWcZ6OFQqRklQ7CZo7mgTpw_gWe9Zl3MMMVqT.rmVHeOK_SdaMEvoQ9BBjqGAI 0sAWskxXFgyP.Ro1l27Ul3k13le1IvU_cPK9xMsehK4TmdJ5dHroPYm_mkhxbmqeG7RNs8Oti9NO oerYK6gRogKZZujSgLn2p2bJK1.h.32GUPI34JMe1UgAhyh7ut5xAO9WgxVvtKY0ahTSubVS5ZFj Qet2qzgPpWzimfCjGv7iDGByqxuYWPGRdMwDeJEX1rB4GvjkdmQIi8GFzdUV7PM2bUVGjiAW4yNE oc0a17YovmEbAXveTbB5T8L._SYAEGKTEt8wzvDlEsvv8btZtWTb0Z1GjSqn938488B.Sw9HwEbi _xhvCfZ5jSlGYDoSjf7QKNUP_4EKwdltSxU9r3vwtmUUrGI6m7FnXPTPFQPehlYHUlvqdO77Qqux Kdti0Hbwr57AJfet6Byu9SJzZj4XYIoA3FnAX181yzjZJzjmS_cpOyttQKiEI3mRtvimTUzmDuF1 lHDGWM3aZNod3WEKwQ0rCTKzCVsRUFMFk0Get2HpqNchV60knxqZW4ekei7TTM9wC9wQlQuAeoa8 gPDPKqADqFntV8FmiQ94Vi2HKlTfCHnt.tjoV_eY8DOyqgUAOD1XTRhi14Vb7YV0exmC4zoX3mPZ xXgRzHSBh7VNpVNHF6pRV0.bVlCPdy2k5ERDQMaNS4Z4Mld_TV_bb7o4IDHp1O7rBxSCFwKfb3_d fFNaBAp7IU8Xerqrize0i7GyQHbJdS0LngMcsUOA7eRasQ3WdY2KI053D111EGez3ocYVP450e.7 ulljbwF6DuFu8ERO5CrMnwk7acfT4MMPlOh4QjxcJ5ET2ZLxWM4ViLe4CXnbe X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Wed, 13 Apr 2022 07:54:11 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-p7hgv (VZM Hermes SMTP Server) with ESMTPA ID 2c6dafb4f4947c8e4b7fd06c0876ef6d; Wed, 13 Apr 2022 07:54:09 +0000 (UTC) From: Po Lu To: Stefan Monnier Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: Date: Wed, 13 Apr 2022 15:53:58 +0800 In-Reply-To: (Stefan Monnier's message of "Fri, 08 Apr 2022 16:33:51 -0400") Message-ID: <87r161to4p.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20001 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2545 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > `nadvice.el` needs to build commands whose interactive spec is computed. > This currently can't be done with `lambda` (see also bug#51695 for > a related problem) but `nadvice.el` is unaffected because it assembles > its byte-code functions all by hand. In order for `nadvice.el` to be > able to use OClosures, we need to address this limitation. > > The patch below does it by making `interactive-form` a generic function, > so OClosures can compute their interactive specs from their slots. > > Maybe it should be `call-interactively` that's turned into a generic > function (which would also open up the possibility to do more than just > compute the args to pass to the function, such as also printing the > return value or things like that), but that would be a more significant > change. > > While the performance of `call-interactively` and `interactive-form` are > not critical, `commandp` is a function that is occasionally used in > tight loops (typically when filtering completions from `obarray`) so > I refrained from making it into a generic function, and instead I make > it defer to `interactive-form` when we counter what looks like an OClosure. > > That keeps the common code as fast as before, tho it makes `commandp` > slow(ish) when applied to interactive OClosures. > > Making `commandp` into a generic function would apparently slow down > a loop like > > (mapatoms (lambda (s) (if (commandp s) (cl-incf count)))) > > by a factor around 2x or 3x, which is not the end of the world but > doesn't seem justified. > > The patch below also includes a use of this new generic function by > moving the interactive spec of kmacros from the kmacro objects > themselves to the generic function. The gain is that each `kmacro` is > now 1 word smaller (negligible, in the grand scheme of things, but > I included it for illustration and testing purposes). > > Any commment? Objection? Calling `interactive-form' in a loop is also fairly common. For example, I wrote some code a while back to list commands which operate on the region, which involves running this on each interned atom: (defun region-command-p (command) "Test if COMMAND, a symbol, is a command that accepts a region." (and (commandp command) (equal (cadr (interactive-form command)) "r"))) I'm sure a 3x slowdown would be noticeable, so why does this have to be a generic function? Why can't we have `interactive-form' return some field of a given OClosure object instead? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 14 14:34:44 2022 Received: (at 54802) by debbugs.gnu.org; 14 Apr 2022 18:34:44 +0000 Received: from localhost ([127.0.0.1]:57365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nf4Il-0007wd-OP for submit@debbugs.gnu.org; Thu, 14 Apr 2022 14:34:44 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46790) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nf4Ik-0007wL-9S for 54802@debbugs.gnu.org; Thu, 14 Apr 2022 14:34:42 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 761E88062B; Thu, 14 Apr 2022 14:34:36 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BC21680570; Thu, 14 Apr 2022 14:34:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1649961274; bh=tXAB/9wriBE9cQLrkWhtM//MhW3g0B/hgQuVzZ9fbNo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Y1qM0IrZWFCb0N6IOThryTBuWdTOR/100RpHBIAJR5Cg2oaX5V/Mm4doo8DyvMQko W/pbyV2fvmMMtgkC8PfwVPdcmjdy5pbXdO60QFUZCPQ4n5rNWibFB3yb5xsSQ1+P3b PXQdFy9iVDz+Cxvs8KlbheqPo0iO27uskLUubvaPezIlWF9q056Mr4L5dvkeSuwXCJ dvzC5arrmBJBrn4/QSUJZ4LCtjsRYkIjiECAaCrFW0xrXlRPngIohpNen+R9ffAAuZ Ux052bP4IluMdj+N8Z/H4lX6NhgcZoGkmFEXy+djP6P1bpjxY705izkNWjZm6UmdgN Jnc6GceLVm+Kg== Received: from alfajor (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8BE9C1201A4; Thu, 14 Apr 2022 14:34:34 -0400 (EDT) From: Stefan Monnier To: Po Lu Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function Message-ID: References: <87r161to4p.fsf@yahoo.com> Date: Thu, 14 Apr 2022 14:34:24 -0400 In-Reply-To: <87r161to4p.fsf@yahoo.com> (Po Lu's message of "Wed, 13 Apr 2022 15:53:58 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.060 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Calling `interactive-form' in a loop is also fairly common. Do you have actual examples in some existing package? > For example, I wrote some code a while back to list commands which > operate on the region, which involves running this on each interned > atom: > > (defun region-command-p (command) > "Test if COMMAND, a symbol, is a command that accepts a region." > (and (commandp command) > (equal (cadr (interactive-form command)) "r"))) Interesting. I just tested this in an `all-completions` loop and my patch makes it run a factor of 2 slower (it went from ~30ms to ~60ms to enumerate the 141 commands that matched). There are some mitigating circumstances, tho: - The first call to this code takes a lot of time (~6s) because it loads a crapload of packages (every package with a registered autoloaded command). - It's very brittle since it won't find those commands that have interactive specs like "r\np" or where it's not a string (like `kill-region` and many others, actually there are regularly more, e.g. to make them obey `use-region-p`). - That loop signaled an error because of an erroneous autoload in `gnus.el` (it's now fixed in `master`), so your code probably did not do that. [ Amusingly, I also tried the loop after removing the `commandp` call (which is arguably unnecessary and could even slow down the loop) but this bumped into even more errors because we then try to load even the non-interactive functions. ] > I'm sure a 3x slowdown would be noticeable, so why does this have to be > a generic function? Making a generic function is the "natural" choice in terms of the semantics of the function (which is implemented as a sequence of tests to dispatch to some implementation-specific alternative). I could change `interactive-form` along the same lines as what I've done with `function-documentation`, i.e. only delegate to a generic function when it looks like an OClosure. That would significantly reduce the performance impact, probably to negligible levels, but semantically the only difference between `interactive-form` and that new `generic-interactive-form` is that one is generic and the other isn't, so it's rather ugly. I've never seen the kind of tight loop you suggest, which is why I have the impression that we can afford to just make `interactive-form` into a generic function, which is a simpler and cleaner API. > Why can't we have `interactive-form' return some > field of a given OClosure object instead? One reason is that for the case of advice, I'd much rather compute the interactive spec lazily (when the command is called) rather than when the advice is built. Another reason is that there is no dedicated "oclosure slot" for an interactive-spec. In theory we could use the byte-code object's slot for that, but making it computable (as needed for bug#51695 and for advice) would require significant changes to cconv.el and bytecomp.el (and to make it not too inconvenient to use in `advice.el` it'd additionally require extending the syntax of `interactive`). We could add a dedicated "oclosure slot" for the interactive-spec, but it'd likely be rather ugly, since that would need to be accessed from the C in `cmds.c` but would require testing the type of the OClosure first and that would have to be written in ELisp since it depends on how OClosure types are represented which itself depends on `cl-defstruct`, etc... So if we want to go in this direction it'd be simpler and cleaner to keep the C implementation of `interactive-form` and have it delegate to a new `generic-interactive-form` when it finds an OClosure. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 14 20:47:13 2022 Received: (at 54802) by debbugs.gnu.org; 15 Apr 2022 00:47:14 +0000 Received: from localhost ([127.0.0.1]:57675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfA7F-000188-Jr for submit@debbugs.gnu.org; Thu, 14 Apr 2022 20:47:13 -0400 Received: from sonic303-22.consmr.mail.ne1.yahoo.com ([66.163.188.148]:41924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfA7C-00017s-Oy for 54802@debbugs.gnu.org; Thu, 14 Apr 2022 20:47:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649983625; bh=rLNvubOFWr4WYB1ct4C3bmOO6Jtl+jLaNob0BiIOEe0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=i1u4mgCuXdygnUBw8sffB5PIuiY3FRp18Hf0B8nf6tGbzMh21to35+T46rUzDsO6snCU/hJ+QE9ygC4q1xLVf85GmAjAyiVu7LLDY3M1Pl3SRD1vO1+XYFrezn4It01I2Hcq5ZvoHiWcPEQ8R8mGQ2ZHaDCexU7yFY0W0mUEzOcKnIQA4DT3ktmu72prGdazYP0z+CS+grheKO/A9OBIzG2Oghv3lg0JxzAVkD2D3/WNGMj639gCCo8+1x7GXqKNJq5lN3+JgnE8KYpEwZBIHBTKdLE9QO/yNv1WaKa7x93KATqbsLKeA+Ltb9DpZ2h09UtsLc+5ElhtQyizAFxZPA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649983625; bh=gUXaJbXUzWfibVgXUT5d7DeXc028rU/vYaGXBVT4Jo6=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Q9a5Sq8WwJ5UjByPaDNwvNfs2o13dgOnprBuTPtH9OfdmszhMx0TUtlQm/MrNcuqI8EHdHTCfTXYW6wPiYBoKjJ0sZnmhLqPFPVVSoOegMQOzEyArRTnZkvtkw+/prycRhOFlmWMpRGmkrfzq8k+9o1vtxDjH0vO7L2VxkJVemYcWlJxT3RflLqiFpNCkmUdsQiiA1v/yNfUSLF8DjYVCLfiNM2QT1bZk0vhC5SkSpqFROD5P/CISY11dPN5lOJvmeNJUEhegw1y2FcfDqgpsb8jCvQvb3xIKws5s59X+j9Tai8M71uZoSmgHZc6ylNT/59wZGGH8DWSu4NSJ70RGA== X-YMail-OSG: tIRw9HMVM1lI6t20Wv56Tg.Wbc3qOsj19.KznXMWK7T1OvKT53CnoCQbE4VIuV8 5eYmF9ULWgv908lJZ2WLSJhX2uz3NpaFY0RfJME0XNHiKbKlckM_RQZL892sUuNzlpz26x5I0o6v JtiProqjenXIPxw9c2jODijUD0Uponi7vMkItUfJ7btdTTSrDpL.senjyFP841fhIEgFXe.lG00u vWwJwDKVicW7ioEiSGHBX_JqWyiTYVtSYiP1zXU1T9d0r5oGxfVCFyiefwY2Ezb2H46LY88dEQLa 7Th0OQ.7NjrQPaIxbPbnmubB6.Iynt7mvi_Q_wqOho9CQy0Vz8V76HZKBg7laJM73bKC1CCY43hV rYwn1Am9WIKWdcd0OvYhPAEtpDWAbWuIXMhu1oTYoV1ud0CqAVnoJ89v13rCVIPL0H.FzHueBsPc V1OTRXIUQg_fK_nwxynN5MslwYdzilUbZQc3TEcsqLer6jXXar1C_f7dR_ynpGx4ObuxBDWi7bMa G_LM89E3GY_J.l9YM2ZXc5EGuhaeBeawkiTf2gJWU2EAiMmc4uDPzsabS31kM6HU7QUmWSbEOlOy yJxggecxuxY98_SohEOhLzUnz77uTf.hLtAh.aKF5dfcx2et7HVps8sBZlAxmIQbDc_Tk7WaM4OL aR2T8GXDKCPbWnO_5dg7uNa_kTiBfGnLeTsF8TPwmtoaD70U4ZzNv6vgiTrPcPrJgJ75Wrm574v4 sVqEKSPKcm1vjeiC1mphvfr.oBF3GImgEhGZhOm3Zf9LSAeeGdX_FCsd_AI6U4QlPP8E9drR4Xuu oUOdm1rVY6CTEf_9ABPaQG6lN1z7K7Gn7uEIQex75uj_zcl_rAszWk9I4fAppZYix5OXi9TUTsxB Jr5XGutxxtY4zFXYLMzwjEr9Lxyi9o.cq_k4_U8D.smF0dPHLQV_mTPYtss.cuI6RJheDqkjBshB 4V3X1fa2FVI0lcAWEq8B7E9RrLXNFT7eZiCuPhnlgK1r2YlBs7ZbKhgN8Dkce5mh9qzan9j7LawE K2816qs0uo8VkkNUtcwQu_rKVC5IT9ohShr3r0wVFvnGGsj71ZpIdcv23l1aBvUquAc8ccDvZCF6 qanUJOvL82_u1cr2R5Ytkdd8U8oZVMenAUy9y9x7dUe42Mz0EpaysvfE6hSumgi2fpGSQBYvl2fd 771ygT6fuYhSrEXLQM.mwmsyzBMjNhYb18Km5rg.pQTRUzYpTwCQrDMUCq3DY17oU1D_V8Dedq.V cmaAuQSxChLonEkh84yX5AqAuKhJ4wWtYpEgNmQMy9fJS9ELX_fm8vOPKIB4.mnw5lALURgWfgTg uETc0BOlWGnOaXo4dIG1PEcE38Jwg2PcrABTwRDbHme86KBEXvkMAzCxVyMojVd6KcshTuhwLl7T WtpXnpXOx2hH_kCBTwewUM5.j_syFMK_WaolnG9bAG6hKe1fSkJqLgClYL263Gg2UDboK2.rTj2S S0l9fCyqSQycBVjuU_i9SnCMBIrCZQk8Nb9gvJeXDJ0mxs0zKTW1DKc0iBk6n4s7VJvDDr84qVo. hrWsUEbsKgbKcIVtoG.EAIWjLFxbBZczUiRiJtvPy7m2pfMLchJhK6s3o2B4MlJvMbzXwFV9JnF. hzu9iuJWKH6eGPW3OshDqAMVvsF3XeRNnw4Wdik175wblsqd9h2dfzv46SbpYtnF_GL.SOgX7Vxv t1JxJFc3e.XsP.TFJokeFOABUwvJ9OToQDy0L24w5K9BfYIDbY292I5QDxQO13xTMOZxWEy3sIG0 g46G7VWaeaDYxvAK2TGiMVnZVs0MaLJ61Uzf0GnWE2hUGCRCA5xi_kHEdEkCitqpmtbwl1AdAHdI xY_DPMVpZVnwqdjXxTAYjeGBscb7eo.2YjCVYUJZ2_XxYwMWasxUlvHciB5hkNOQUsfURuXTqHFV M7AZkRT4zJz0eRFmSnTTVrkjsGX.uMKpsUy0UZ2FnCgNblrL0vGFnEmgaLpKqXvFct0H4q8BelP0 WN4KW_EvTJlBHiv6QJpTLwcJi.agUKFOS19x0EK7fYoAF6ZqAWX_O35cWT0Qg4GAUjHUUKD.9gOF H38iV5sNPdAOb.Oi8iJxtjy2km4QRwGUjS9ZtChb4Lo_B9GWuB6sZqHdsLgBTFNFIg19tFyMfIOM UPKO9JuJ88bbB6B_mE1M.wmdCnQO_QAcq.tkdHZcAx9aK0F_9EqHxzmjUUoEQ__IlvlJTBuyrhg5 g.IxXbbZG2f_7chzERKlu4xnYzijjvH2OG2X4Ui39Wi4Ciy4OhZnO6w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Fri, 15 Apr 2022 00:47:05 +0000 Received: by hermes--canary-production-sg3-cfddc4f9d-6mzbv (VZM Hermes SMTP Server) with ESMTPA ID 3ca1f074b1fae4090cbc155af4f06b7e; Fri, 15 Apr 2022 00:47:00 +0000 (UTC) From: Po Lu To: Stefan Monnier Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <87r161to4p.fsf@yahoo.com> Date: Fri, 15 Apr 2022 08:46:55 +0800 In-Reply-To: (Stefan Monnier's message of "Thu, 14 Apr 2022 14:34:24 -0400") Message-ID: <87v8vbrx4w.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2395 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > Do you have actual examples in some existing package? Just the one I wrote for myself. > Interesting. I just tested this in an `all-completions` loop and my > patch makes it run a factor of 2 slower (it went from ~30ms to ~60ms to > enumerate the 141 commands that matched). > > There are some mitigating circumstances, tho: > - The first call to this code takes a lot of time (~6s) because > it loads a crapload of packages (every package with a registered > autoloaded command). Indeed, that's a problem I know of, but it solves itself after the first call. > - It's very brittle since it won't find those commands that have > interactive specs like "r\np" or where it's not a string (like > `kill-region` and many others, actually there are regularly more, e.g. > to make them obey `use-region-p`). Hmm, I'll try to adapt that code to those commands. > - That loop signaled an error because of an erroneous autoload in > `gnus.el` (it's now fixed in `master`), so your code probably did > not do that. Somehow I never ran into that. > One reason is that for the case of advice, I'd much rather compute the > interactive spec lazily (when the command is called) rather than when > the advice is built. > > Another reason is that there is no dedicated "oclosure slot" for an > interactive-spec. In theory we could use the byte-code object's slot > for that, but making it computable (as needed for bug#51695 and for > advice) would require significant changes to cconv.el and bytecomp.el > (and to make it not too inconvenient to use in `advice.el` it'd > additionally require extending the syntax of `interactive`). > > We could add a dedicated "oclosure slot" for the interactive-spec, but > it'd likely be rather ugly, since that would need to be accessed from > the C in `cmds.c` but would require testing the type of the OClosure > first and that would have to be written in ELisp since it depends on how > OClosure types are represented which itself depends on `cl-defstruct`, > etc... OClosures are records, right? There's no other record type that can be a function with an interactive form, so we could just use `recordp' instead of calling into Lisp for that. Alternatively, we could try to speed up generic dispatch, but I don't know that code and as such am devoid of ideas in that direction. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 14 21:19:12 2022 Received: (at 54802) by debbugs.gnu.org; 15 Apr 2022 01:19:12 +0000 Received: from localhost ([127.0.0.1]:57699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfAcC-0001yr-Jy for submit@debbugs.gnu.org; Thu, 14 Apr 2022 21:19:12 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:59455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfAc9-0001yc-AB for 54802@debbugs.gnu.org; Thu, 14 Apr 2022 21:19:11 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 857EB80306; Thu, 14 Apr 2022 21:19:03 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4F50D80066; Thu, 14 Apr 2022 21:19:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1649985541; bh=In/1WvEPj1+aaRzSVVzLkggNEm0cUF779AmIJM0osVQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=QLQx/qRDcWitQ/sAxllNAyeGL6jQg6JfwTp6g7B8ww5ZtnWLn21UK12/n9jXSrk7J AihCeXwuMntltkf6RsZ9euZH5g3VInq4jc33O6kwVWWmWYyWI+v1GuQqpdjx0k9oAi GwRCGfQ7OUjRmXTI/Km2sXytJIvdZjQ+3uUZfUA2/GHFQ1kIOHpB9zgJBidNDMGoKj x5hSg68ON79YMO/vejmI9CirpKaYZfvrXWYNJdycPKz1L3I5TKsV16u/sUMzk08i56 4nhdD/bELH/3g203o6YxT42H7jnv5rX81GpaF9NCZ4cABgScSy6vQrDzQcaTfNq/xX CnXkctL14JUmg== Received: from alfajor (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 17CE7120692; Thu, 14 Apr 2022 21:19:01 -0400 (EDT) From: Stefan Monnier To: Po Lu Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function Message-ID: References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> Date: Thu, 14 Apr 2022 21:18:58 -0400 In-Reply-To: <87v8vbrx4w.fsf@yahoo.com> (Po Lu's message of "Fri, 15 Apr 2022 08:46:55 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.060 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> - It's very brittle since it won't find those commands that have >> interactive specs like "r\np" or where it's not a string (like >> `kill-region` and many others, actually there are regularly more, e.g. >> to make them obey `use-region-p`). > Hmm, I'll try to adapt that code to those commands. The "r\np" case is easy to solve: just use (string-match "^r"). But the other case is a lot harder since we're talking about analyzing arbitrary code, potentially byte-compiled. >> - That loop signaled an error because of an erroneous autoload in >> `gnus.el` (it's now fixed in `master`), so your code probably did >> not do that. > Somehow I never ran into that. Hmm... odd. I know the problem doesn't show up if you have `gnus-score.el` loaded beforehand, but otherwise I wonder how you dodged that "bullet" (not that it matters, it's fixed now anyway; just curious). Talking about curious, I wonder what you use that loop for. >> One reason is that for the case of advice, I'd much rather compute the >> interactive spec lazily (when the command is called) rather than when >> the advice is built. >> >> Another reason is that there is no dedicated "oclosure slot" for an >> interactive-spec. In theory we could use the byte-code object's slot >> for that, but making it computable (as needed for bug#51695 and for >> advice) would require significant changes to cconv.el and bytecomp.el >> (and to make it not too inconvenient to use in `advice.el` it'd >> additionally require extending the syntax of `interactive`). >> >> We could add a dedicated "oclosure slot" for the interactive-spec, but >> it'd likely be rather ugly, since that would need to be accessed from >> the C in `cmds.c` but would require testing the type of the OClosure >> first and that would have to be written in ELisp since it depends on how >> OClosure types are represented which itself depends on `cl-defstruct`, >> etc... > OClosures are records, right? There's no other record type that can be > a function with an interactive form, so we could just use `recordp' > instead of calling into Lisp for that. They're somewhat like records but they're not `recordp`, they're `functionp`. > Alternatively, we could try to speed up generic dispatch, but I don't > know that code and as such am devoid of ideas in that direction. Part of the 2x slowdown is due to generic dispatch but part is due to the fact the code is in ELisp rather than in C, so even a "perfectly fast" generic dispatch wouldn't get us back the factor 2x. And speeding up generic dispatch is not super easy. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 14 21:38:02 2022 Received: (at 54802) by debbugs.gnu.org; 15 Apr 2022 01:38:02 +0000 Received: from localhost ([127.0.0.1]:57705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfAuQ-0002Sj-9S for submit@debbugs.gnu.org; Thu, 14 Apr 2022 21:38:02 -0400 Received: from sonic312-25.consmr.mail.ne1.yahoo.com ([66.163.191.206]:36215) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfAuN-0002S9-U9 for 54802@debbugs.gnu.org; Thu, 14 Apr 2022 21:38:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649986673; bh=6AHNQ8SS2eN3ttq0kDdpuyY5TsskymdxvqMSZalLi5Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=DXfPazxbPj0Wb32vzD7Be7wcqYKQAaRZqlxrQfirJ3Er6moCgu/4S2dLSnUmcTT0iZnxBGWlXmzr7XBjafntUAkfXoMFLZ0ezkGxQy/ysAtcy8F+yX474IubBjJzqYRAeap9DBsbyQQTEznPW7rRmpZzX+koW7i2PWUn5+hlcii1pTswBAzxEWZOZaku3ENoc1ppp4gWjJCqlU0mGcdVKTlRRdD9YEP5DoMICOsGroLJLImfrLOyNv3ZqAUYmfQutHRX26bmq9FuTpv1t5EQAWCgi9UGcZp1SoI45lkE0+7Y+KA7TPk+EKO+Ij+mV7iGmieER/eUqS3ckOhF3+Wd2w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649986673; bh=k74L8jwWZz0wZxiVtQLGfHugM761Oc8xEan6QFTuDjI=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=uf5NULEEeaNOZ1FfS9jfCj26V+Zlc/KHAvNeK6fWdm5FVd02WYTqT0BBE8laBTkbgfZIgykxxBf9ncQmT2gp3Fwn4C93nXj0uq6laqkgBz/waWFnvdtOLoqoBlurhMyzqzQ2A/cDhcGnzWVz7lbrbKlWsZL1AzUI40vZ66CI94IMBwPhG0TZuMQKi/4H18p19oTTiwlioOM27HiuL3lg60cyVNLeHbmTbqRnWh4gA4UXp1ZFpOPadb8gUttRQnb534Woc5ab5ssxRvHnHxOSrhLTwQCvbTSsG4JAMcQaO6i2NoGYGVcUerk1KdDA11vWs3bTplav6rya3WI+TPeMIA== X-YMail-OSG: FQ5qGVsVM1kVH7kStDkEmiT5iFl.1BOAr6TBDufY4F0jUnjOZXWBGtVmtXV0yul Gz34PIluSZjt406a.rLZ2zTz1tJVqNJ2r9FuA36oSMHbz4c1Wc6chA0k9nVUGRDqnAJ3.YOwR8pC r8vUaLOMZPbpu.Cmh7BYYH835DGUu4qvT5Z.20TieE3bq_jPyNNKY7GpdjCsVNE7b8ZBreLlcGdp XF89BUsj8Q4fAHoh2CxVtokUdnL4q7MQA_d7ZbGNh074RKEeiKLf5iIU_B_NABKSadLG3sDJBxth TYJIHHltirXBxNcC4iuAI323.yFbtzSMh5QSZDmPYqPiJZqLOq6Af3ZMxbL04ldW9_x22ugMcFDK HcB7N.K7VVVoWC_yoIi6kC4MYVCd0WpILfwCS673rFUnqYeo90fTLsl8.Ih08v8qg6j7_rtx2y89 wfFzbAJ16LYfTYvH3gua3jHD26ao9NesL7BMfnFXlTNfFO1ruT8D3JbUzF4bi9mpPVD5JM7YnGGi B0VtQKrMz6gr7t7dkI1i9NUUpwv20mMif2rJs8l9fvS3D4E.DCL.NhVJ7NobmtVVWT4Rl6qUdgSB 63mKRI1W5JokbvwycGBujbwDAhxZkYDgV2xc39lmlq_4K2_0PFhoGTBeMkmZj9WlDHu4j0FQFp5n N5l3EljXsoGpKhWNt.LuxaLo42zkdWkW5MK2K4zazdibId8L7Mqy90lAYQqy_LJaOA8MwaeuegoB VGKIzvsxMG9MNB4jC4ecQEYCPAs49c8nN7EFAb9HbhweGVPfcdU2Wd2PGJKmZC5Npl2nP88BRnG1 Ae73.ggE8jgUTmLmK.KxE2_hTRlgs8Km1JISLIUAxpZ48ntKISEcwB4_.JsskqkI5dLpVoZTq7f0 XYxVGVQ8Pti6v_9_nR1grHLMLNyu9PtmdkgJoz0l7n9BNK585sbeWmoLJsII1YzVbyozfM6mjizD RqmWqegM5GObJDKFjRNYFDDfnTULFzEMjKx1_QreiGuN2KTFOLlYEWAhveHzwxI1I1mSsrVFS1c5 Nt_n5w4jDTdWjGcHD4wIr3KO5rY_0btL0KgaSyttcsgl8Gulx_KtA5NqnU.pMtlFbIfGnPsj6.1e 70sHVjPsqM7Dhi2kz9wYs13c99.822kIr8oOQx.10b_I4Q7jHrmYjv1YNRJLAd0DPShPqiN7waLZ FT_bU4ToPZ7jD42L2Bluwa2wW14RiP1lU8Z5t0KUbdKg.VuZF_tkp4zpX3nBEzmgt1EH.5GNkbG3 1ZiCwo4lcFQu1VM9M.CAHu9NE0pRLezEmw0JpLzQtbJbTOhCFG1WqVpjH5VkhJfjDGZYkrba6r3I qaps9J1L3h0h1kYmEd8Lu519V2KVQkHcEhlaETGbmoNKMDHakKg0lgVj3eZC4AJi_cVPldKbmtrl BOttpsCrvG9aD41R8iBt1ChYmmFKEJa97U7RNess5bdf53vgzzUYexKYWGWBm5X4M61y8.JfCA0L BwjUHf4yRY.I9dQfzUMOas8W9kKgOFfDY04.5srL3aLO7BWs0el4ssmE2A8hkPDIlz6SFFR8aH9R SxBOvPF96r0DxQ08MXFgryXuBZd.qNFttmZ.yJYS.MKVfPXUakeFtv_YLxUfsjLrj_y6n_V0F.6e sLkJxcd1BwI.DCcdRUT2i.rvnxBeALqY4AQ74sp5yyzHA0fZoZpBAAPMiBOP8mVis9_O.9BxN.Ug MT79JWUFuM2F15U7X9eqGYwR4oWPJvPsTbyZQlB_HNSTKWpm0OCP45DUg_.PgyvZY74_GEpWMouv LHztLtKvT_mxouhW4uzMRmCTpFMLZ_OwdNANR1Oe0TAi8GEDHk4Xo5T7p6WICa7ul9S0KmL4aXbP YL7Pbb_Sjf83GzjNiJSug3ES1mOVxobJ07ZzpHKCFNVh77e9SUE.ND3mCjAHFLqUTLtN69p3XVgt 3TaBY242Sm.MZOtN8uT7E1T8FOGzSgekrsC5LIK99gA95F5bGlB86XxXO2y3L6BiGvk9ahqUNLj7 80jix2Jrxb8xcsEJU_z8WuMijkAyvMAv7P5uSPttgeD7el1ONfrma47054WT_DvH8gUwlpt12iTa fm5MVFmtDZ5fimWqNm0yOUjk1uVv2_WJ9tvuwRmURJJRSTNgPynPiHjaDPI98NN9r5fu0wHXgU0y 1uGdIsbvx22j1FCu.0MHXb0UZpPfmNRgcSf6zBAmuHIjJGVKagZ9lrVNTRO2O4SvEXM4FWTjj9m. _YM0cWR9skslEhAoE40FAg_6A7cKRz2HysC8041vGWjQtssj1j8YXfjzC5g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Fri, 15 Apr 2022 01:37:53 +0000 Received: by hermes--canary-production-sg3-cfddc4f9d-v5tn7 (VZM Hermes SMTP Server) with ESMTPA ID a969e426118f0d41086d93859728e41d; Fri, 15 Apr 2022 01:37:48 +0000 (UTC) From: Po Lu To: Stefan Monnier Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> Date: Fri, 15 Apr 2022 09:37:43 +0800 In-Reply-To: (Stefan Monnier's message of "Thu, 14 Apr 2022 21:18:58 -0400") Message-ID: <878rs7rus8.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1441 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > Hmm... odd. I know the problem doesn't show up if you have > `gnus-score.el` loaded beforehand, but otherwise I wonder how you dodged > that "bullet" (not that it matters, it's fixed now anyway; just curious). Probably because every autoload that could cause problems was already loaded. > Talking about curious, I wonder what you use that loop for. It was originally supposed to demonstrate the feasibility of a "context-sensitive" menu in Emacs, i.e. one that displays commands pertinent to the region when it is active, etc. But in the end I made a completing-read wrapper around it, which does make it easier to find some odd commands I can't remember. >> OClosures are records, right? There's no other record type that can be >> a function with an interactive form, so we could just use `recordp' >> instead of calling into Lisp for that. > > They're somewhat like records but they're not `recordp`, they're `functionp`. [...] > Part of the 2x slowdown is due to generic dispatch but part is due to > the fact the code is in ELisp rather than in C, so even a "perfectly > fast" generic dispatch wouldn't get us back the factor 2x. > And speeding up generic dispatch is not super easy. Hmm, so what about having a special "OClosure" pseudovector type on the C level which would otherwise behave like byte-code functions, but behave specially in `interactive-form'? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 14 23:24:34 2022 Received: (at 54802) by debbugs.gnu.org; 15 Apr 2022 03:24:34 +0000 Received: from localhost ([127.0.0.1]:57793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfCZV-0005GK-Pw for submit@debbugs.gnu.org; Thu, 14 Apr 2022 23:24:33 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24076) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfCZU-0005G6-Ht for 54802@debbugs.gnu.org; Thu, 14 Apr 2022 23:24:33 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C95678062B; Thu, 14 Apr 2022 23:24:26 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7461C80306; Thu, 14 Apr 2022 23:24:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1649993065; bh=ILHHYHQcfYXdsXFvUGXuuxJHIMymJOLX/rZrutMgafo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=NSGoyVeXWY7VtOZt+ShAmKtyDWBynClyRxrUyMEnG+xBD/6tfeZZ7bLsf2RhLg4aT +WOgpmQQB4v8xqk4kEd0w8nDu7p/3X+tdpW2fxpayqgHKtRfVRkY3Ng6j+pdpC5hSm KGfUGDt085L3v/mtCRMTu1S+0hO4JH8Y4tynybBoduyU9lVgFVQkO7a5M4UWSYfZT+ AEQOGnIgEhDt5ErBel6894F94ItnJ7Y+G3FsY//Wo6ZEFkdRssEqqBnrZcEYQSbQQZ 2vu6exOvWoDslO7b7j5KkukuHbOp+vuvvZnmOpKqvGSOfEo/xyv9HI5v1LAS+1AJS0 5tv+TIrSbWEvA== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 46E7F1203A5; Thu, 14 Apr 2022 23:24:25 -0400 (EDT) From: Stefan Monnier To: Po Lu Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function Message-ID: References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> Date: Thu, 14 Apr 2022 23:24:23 -0400 In-Reply-To: <878rs7rus8.fsf@yahoo.com> (Po Lu's message of "Fri, 15 Apr 2022 09:37:43 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.060 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Part of the 2x slowdown is due to generic dispatch but part is due to >> the fact the code is in ELisp rather than in C, so even a "perfectly >> fast" generic dispatch wouldn't get us back the factor 2x. >> And speeding up generic dispatch is not super easy. > > Hmm, so what about having a special "OClosure" pseudovector type on the > C level which would otherwise behave like byte-code functions, but > behave specially in `interactive-form'? I can do a sort of `oclosurep` from C already. But that doesn't guarantee that the OClosure has an interactive form, so in the case we match `oclosurep` I'd still need to call another function from the ELisp world (that's the one I called `generic-interactive-form` since it would most naturally be a generic function) because it'd be inconvenient to figure out from C if that OClosure has an interactive-form (and where it is). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 15 00:27:19 2022 Received: (at 54802) by debbugs.gnu.org; 15 Apr 2022 04:27:19 +0000 Received: from localhost ([127.0.0.1]:57861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfDYF-0006uL-26 for submit@debbugs.gnu.org; Fri, 15 Apr 2022 00:27:19 -0400 Received: from sonic313-10.consmr.mail.ne1.yahoo.com ([66.163.185.33]:35377) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfDYD-0006u7-1N for 54802@debbugs.gnu.org; Fri, 15 Apr 2022 00:27:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649996830; bh=QAxh5zgENwB2kL9nHDMBRN6bnN+c0SvhD6ZCe3+UKn4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=YKNrqpAUvlB8JHInV6kqyoQeFHPjZ65EWDHOszcAODsxKdqf+mPG1EK9KdkqtpCr23l7hcXzvsa6MRHO/gITu9g2fSOXtzeQAPmzHhBiN35x8HXm93O6/rmStStu/59BwiHMEPwTEc3C1bJNwrXtdTmKD456yZxN3JOgol8qkdpD5jQ4Nx2a7zQfGJPcFxHNfUPo7OCjTT13c65e5Wr2gLt04vw4+L3LwIq84gmj7ZGiKt6MgIjVAxzHx/mKhcURuXrxgno7jEtIxqCljU3qAcgnWrW2XZ1sIjDBly/ObAt/b24qL+0I+FMzkJ3tJdE/LMBvt6YWyheaAdAIT5sVfA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649996830; bh=kU5mTQY99HJxxG+28XgWZE9qShVHBderSSb8hn+iACE=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=m78lOlZwDnSnsnDaE658lNJEQSLxOMl1l7oE/BqP3S62wGO0JJ3PY4jARIjabeNpxwkZkZbTiZqF1x6ywSUKYdV6eGsyzE089ph/YX69DF18j+88wn5IdoZeAZsDxzGviw372QQ86SEPAJgQdeVjwHtUpQQdqCpwwwRilhVF7Ni9QfnNwMIZ+sBs5cVKi8j/PYQc711A3g9UJihrm7AC3JAdHcxRzfq7KVc1NZFkuf5S+5S3mwjAOwoJ98Enwu0HjKD1tSAcpIGqpx4biDVQge6RmXY/pjm/I+Wtpkba39bbBrCngYn1EX0wHPrkDckT4Tep3+onlnXwf6cFbY9VHw== X-YMail-OSG: t850VT4VM1l4nfwchIzXiP.6pXxPhAV.j7sjgSlDPwNjzyYuzQJiqAyzTryoodc SvunNu1zQk5fXzwBh59c8RreaoMDjpcc1CuSaxaD9Y4svQ0ywf45b0zj0JyrgTHoELYjACZCdfcC f6Zbny6mYr04GIeCXA0qU2pEY1_NhGjq9sLyWt2NPIVEiLeUsA6TBvzITmATdLWHfAsaeZdaLf5g LfBQMKpygtLk0Wk.zS9q.vNbWDAb.sS4.7Iwn.arEErqK95GucGvnxRie_nfgn.NzTGx.rq4kfNB HxCfGeJRenYxmApGbNewSw9WiCWPuebV8I6ppxEghVZVz70F3sQ.O7cYwALWqFOxWw_BbXawF1fu EwGrKFHX3J6tba8tnrjDmCRCVO1vapNeR17mBjibUqj9tWbXRAk3v3AeDTrhBjvkPyD0B2VMHLWT RHvW_OvCljQK7f2JNTqL8guruB8u4oqofjU_a0jSEomwIQfoWF.Zv44XSwihgD0Rfw5NAlOMxBd1 IL5EQwPiNLfEyYdi1Mb_VoVr7CoKvydTOHbTpEHku08YjtA5g6uFPgenpEmY8loy8cUKIT7w3TUM izewooyH6DIWaWbRm0FKY0VjeLiw9JoaHNhQF8bk1FpbuShUmH48serB.LQsXmvWb2_AYmnMHmFi 64jlM.0GdwDXgfH0eLc5HZohD3rDqyoHJSdoQjoM_Hzfj57oB8PVupHj3mzn5SAYCxVLs7q_JICv _y3_ffNk4y5XHUUoMw50QWmpqAJHghdXrf6Z3mdwO2emoqs7a6UWeJI3dN521sl.Jsib6rJtfLHf wf7Ryjzk2nyO9ZG.vDGeRGnTBOvmwBTbIv7Q1Fi3F_.NBwNAo3knpjsww65..pXbw2drRAjHfkL0 .yCQ7jSvFAXvSfCYIItyKuZhTo8HBpU3pHwkNOgMxPvncKjB1npHOUJ9.kJ1zbQr9QmDtkUZNwxj JM5G0X5lN25tXmkPmvKXwuj._8ibob1DZ3GHnmWorzOGDkFIWwZf_5jllzm9x09XHvENl7iO_BqS AcNKaeyQxceou6ghKz4vrHrIojcfmdhJFzQQyv5L5eZS9ZPcOgknpbA1jc.tO8plBGRk9BQmgHVb 71IFRI2wC4ncMdnAIGgiudd2nPeSu7md2zvKnBKhpYE7mQR6DBvBrHklihlPqH.kjF0GzMV_GhSV WIZJVrnPun7x133KCpdx1_2KhyKm4073W_85fjv7k589Quv1VmlKpYiiNcgrbXesUuqUEIbCQZbk qbOphcyhwuVw3YKWNrx0whhemeHwjvucjKO8mIWJLHSqnwCg.qMHaRcySMuZzYBgnVOdrf998TKe cQqgjt7EGIHPKgOXEiPoP_E8pbN9JFMS3vGLmfUCDUe72f3tr5kEWkvgeI1iHKWE.ndlhqihRid9 i52cH05Ff9CWyGDK6GZQ38xgNa2e9qvxXhk5PJogwMK3uKxl97t9aRSQ5.yW.QJQK2RcTFcT0jGg sOG9ZFINfOX7vfdQElu3.4D6CToVa7pL1JQ1Rygy1QBBdz7HEnHROFOr56xma8mUwnHmtwHDZpg5 ZmxqCCrM.EwI8liAMnJOMeXRCJGAK4.9IX3cN2y_C7Kjtt9y3pNU65N2y9ccF5BKijGHGBFbOvac _xHTraagkpw3DMQr02_fRq6TvCOa4YYUgN1Bnm1h0RQJaPBML.TAXVcdD38k0KLNmZuynUKQrvEj 9oBdR0Ns8HTBlN.5qwgwG.voNo4FOzXj_5Gd6Q5J_9quabazSVGQCUrStq_fpRQ2oKXGTGCuHK3M G9bXoGpJMZX_PeNxQiybLEZP4qryuvkQJAFBf1a_lLBJPxaT6DslNgWH1Qe5RV7cB3SVNzHTmgO0 ivJNLmIHozfNnEgKc0MNMG.xIENwDsWqixyL9cVN1W4maL8Z_AQTfOUcFBgIDxqDe_nM.77DYVYw sEcy1aDgTyE5pFXZ4BdFmg9Z7iHuYFNGRoHHV3fQmE0jHVG7SklLN0nyu_b_tuIv_jkhRp.zH8QG vxGo_qJ7feumYXFSiAjh8EtXzDX4mUEflEHiqn8BO7GaP1yvjPXiMUK_q31aqPoP6fhPPrLUllJB raedQLHbCHldiRJygsIO8mkOjJMorvplq0APim78Ht15PJvPrtcTzBHoF_.kFGkk.JzQH352wxUn rwbe1cKeW9A8bm6zIk.r1eq7GPi.x6FPrO82U2kW2iKUdWCXO5Ozvepj91oEbu24NHjvOuMd9dpT 82Gz8gdMpx.Nng7hsF4IvdtqXyhb2G9XXfokScC.Os0DQTF_Ei48YFrNuEUdD X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 15 Apr 2022 04:27:10 +0000 Received: by hermes--canary-production-sg3-cfddc4f9d-shft8 (VZM Hermes SMTP Server) with ESMTPA ID c7b8c4e3360e5121abe4718e2566ae05; Fri, 15 Apr 2022 04:27:06 +0000 (UTC) From: Po Lu To: Stefan Monnier Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> Date: Fri, 15 Apr 2022 12:27:02 +0800 In-Reply-To: (Stefan Monnier's message of "Thu, 14 Apr 2022 23:24:23 -0400") Message-ID: <87fsmfq8dl.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 440 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > I can do a sort of `oclosurep` from C already. But that doesn't > guarantee that the OClosure has an interactive form, so in the case we > match `oclosurep` I'd still need to call another function from the ELisp > world (that's the one I called `generic-interactive-form` since it would > most naturally be a generic function) Well, as long as its possible, I think we should do that. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 15 12:08:20 2022 Received: (at 54802) by debbugs.gnu.org; 15 Apr 2022 16:08:20 +0000 Received: from localhost ([127.0.0.1]:60161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfOUb-0002Fk-Ks for submit@debbugs.gnu.org; Fri, 15 Apr 2022 12:08:20 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfOUX-0002FQ-Ct for 54802@debbugs.gnu.org; Fri, 15 Apr 2022 12:08:17 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B6F93805E4; Fri, 15 Apr 2022 12:08:07 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2FC0C802BB; Fri, 15 Apr 2022 12:08:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1650038886; bh=qbcC9sZ0FiufIMB55s1G/9v9SeQ8iT/TamzM6+Coi9I=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=WoMFMtXd80UjJV/XQoJ8anvppsloDA45IK6LktvzHWsM0G6HDtEvwVRpmnIu+0rNX nAeH20rYaBo0wcqu4g9PlGAQz2Ej22QsOAIwcZfxgTCECOi3tFZSPcUDSvJjav0KJt 3RFXGYYlEESkwY6/TLYQHZpQgcE0+HKzff1D71ufzBf9cBFYLjakuG+2sR74+eXaSw cbyM6T+tgjDA/PozZfh0STEujC3e7Zk9ZzIq2M8u7UaBwB5kByEvkoWrAUz52oBNu3 o53QaJiIawxmJ6QKUepj6jF8PIarlK4SYgqKolJ24Hh/WqCXAMNENAOCSXbUMzYCfw Pl2uxPU5ihPEw== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0804D120600; Fri, 15 Apr 2022 12:08:05 -0400 (EDT) From: Stefan Monnier To: Po Lu Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function Message-ID: References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> Date: Fri, 15 Apr 2022 12:08:04 -0400 In-Reply-To: <87fsmfq8dl.fsf@yahoo.com> (Po Lu's message of "Fri, 15 Apr 2022 12:27:02 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.060 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Po Lu [2022-04-15 12:27:02] wrote: > Stefan Monnier writes: >> I can do a sort of `oclosurep` from C already. But that doesn't >> guarantee that the OClosure has an interactive form, so in the case we >> match `oclosurep` I'd still need to call another function from the ELisp >> world (that's the one I called `generic-interactive-form` since it would >> most naturally be a generic function) > Well, as long as its possible, I think we should do that. It's definitely possible. The reason I resist doing that is that the resulting API is ugly (you basically have two "identical" functions with the only justification for the difference is that one is implemented in C and the other is a generic function) and the only existing reason for this ugliness is this one loop of yours whose behavior is brittle anyway, whose first execution is 100x times slower (so the remaining 2x slowdown when the loop is fast can't be that important), and whose subsequent fast executions could trivially be made faster by caching the result of the first call. So, I'm waiting to hear what others have to say about this choice. Eli and Lars, do you prefer the faster-but-uglier API or the cleaner-but-slower API for `interactive-form`? Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 15 12:14:10 2022 Received: (at 54802) by debbugs.gnu.org; 15 Apr 2022 16:14:10 +0000 Received: from localhost ([127.0.0.1]:60166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfOaH-0002Or-On for submit@debbugs.gnu.org; Fri, 15 Apr 2022 12:14:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfOaD-0002OD-IK for 54802@debbugs.gnu.org; Fri, 15 Apr 2022 12:14:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58818) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfOa8-00043i-8X; Fri, 15 Apr 2022 12:14:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=MyP8uAAwbZbZVTwG/n8v4S6Npi+/zirzI2zTMA20+Cc=; b=UAdiECaJIaKQ iOdJtBnJIgcNYFokMzx28xXk6WTGyNjbc66Jtl2oe4XXqf1Ivo3b7Uend37hGRstzD1STsJLzXKY3 cYZVuOoq4l8sEVBei28bleJcbZDAfvJLEG/bLYMVpWsHc1aqdHy2kes9VOuOHNM2ouy+xtmFj4Nnx iYq5ZtJbhV05jR9GXZGZcH7u+7A4H+ntzotjlAGFlFvA/7qbnUyYJASjL63b+QBUmCwVW70E4MsD7 HQmmJHuxwrUOsMi5N6cFVtY3PMLIgQEftdqY0BZo0zFP2dPiy9e9Pg1Y2wiTy7ZiFQA3NI5tfr+1C acFSd4WgPG2BYucQptJ7RA==; Received: from [87.69.77.57] (port=1082 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfOa7-0000hu-NG; Fri, 15 Apr 2022 12:14:00 -0400 Date: Fri, 15 Apr 2022 19:14:11 +0300 Message-Id: <83wnfq1fzg.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 54802@debbugs.gnu.org > Date: Fri, 15 Apr 2022 12:08:04 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Eli and Lars, do you prefer the faster-but-uglier API or the > cleaner-but-slower API for `interactive-form`? As I said up-thread, I don't understand why we need to touch interactive-form at all. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 18 18:59:39 2022 Received: (at 54802) by debbugs.gnu.org; 18 Apr 2022 22:59:39 +0000 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 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 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) 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== 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) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function Message-ID: References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> <83wnfq1fzg.fsf@gnu.org> Date: Mon, 18 Apr 2022 18:59:28 -0400 In-Reply-To: <83wnfq1fzg.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Apr 2022 19:14:11 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.048 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 01:40:55 2022 Received: (at 54802) by debbugs.gnu.org; 19 Apr 2022 05:40:55 +0000 Received: from localhost ([127.0.0.1]:41509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nggbf-0007c5-Ln for submit@debbugs.gnu.org; Tue, 19 Apr 2022 01:40:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nggbe-0007bs-7n for 54802@debbugs.gnu.org; Tue, 19 Apr 2022 01:40:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60078) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nggbX-0002xF-V0; Tue, 19 Apr 2022 01:40:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fDZWH3NcDJO3p+Aj3zMg5IwAIIyVtHDPDPuwBTiCuk8=; b=Aqk4tfVE54mw GfZ4ZbqmVgKyHwvU4e2oQTrSqP5XK04GV1NmBhdDgo6U04P2Vyktovqmc6fmyvRrb9uT/L+tNcSw/ 6pQuAc7CDMatWtSXPumMohQpsJ25lu/khnlelkAB5j1LHPMASuJ0iqgqPKwjY2wPlDMVn8ozns6om Gc9lr0WRd2Nm5N1NAcYc6HmEV8lK5wkM2sCSH9mYqlgxx//3XDBJg8aSK9fIFc2mJs/b1FzkFQ+GE NQdTlKQIrZkTAABIgFGjaO0Vh8rcUEevo/3PGxXCV914AvMTHB5eC+akFeZcuWsf8np/gUkq8q1mL TSOY5tYmd3YDjUXcBtFdUQ==; Received: from [87.69.77.57] (port=3963 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nggbX-0000S9-EX; Tue, 19 Apr 2022 01:40:47 -0400 Date: Tue, 19 Apr 2022 08:40:37 +0300 Message-Id: <83v8v5vdey.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Mon, 18 Apr 2022 18:59:28 -0400) Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> <83wnfq1fzg.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org > Date: Mon, 18 Apr 2022 18:59:28 -0400 > > 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. I'm sorry, but I think the cleanest fix is too much to pay for a minor feature such as this one. Can't you find a less intrusive way of fixing these issues, one that doesn't affect all of Emacs for the benefit of one or two packages of minor importance? From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 08:39:02 2022 Received: (at 54802) by debbugs.gnu.org; 19 Apr 2022 12:39:02 +0000 Received: from localhost ([127.0.0.1]:41942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngn8I-0001da-9Q for submit@debbugs.gnu.org; Tue, 19 Apr 2022 08:39:02 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngn8G-0001dG-UV for 54802@debbugs.gnu.org; Tue, 19 Apr 2022 08:39:01 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EF6D68005E; Tue, 19 Apr 2022 08:38:54 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2418D805B9; Tue, 19 Apr 2022 08:38:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1650371929; bh=2Kp9WDJt9CMGD5/126hyTb6K0BcoIrhG3k9tWYqrgHE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=C98mD7BJZ4nuZL3Xsjv1fBNpz0LAt49etY0FvL7mBPKaSK0Q2nCV65S2hMlWrDoEW bYcmMAouKxyFehKe0RzLENCgKaTyUs3T4RxGYKbcs8viAuBkHwnXNRj1Vv3A0f/JBk luifW9SHXaBv8BQeI+/xOe2ovvZp0xW5Kz5DWXV7gcb1n0aLrXqWaR0JsWH83lD8yk sDbhY2fI6EORCq20rqeZ9xYh0k37g5gZryhLl1dCOZO5PDqemi+Ar1zMNmVp4KcKs+ zpB7cfzxdP5GRb2poRCHBp/nbi4Zvcdb1oGGOb4LJ6+O+Sy8TUX87ajg93S9c9RgYL 8Oa1T4+kL4h7A== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E8EEC120164; Tue, 19 Apr 2022 08:38:48 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function Message-ID: References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> <83wnfq1fzg.fsf@gnu.org> <83v8v5vdey.fsf@gnu.org> Date: Tue, 19 Apr 2022 08:38:47 -0400 In-Reply-To: <83v8v5vdey.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Apr 2022 08:40:37 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.060 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I'm sorry, but I think the cleanest fix is too much to pay for a minor > feature such as this one. I don't see much price to pay here. Am I the only here who finds that defining `interactive-form` as an ELisp generic function is, in itself, a good idea (not good enough to do it without a good reason, but something I put on the side of "advantages" rather than "defects" when assessing my patch)? > Can't you find a less intrusive way of fixing these issues, one that > doesn't affect all of Emacs for the benefit of one or two packages of > minor importance? Not sure what you mean by "affect all of Emacs". It affects a well-delimited (and small) part of the code. `interactive-form` is a rather simple function with a well understood semantics. Are you worried about introducing bugs, about the performance impact, or something else? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 08:44:05 2022 Received: (at 54802) by debbugs.gnu.org; 19 Apr 2022 12:44:05 +0000 Received: from localhost ([127.0.0.1]:41959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngnDA-0001lp-Tk for submit@debbugs.gnu.org; Tue, 19 Apr 2022 08:44:05 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngnD8-0001lB-8U for 54802@debbugs.gnu.org; Tue, 19 Apr 2022 08:44:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=PeVWPDh6g1jvXBS93rqw++qlou+cM6XLMEmmolL8uOU=; b=bl4CraSe39X7eFNoc8FIjxqn0i qOIc/Ho/JYdVo0xVudx9aOSjZrGhnNab4/SfKeH2V3yUeNchCaXbKVrMeoRqKHbvQj7Sdts7AYSvY Qd5w2ryEiWgRPRJ0E1DVzlkcyRFoqMVApdDYyNrLLoMfnYJgd5XefdAVFjh9WRL+aCE8=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ngnCx-0007CR-6G; Tue, 19 Apr 2022 14:43:54 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> <83wnfq1fzg.fsf@gnu.org> <83v8v5vdey.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEVVTFksIyx/dYfR xsgOCQv///9l4j0tAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+YEEwwrGaDkoEMAAAGcSURBVDjLddPt mYMgDADgiA4AlAEQOkBrbgBi2X+mS0A+vD7HLx9fAyGJsEBdwXtojwEUQq7L8MpjkQJ3vYZlfm8q kDEaIM8rFpCAGtqWKWAkQN3gRAYqAWGbISFs9QQV/Aw0wfIVUXcK7QxD/ETrBWqCc2cA2CSnxdjQ drEg3+gCBqaUbESGs4IblzAq4jM7AicB0+U0RHznFCrMxSggN5dbzOXQRu8C5guyelOHbXQpZPW6 AEA/jwnsK38QFgG1H323dYtHWmsEl3bAAxEj1giu1B1wgPkPli+4io4dzjgAKpAW/VwRWwVpx1oG Qv0B/jhigXgDGSPkRvAchA48nqA2gZ/7VtzBJBd5lAh9gZM+KSp7RQGKUpESEfK5a/kN0i65Ia4V uMrpcL1bFvEIDWxYdBtRauk663k0nN6v96FllR87AefUZi52sFuC0XKawCU/xiRhB30DmiCn8TfR tdXB2UOeIpJfW0kycKUKyFXS69HBO/Lye3FCh1fHZ0RkyrackiLfzjaghY+3pXlZczNCB1dA/kjT usTrF8cox9B0KrUDAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTA0LTE5VDEyOjQzOjI1KzAwOjAw J9nTawAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNC0xOVQxMjo0MzoyNSswMDowMFaEa9cAAAAA SUVORK5CYII= X-Now-Playing: AR Kane's _Single Collection (2)_: "What's All This Then " Date: Tue, 19 Apr 2022 14:43:48 +0200 In-Reply-To: (Stefan Monnier via's message of "Tue, 19 Apr 2022 08:38:47 -0400") Message-ID: <87k0blb5vf.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Am I the only here who finds that defining `interactive-form` as > an ELisp generic function is, in itself, a good idea (not good enough > to do it without a good reason, but something I put on the [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Am I the only here who finds that defining `interactive-form` as > an ELisp generic function is, in itself, a good idea (not good enough > to do it without a good reason, but something I put on the side of > "advantages" rather than "defects" when assessing my patch)? Sounds like a good idea to me. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 09:01:15 2022 Received: (at 54802) by debbugs.gnu.org; 19 Apr 2022 13:01:15 +0000 Received: from localhost ([127.0.0.1]:41999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngnTm-0003TN-Ve for submit@debbugs.gnu.org; Tue, 19 Apr 2022 09:01:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngnTl-0003Nz-W3 for 54802@debbugs.gnu.org; Tue, 19 Apr 2022 09:01:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37392) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ngnTg-0003H1-8u; Tue, 19 Apr 2022 09:01:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FDuWmw2R5vQQOL625mCV2BYnrMM6RhOK9v9YpMd50KI=; b=o37R2QPP9aad rk11xsunDBKh4q+lRQ6TcNRgqL65b6G4FR6ACa/uQOttiflZCbImLFSGUCi7k3nlX9omYIqDiBbmN 61q1nzH/T8M3YcyZ7//ZTjZ5eQmGr3PErQe47WywfDid++ZZdMg0hyxC1xzIm/Zwp5QrtyWgbPt1t OdjspdsDr+TQb8duqwi2dTg9JBLLVNkKkhlsNsscB84Q2CeERUs8p88QQ6jxHo1VTfSq6HUu8NNku Nc59tah8houazDdn4Ub1TdPnhLXt5JtzoJaEKaNYiHcImXvcQz+xqJVVQlvHG97+mDL+A9RP1/Dgq gJqVCO81BG5YoYYLSkALFg==; Received: from [87.69.77.57] (port=3681 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ngnTf-0000UE-15; Tue, 19 Apr 2022 09:01:08 -0400 Date: Tue, 19 Apr 2022 16:00:58 +0300 Message-Id: <83fsm9ut11.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Tue, 19 Apr 2022 08:38:47 -0400) Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> <83wnfq1fzg.fsf@gnu.org> <83v8v5vdey.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org > Date: Tue, 19 Apr 2022 08:38:47 -0400 > > > I'm sorry, but I think the cleanest fix is too much to pay for a minor > > feature such as this one. > > I don't see much price to pay here. See below. > Am I the only here who finds that defining `interactive-form` as > an ELisp generic function is, in itself, a good idea (not good enough > to do it without a good reason, but something I put on the side of > "advantages" rather than "defects" when assessing my patch)? Maybe you aren't the only one, but I don't share that opinion. And in this particular case, I don't even consider the reason to be anywhere near "good enough". > > Can't you find a less intrusive way of fixing these issues, one that > > doesn't affect all of Emacs for the benefit of one or two packages of > > minor importance? > > Not sure what you mean by "affect all of Emacs". It affects > a well-delimited (and small) part of the code. It is called outside of the advice functions. > Are you worried about introducing bugs, about the performance impact, > or something else? All of them. And again, the reason doesn't seem to justify the risks, not IMO. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 09:34:58 2022 Received: (at 54802) by debbugs.gnu.org; 19 Apr 2022 13:34:58 +0000 Received: from localhost ([127.0.0.1]:42020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngo0Q-0005Bz-9F for submit@debbugs.gnu.org; Tue, 19 Apr 2022 09:34:58 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngo0N-0005Bl-Qp for 54802@debbugs.gnu.org; Tue, 19 Apr 2022 09:34:56 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2A08E803E6; Tue, 19 Apr 2022 09:34:50 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E7BB880664; Tue, 19 Apr 2022 09:34:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1650375288; bh=5gxPJtw3dYtXzTi+y8Oy++x/I0hT5GTaSYlPQplHK60=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=O+FOkvBl8lzA6W3rpKei+h1vBMTJYMivrhxZKxzx6tD8Q8rrnluoa2K4YNulYDOLH Q4h46+Aty3Q6DKaatjT7cSFvh2C9itwA2QGOtyPBDYMY8gWzUtPZpYU07SNUDfbxzT qTGwEUkAJcOQRM2GS6lSnseT8WlWPllhNpk70Mt2Bn5gF872Lh7D6hHrqfLIr1EyFX WL5MFOLaocQVCO4g1xjMxLm3dluXERdNUWU5pffmLve0pO4Slx1Lzu4Ikjlu1gmTZr RnR+8bi5CnUhS7d1ubGfnYJAiewwF0fjI0ENwvZUXs+GRVjOVTuDkSpaD/V36RT6cZ pzbtTBc0/P32Q== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B64EB1201C6; Tue, 19 Apr 2022 09:34:48 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function Message-ID: References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> <83wnfq1fzg.fsf@gnu.org> <83v8v5vdey.fsf@gnu.org> <83fsm9ut11.fsf@gnu.org> Date: Tue, 19 Apr 2022 09:34:47 -0400 In-Reply-To: <83fsm9ut11.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Apr 2022 16:00:58 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.060 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Not sure what you mean by "affect all of Emacs". It affects >> a well-delimited (and small) part of the code. > It is called outside of the advice functions. The patch under discussion moves a well-understood and simple piece of code from C to ELisp, and while doing so marks the resulting function as generic so that it can be overridden on a case-by-case basis by packages. The move from C to ELisp should make no difference other than performance. As discussed with Po Lu, if needed, we can reduce this impact at the cost of a less clean API, and I think it would be for the worse (the result would be a more complex system with two equivalent functions where the coders need to understand when to use which), but I could live with that. The fact of marking it as generic does not directly have any impact at all (literally: it just adds a `cl--generic` property to the `interactive-form` symbol but the content of the `symbol-function` is the same as it would be for a normal function :-). The act of overriding it for specific cases by added methods will on the other hand make a difference and can introduce bugs, just like advising `interactive-form` can introduce bugs. It'll be the responsability of those writing those methods. I don't foresee this to become a problem at all since it'll be rather uncommon to define such methods and it will most likely be limited to OClosures (doing it for other values would be of limited interest). >> Are you worried about introducing bugs, about the performance impact, >> or something else? > All of them. What makes you think this can introduce bugs? What kinds of bugs? Can you point to code where you'd expect `interactive-form` to be a potential performance problem? Care to be a bit more specific about the "something else"? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 09:53:57 2022 Received: (at 54802) by debbugs.gnu.org; 19 Apr 2022 13:53:57 +0000 Received: from localhost ([127.0.0.1]:42026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngoIm-0005eO-UK for submit@debbugs.gnu.org; Tue, 19 Apr 2022 09:53:57 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngoIk-0005eC-O8 for 54802@debbugs.gnu.org; Tue, 19 Apr 2022 09:53:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38626) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ngoIe-0006FS-JY; Tue, 19 Apr 2022 09:53:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=m2AnpRqNgMXN4fA05tSFe5gbB3+Ak72KMJQTwtJe5S0=; b=aJthPF444o9l ChiZ6zKvwoP7x7HgfkizpvGYonwuzxCg5HDUn5jlaXYwnF/YhjCduoB6iObYUyQ5Dt6bSxuxhPkaH SN4I3T1euCG+0Peo+qeUbkn5r7ZIjOmUYb9rznV0E8fxa3zdSn4ACpf8HXHaTpvTjUme955V5dmYn RoQTQkGGpDp5APxKQIFoqMlsbisL25QbvOIv4VRuW+B3x6UoUzk1bC9KghyCNtejeGga5l/j0ozO3 ehmvn6GvTdcp/SHwXJAptmY4sqX2lc3cWXIpBwOfDoK3NaDNpmEtRS45XzAdVyyRlOt7qUnx5UuYP qZ96eH12YS+18YGgjZWPjw==; Received: from [87.69.77.57] (port=2975 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ngoIe-0006Ij-1v; Tue, 19 Apr 2022 09:53:48 -0400 Date: Tue, 19 Apr 2022 16:53:37 +0300 Message-Id: <83czhduqla.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Tue, 19 Apr 2022 09:34:47 -0400) Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <87r161to4p.fsf@yahoo.com> <87v8vbrx4w.fsf@yahoo.com> <878rs7rus8.fsf@yahoo.com> <87fsmfq8dl.fsf@yahoo.com> <83wnfq1fzg.fsf@gnu.org> <83v8v5vdey.fsf@gnu.org> <83fsm9ut11.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: luangruo@yahoo.com, 54802@debbugs.gnu.org > Date: Tue, 19 Apr 2022 09:34:47 -0400 > > >> Not sure what you mean by "affect all of Emacs". It affects > >> a well-delimited (and small) part of the code. > > It is called outside of the advice functions. > > The patch under discussion moves a well-understood and simple piece of > code from C to ELisp, and while doing so marks the resulting function as > generic so that it can be overridden on a case-by-case basis > by packages. > > The move from C to ELisp should make no difference other than > performance. We've seen this proven wrong quite a few times already. This isn't the first time we move some "well-understood and simple" code from C to Lisp. And every time we did that it had unintended consequences: subtle bugs, features that were lost, subtly changed behavior, etc. How many times we need to experience this before we all understand that there are no "well-understood and simple" enough code in Emacs internals that can be reimplemented without consequences? I could understand an argument about advantages that outweigh these costs, but denying these costs exist? that I cannot understand, given our common experience. > The fact of marking it as generic does not directly have any impact at > all (literally: it just adds a `cl--generic` property to the > `interactive-form` symbol but the content of the `symbol-function` is > the same as it would be for a normal function :-). And makes debugging harder while at that. Right? > >> Are you worried about introducing bugs, about the performance impact, > >> or something else? > > All of them. > > What makes you think this can introduce bugs? Bitter experience. You were there, so I'm surprised you don't have the same experience. > What kinds of bugs? How should I know? We will know when we discover them, months or maybe years from now. But discover them we will, of that I'm certain. > Care to be a bit more specific about the "something else"? See above. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 10:53:20 2022 Received: (at 54802) by debbugs.gnu.org; 19 Apr 2022 14:53:20 +0000 Received: from localhost ([127.0.0.1]:43898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngpEG-0007bJ-27 for submit@debbugs.gnu.org; Tue, 19 Apr 2022 10:53:20 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngpED-0007b5-Bl for 54802@debbugs.gnu.org; Tue, 19 Apr 2022 10:53:18 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 700B210019F; Tue, 19 Apr 2022 10:53:11 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7904B10000D; Tue, 19 Apr 2022 10:53:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1650379988; bh=nDd98Wr2oxKwaWXdUbUATJ+RfMk638wDzwc8E9R0CTc=; h=From:To:Subject:References:Date:In-Reply-To:From; b=Ym3EHkCHeTU7u1d0Czl/IoOajHT6bTC7Mshwq+2T00pB34VgelaVmKrnsm3cVl+Tg amKbT3ZSy1I5TXKLqAAxnTefCH+EcylINFwadO88MGqEQl6aCS1R2ygJGhf5ofsZqC o+UEzY7IOCwzks0g0FecgA8eOxad+da/sME5pVk4v69/cOb7Zk7Xr2KU/z1Z0qTyjG Mwi/hzivtn61mNlifruy1BHP83cp7Q/O7xB414IdpywvcBM6j+jtQTXGVRDhNHY9qE RiHv8gbteCicHK179QmcXcl/717GI6WDpZb/pEI3/el1Ef3ovT4wzGE0NdKatwEtwb Tk1+BUJO/SEaA== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 56E5D12069F; Tue, 19 Apr 2022 10:53:08 -0400 (EDT) From: Stefan Monnier To: 54802@debbugs.gnu.org Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function Message-ID: References: Date: Tue, 19 Apr 2022 10:53:06 -0400 In-Reply-To: (Stefan Monnier's message of "Fri, 08 Apr 2022 16:33:51 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.048 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier [2022-04-08 16:33:51] wrote: > The patch below does it by making `interactive-form` a generic function, > so OClosures can compute their interactive specs from their slots. Here is an alternative patch which does not make `interactive-form` a generic function, but instead does what we discussed with Po, i.e. introduce a new generic function to which `interactive-form` delegates the work when it encounters an OClosure. This way, we avoid slowdowns both for `commandp` and for `interactive-form` and it minimizes the changes to `interactive-form`. Stefan 2022-04-19 Stefan Monnier New generic function `oclosure-interactive-form`. It's used by `interactive-form` when it encounters an OClosure. This lets one compute the `interactive-form` of OClosures dynamically by adding appropriate methods. * lisp/simple.el (oclosure-interactive-form): New generic function. * src/data.c (Finteractive_form): Delegate to `oclosure-interactive-form` if the arg is an OClosure. (syms_of_data): New symbol `Qoclosure_interactive_form`. * src/eval.c (Fcommandp): Delegate to `interactive-form` if the arg is an OClosure. * src/lisp.h (VALID_DOCSTRING_P): New function, extracted from `store_function_docstring`. * src/doc.c (store_function_docstring): Use it. * lisp/kmacro.el (kmacro): Don't carry any interactive form. (oclosure-interactive-form) : New method, instead. * test/lisp/emacs-lisp/oclosure-tests.el (oclosure-interactive-form) : New method. (oclosure-test-interactive-form): New test. diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi index ace0c025512..16712fd7cb7 100644 --- a/doc/lispref/commands.texi +++ b/doc/lispref/commands.texi @@ -312,6 +312,9 @@ Using Interactive specifies how to compute its arguments. Otherwise, the value is @code{nil}. If @var{function} is a symbol, its function definition is used. +When called on an OClosure, the work is delegated to the generic +function @code{oclosure-interactive-form}, where additional methods +can be used for specific OClosure types, e.g. for advice and keyboard macr= os. @end defun =20 @node Interactive Codes diff --git a/etc/NEWS b/etc/NEWS index 3e7788277d3..284e6ab50dc 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1292,6 +1292,11 @@ remote host are shown. Alternatively, the user opti= on Allows the creation of "functions with slots" or "function objects" via the macros 'oclosure-define' and 'oclosure-lambda'. =20 +*** New generic function 'oclosure-interactive-form'. +Used by `interactive-form` when called on an OClosure. +This allows specific OClosure types to compute their interactive specs +on demand rather than precompute them when created. + --- ** New theme 'leuven-dark'. This is a dark version of the 'leuven' theme. diff --git a/lisp/kmacro.el b/lisp/kmacro.el index 8a9d89929eb..5476c2395ca 100644 --- a/lisp/kmacro.el +++ b/lisp/kmacro.el @@ -820,13 +820,14 @@ kmacro (counter (or counter 0)) (format (or format "%d"))) (&optional arg) - (interactive "p") ;; Use counter and format specific to the macro on the ring! (let ((kmacro-counter counter) (kmacro-counter-format-start format)) (execute-kbd-macro keys arg #'kmacro-loop-setup-function) (setq counter kmacro-counter)))) =20 +(cl-defmethod oclosure-interactive-form ((_ kmacro)) '(interactive "p")) + ;;;###autoload (defun kmacro-lambda-form (mac &optional counter format) ;; Apparently, there are two different ways this is called: diff --git a/lisp/simple.el b/lisp/simple.el index 7e964c9d1d5..ead973d45e0 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -2389,6 +2389,15 @@ function-documentation (cl-defmethod function-documentation ((function accessor)) (oclosure--accessor-docstring function)) ;; FIXME: =CE=B7-reduce! =20 +;; This should be in `oclosure.el' but that file is loaded before `cl-gene= ric'. +(cl-defgeneric oclosure-interactive-form (_function) + "Return the interactive form of FUNCTION or nil if none. +This is called by `interactive-form' when invoked on OClosures. +Add your methods to this generic function, but always call `interactive-fo= rm' +instead." + ;; (interactive-form function) + nil) + (defun command-execute (cmd &optional record-flag keys special) ;; BEWARE: Called directly from the C code. "Execute CMD as an editor command. diff --git a/src/callint.c b/src/callint.c index 31919d6bb81..92bfaf8d397 100644 --- a/src/callint.c +++ b/src/callint.c @@ -315,7 +315,7 @@ DEFUN ("call-interactively", Fcall_interactively, Scall= _interactively, 1, 3, 0, Lisp_Object up_event =3D Qnil; =20 /* Set SPECS to the interactive form, or barf if not interactive. */ - Lisp_Object form =3D Finteractive_form (function); + Lisp_Object form =3D call1 (Qinteractive_form, function); if (! CONSP (form)) wrong_type_argument (Qcommandp, function); Lisp_Object specs =3D Fcar (XCDR (form)); diff --git a/src/data.c b/src/data.c index 72af8a6648e..543590dfa31 100644 --- a/src/data.c +++ b/src/data.c @@ -1072,6 +1072,7 @@ DEFUN ("interactive-form", Finteractive_form, Sintera= ctive_form, 1, 1, 0, (Lisp_Object cmd) { Lisp_Object fun =3D indirect_function (cmd); /* Check cycles. */ + bool genfun =3D false; =20 if (NILP (fun)) return Qnil; @@ -1113,6 +1114,12 @@ DEFUN ("interactive-form", Finteractive_form, Sinter= active_form, 1, 1, 0, /* Old form -- just the interactive spec. */ return list2 (Qinteractive, form); } + else if (PVSIZE (fun) > COMPILED_DOC_STRING) + { + Lisp_Object doc =3D AREF (fun, COMPILED_DOC_STRING); + if (!(NILP (doc) || VALID_DOCSTRING_P (doc))) + genfun =3D true; + } } #ifdef HAVE_MODULES else if (MODULE_FUNCTIONP (fun)) @@ -1135,13 +1142,20 @@ DEFUN ("interactive-form", Finteractive_form, Sinte= ractive_form, 1, 1, 0, if (EQ (funcar, Qclosure)) form =3D Fcdr (form); Lisp_Object spec =3D Fassq (Qinteractive, form); - if (NILP (Fcdr (Fcdr (spec)))) + if (NILP (spec) && VALID_DOCSTRING_P (CAR_SAFE (form))) + genfun =3D true; + else if (NILP (Fcdr (Fcdr (spec)))) return spec; else return list2 (Qinteractive, Fcar (Fcdr (spec))); } } - return Qnil; + if (genfun + /* Avoid burping during bootstrap. */ + && !NILP (Fsymbol_function (Qoclosure_interactive_form))) + return call1 (Qoclosure_interactive_form, fun); + else + return Qnil; } =20 DEFUN ("command-modes", Fcommand_modes, Scommand_modes, 1, 1, 0, @@ -4123,6 +4137,7 @@ syms_of_data (void) DEFSYM (Qchar_table_p, "char-table-p"); DEFSYM (Qvector_or_char_table_p, "vector-or-char-table-p"); DEFSYM (Qfixnum_or_symbol_with_pos_p, "fixnum-or-symbol-with-pos-p"); + DEFSYM (Qoclosure_interactive_form, "oclosure-interactive-form"); =20 DEFSYM (Qsubrp, "subrp"); DEFSYM (Qunevalled, "unevalled"); diff --git a/src/doc.c b/src/doc.c index 5326195c6a0..71e66853b08 100644 --- a/src/doc.c +++ b/src/doc.c @@ -469,9 +469,7 @@ store_function_docstring (Lisp_Object obj, EMACS_INT of= fset) if (PVSIZE (fun) > COMPILED_DOC_STRING /* Don't overwrite a non-docstring value placed there, * such as the symbols used for Oclosures. */ - && (FIXNUMP (AREF (fun, COMPILED_DOC_STRING)) - || STRINGP (AREF (fun, COMPILED_DOC_STRING)) - || CONSP (AREF (fun, COMPILED_DOC_STRING)))) + && VALID_DOCSTRING_P (AREF (fun, COMPILED_DOC_STRING))) ASET (fun, COMPILED_DOC_STRING, make_fixnum (offset)); else { diff --git a/src/eval.c b/src/eval.c index 37bc03465cc..15e34790a1c 100644 --- a/src/eval.c +++ b/src/eval.c @@ -2032,8 +2032,7 @@ DEFUN ("commandp", Fcommandp, Scommandp, 1, 2, 0, (Lisp_Object function, Lisp_Object for_call_interactively) { register Lisp_Object fun; - register Lisp_Object funcar; - Lisp_Object if_prop =3D Qnil; + bool genfun =3D false; /* If true, we should consult `interactive-form`.= */ =20 fun =3D function; =20 @@ -2041,52 +2040,87 @@ DEFUN ("commandp", Fcommandp, Scommandp, 1, 2, 0, if (NILP (fun)) return Qnil; =20 - /* Check an `interactive-form' property if present, analogous to the - function-documentation property. */ - fun =3D function; - while (SYMBOLP (fun)) - { - Lisp_Object tmp =3D Fget (fun, Qinteractive_form); - if (!NILP (tmp)) - if_prop =3D Qt; - fun =3D Fsymbol_function (fun); - } - /* Emacs primitives are interactive if their DEFUN specifies an interactive spec. */ if (SUBRP (fun)) - return XSUBR (fun)->intspec.string ? Qt : if_prop; - + { + if (XSUBR (fun)->intspec.string) + return Qt; + } /* Bytecode objects are interactive if they are long enough to have an element whose index is COMPILED_INTERACTIVE, which is where the interactive spec is stored. */ else if (COMPILEDP (fun)) - return (PVSIZE (fun) > COMPILED_INTERACTIVE ? Qt : if_prop); + { + if (PVSIZE (fun) > COMPILED_INTERACTIVE) + return Qt; + else if (PVSIZE (fun) > COMPILED_DOC_STRING) + { + Lisp_Object doc =3D AREF (fun, COMPILED_DOC_STRING); + genfun =3D !(NILP (doc) || VALID_DOCSTRING_P (doc)); + } + } =20 #ifdef HAVE_MODULES /* Module functions are interactive if their `interactive_form' field is non-nil. */ else if (MODULE_FUNCTIONP (fun)) - return NILP (module_function_interactive_form (XMODULE_FUNCTION (fun))) - ? if_prop - : Qt; + { + if (!NILP (module_function_interactive_form (XMODULE_FUNCTION (fun))= )) + return Qt; + } #endif =20 /* Strings and vectors are keyboard macros. */ - if (STRINGP (fun) || VECTORP (fun)) + else if (STRINGP (fun) || VECTORP (fun)) return (NILP (for_call_interactively) ? Qt : Qnil); =20 /* Lists may represent commands. */ - if (!CONSP (fun)) + else if (!CONSP (fun)) return Qnil; - funcar =3D XCAR (fun); - if (EQ (funcar, Qclosure)) - return (!NILP (Fassq (Qinteractive, Fcdr (Fcdr (XCDR (fun))))) - ? Qt : if_prop); - else if (EQ (funcar, Qlambda)) - return !NILP (Fassq (Qinteractive, Fcdr (XCDR (fun)))) ? Qt : if_prop; - else if (EQ (funcar, Qautoload)) - return !NILP (Fcar (Fcdr (Fcdr (XCDR (fun))))) ? Qt : if_prop; + else + { + Lisp_Object funcar =3D XCAR (fun); + if (EQ (funcar, Qautoload)) + { + if (!NILP (Fcar (Fcdr (Fcdr (XCDR (fun)))))) + return Qt; + } + else + { + Lisp_Object body =3D CDR_SAFE (XCDR (fun)); + if (EQ (funcar, Qclosure)) + body =3D CDR_SAFE (body); + else if (!EQ (funcar, Qlambda)) + return Qnil; + if (!NILP (Fassq (Qinteractive, body))) + return Qt; + else if (VALID_DOCSTRING_P (CAR_SAFE (body))) + genfun =3D true; + } + } + + /* By now, if it's not a function we already returned nil. */ + + /* Check an `interactive-form' property if present, analogous to the + function-documentation property. */ + fun =3D function; + while (SYMBOLP (fun)) + { + Lisp_Object tmp =3D Fget (fun, Qinteractive_form); + if (!NILP (tmp)) + error ("Found an `interactive-form` property!"); + fun =3D Fsymbol_function (fun); + } + + /* If there's no immediate interactive form but it's an OClosure, + then delegate to the generic-function in case it has + a type-specific interactive-form. */ + if (genfun) + { + Lisp_Object iform =3D call1 (Qinteractive_form, fun); + return NILP (iform) ? Qnil : Qt; + } else return Qnil; } diff --git a/src/lisp.h b/src/lisp.h index 75f369f5245..1ad89fc4689 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -2185,6 +2185,16 @@ XSUBR (Lisp_Object a) return &XUNTAG (a, Lisp_Vectorlike, union Aligned_Lisp_Subr)->s; } =20 +/* Return whether a value might be a valid docstring. + Used to distinguish the presence of non-docstring in the docstring slot, + as in the case of OClosures. */ +INLINE bool +VALID_DOCSTRING_P (Lisp_Object doc) +{ + return FIXNUMP (doc) || STRINGP (doc) + || (CONSP (doc) && STRINGP (XCAR (doc)) && FIXNUMP (XCDR (doc))); +} + enum char_table_specials { /* This is the number of slots that every char table must have. This diff --git a/test/lisp/emacs-lisp/oclosure-tests.el b/test/lisp/emacs-lisp/= oclosure-tests.el index b6bdebc0a2b..1af40bcdab4 100644 --- a/test/lisp/emacs-lisp/oclosure-tests.el +++ b/test/lisp/emacs-lisp/oclosure-tests.el @@ -106,6 +106,27 @@ oclosure-test-limits (and (eq 'error (car err)) (string-match "Duplicate slot: fst$" (cadr err))))))) =20 +(cl-defmethod oclosure-interactive-form ((ot oclosure-test)) + (let ((snd (oclosure-test--snd ot))) + (if (stringp snd) (list 'interactive snd)))) + +(ert-deftest oclosure-test-interactive-form () + (should (equal (interactive-form + (oclosure-lambda (oclosure-test (fst 1) (snd 2)) + () fst)) + nil)) + (should (equal (interactive-form + (oclosure-lambda (oclosure-test (fst 1) (snd 2)) + () + (interactive "r") + fst)) + '(interactive "r"))) + (should (equal (interactive-form + (oclosure-lambda (oclosure-test (fst 1) (snd "P")) + () + fst)) + '(interactive "P")))) + (oclosure-define (oclosure-test-mut (:parent oclosure-test) (:copier oclosure-test-mut-copy)) From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 12:35:57 2022 Received: (at 54802) by debbugs.gnu.org; 19 Apr 2022 16:35:57 +0000 Received: from localhost ([127.0.0.1]:43992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngqpY-0001fI-TM for submit@debbugs.gnu.org; Tue, 19 Apr 2022 12:35:57 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngqpX-0001f6-On for 54802@debbugs.gnu.org; Tue, 19 Apr 2022 12:35:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43888) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ngqpS-0007TO-D2; Tue, 19 Apr 2022 12:35:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dnXucNKovOyqaE2bRHSe88wqR1d/VpiAcTGDWMfRPkA=; b=MCSHw4BXmqj3 tlOq61x1XZ930Ijaflm/ccjzJcOTiVtlDSNtT0ICSo5CVo8Lj669pQpnl/luKQ0FRLwUyl7C2V2h3 L8jqYSCh1wChjoqr28OH0MgQ+zx2nxzc0bpHwRorfcwnWb1jCF5PkBWZTEQkkCvFLnxBQq/1yIjRf u9V7rbrqILwON7mpmy2u1m1K7yZVPtvu+BZLlJkLnCYqrsbVmarF7GTqqT0H4pOcAylj7IB2ndv4I V4wR1fetl4MU71El8/Vy6gtB9VJ7a+/Rlazbzb1as0gce3aI6HjXtX4v7SQjQIg61jZ3kBEjPCgIG ZL6bv+rweRHc7iyNgamH/A==; Received: from [87.69.77.57] (port=1105 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ngqpL-0007uO-Hh; Tue, 19 Apr 2022 12:35:50 -0400 Date: Tue, 19 Apr 2022 19:35:34 +0300 Message-Id: <837d7luj3d.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 19 Apr 2022 10:53:06 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Here is an alternative patch which does not make `interactive-form` > a generic function, but instead does what we discussed with Po, > i.e. introduce a new generic function to which `interactive-form` > delegates the work when it encounters an OClosure. > > This way, we avoid slowdowns both for `commandp` and for > `interactive-form` and it minimizes the changes to `interactive-form`. Thanks. A few minor comments below: > diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi > index ace0c025512..16712fd7cb7 100644 > --- a/doc/lispref/commands.texi > +++ b/doc/lispref/commands.texi > @@ -312,6 +312,9 @@ Using Interactive > specifies how to compute its arguments. Otherwise, the value is > @code{nil}. If @var{function} is a symbol, its function definition is > used. > +When called on an OClosure, the work is delegated to the generic > +function @code{oclosure-interactive-form}, where additional methods > +can be used for specific OClosure types, e.g. for advice and keyboard macros. > @end defun I think oclosure-interactive-form should be documented in more detail, since we will probably see it used more and more in the future. E.g., we should say something about all those "additional methods" that are only hinted above. > diff --git a/lisp/kmacro.el b/lisp/kmacro.el > index 8a9d89929eb..5476c2395ca 100644 > --- a/lisp/kmacro.el > +++ b/lisp/kmacro.el > @@ -820,13 +820,14 @@ kmacro > (counter (or counter 0)) > (format (or format "%d"))) > (&optional arg) > - (interactive "p") > ;; Use counter and format specific to the macro on the ring! > (let ((kmacro-counter counter) > (kmacro-counter-format-start format)) > (execute-kbd-macro keys arg #'kmacro-loop-setup-function) > (setq counter kmacro-counter)))) > > +(cl-defmethod oclosure-interactive-form ((_ kmacro)) '(interactive "p")) So suppose we'd like later to modify the interactive form of kmacro to use Lisp code instead of just the "p" thing -- how should we go about that? Does oclosure-interactive-form accept everything that 'interactive' accepts? Does it use the same syntax, or will we need to use some special quoting there? I also wonder whether this will make commands harder to spot just by looking at their code than it is now. > + else if (PVSIZE (fun) > COMPILED_DOC_STRING) > + { > + Lisp_Object doc = AREF (fun, COMPILED_DOC_STRING); > + if (!(NILP (doc) || VALID_DOCSTRING_P (doc))) > + genfun = true; > + } There should be a comment there explaining the significance of comparison with COMPILED_DOC_STRING and why this turns on the genfun flag. > + bool genfun = false; /* If true, we should consult `interactive-form`. */ Please don't use Markdown-style quoting in code comments. > /* Bytecode objects are interactive if they are long enough to > have an element whose index is COMPILED_INTERACTIVE, which is > where the interactive spec is stored. */ > else if (COMPILEDP (fun)) > - return (PVSIZE (fun) > COMPILED_INTERACTIVE ? Qt : if_prop); > + { > + if (PVSIZE (fun) > COMPILED_INTERACTIVE) > + return Qt; > + else if (PVSIZE (fun) > COMPILED_DOC_STRING) > + { > + Lisp_Object doc = AREF (fun, COMPILED_DOC_STRING); > + genfun = !(NILP (doc) || VALID_DOCSTRING_P (doc)); > + } > + } Here, too, the significance of comparison with COMPILED_DOC_STRING should be explained in a comment. > /* Strings and vectors are keyboard macros. */ > - if (STRINGP (fun) || VECTORP (fun)) > + else if (STRINGP (fun) || VECTORP (fun)) > return (NILP (for_call_interactively) ? Qt : Qnil); > > /* Lists may represent commands. */ > - if (!CONSP (fun)) > + else if (!CONSP (fun)) > return Qnil; I don't understand why you replace 'if' with 'else if' here: are they just stylistic preferences? If so, I'd prefer to leave the original code intact where it doesn't have to be changed. > + while (SYMBOLP (fun)) > + { > + Lisp_Object tmp = Fget (fun, Qinteractive_form); > + if (!NILP (tmp)) > + error ("Found an `interactive-form` property!"); Please quote `like this' in error messages, as text-quoting-style expects that. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 13:52:24 2022 Received: (at 54802) by debbugs.gnu.org; 19 Apr 2022 17:52:24 +0000 Received: from localhost ([127.0.0.1]:44072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngs1X-0003cg-LK for submit@debbugs.gnu.org; Tue, 19 Apr 2022 13:52:24 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngs1V-0003cT-F7 for 54802@debbugs.gnu.org; Tue, 19 Apr 2022 13:52:22 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D28F580664; Tue, 19 Apr 2022 13:52:15 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B517480539; Tue, 19 Apr 2022 13:52:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1650390732; bh=hlUK/I3CH9q+8bv0juc/XuPT1azXqiiWuWuZpk/t3Sg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=R8pFQ/TZ4wdn3j2PM9idXXcYTVWFGT08rQAWdeg+yx5BcfVBK3cVwtb67jPD3M0ju G6ucsSzHpGkrYwP1GFsoWbopXcA3fG/T5kiSatJIW+vW+v2v4LDm6mhnHvA+pG+1BL FP3026V1J1yykwYjDOijUYVD2HKZuDmuNUTOE50/wGt3yDiJSIlOrmdE5/aYZLCBIY l4rLp05BRN8q002u9nYD791vO/OozWrkbUImzN2Hf3z1QRr/cuyuibyK1DGsAksZlb RNIcK5P26v9pSegqgqco6Ix3ZfsGIxI6i7sUX+jsc5Djet8CoxdDI7JR29+oBoZAYH gdAidr9De+NTQ== Received: from alfajor (modemcable124.78-161-184.mc.videotron.ca [184.161.78.124]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7AE56120218; Tue, 19 Apr 2022 13:52:12 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function In-Reply-To: <837d7luj3d.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Apr 2022 19:35:34 +0300") Message-ID: References: <837d7luj3d.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Date: Tue, 19 Apr 2022 13:52:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.058 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Thanks. A few minor comments below: See updated patch after my sig. > I think oclosure-interactive-form should be documented in more detail, > since we will probably see it used more and more in the future. E.g., > we should say something about all those "additional methods" that are > only hinted above. I tried to do that. Let me know if that fits your expectations. > So suppose we'd like later to modify the interactive form of kmacro to > use Lisp code instead of just the "p" thing -- how should we go about > that? Does oclosure-interactive-form accept everything that > 'interactive' accepts? Currently, it is fundamentally defined not by the syntax of the `interactive` thingy in source code but by what `call-interactively` expects as return value of `interactive-form`. So yes, it can return `(interactive (list ))` just fine. OTOH it currently doesn't offer any way to have an OClosure with a non-nil `command-modes`. I.e. if you return (interactive (list gomoku-mode)) the `gomoku-mode` part will not be understood as a `commands-mode` spec and may even cause trouble since `interactive-form` is not expected to return something of this form (tho most callers just extract the form with `cadr` and just ignore any extra elements). Maybe you're right that we should define the return value as "whatever is accepted in the `interactive` source thingy", and then arrange for `command-modes` to delegate to `oclosure-interactive-mode`? > Does it use the same syntax, or will we need > to use some special quoting there? No special quoting, no. > I also wonder whether this will make commands harder to spot just by > looking at their code than it is now. Indeed, it is better not to abuse it. >> + else if (PVSIZE (fun) > COMPILED_DOC_STRING) >> + { >> + Lisp_Object doc =3D AREF (fun, COMPILED_DOC_STRING); >> + if (!(NILP (doc) || VALID_DOCSTRING_P (doc))) >> + genfun =3D true; >> + } > > There should be a comment there explaining the significance of > comparison with COMPILED_DOC_STRING and why this turns on the genfun > flag. Added. >> + bool genfun =3D false; /* If true, we should consult `interactive-for= m`. */ > Please don't use Markdown-style quoting in code comments. Duh, sorry, they were "everywhere". >> /* Lists may represent commands. */ >> - if (!CONSP (fun)) >> + else if (!CONSP (fun)) >> return Qnil; > > I don't understand why you replace 'if' with 'else if' here: are they > just stylistic preferences? If so, I'd prefer to leave the original > code intact where it doesn't have to be changed. That was a left over from an earlier code reorg. Stefan diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi index ace0c025512..6c60216796c 100644 --- a/doc/lispref/commands.texi +++ b/doc/lispref/commands.texi @@ -312,6 +312,25 @@ Using Interactive specifies how to compute its arguments. Otherwise, the value is @code{nil}. If @var{function} is a symbol, its function definition is used. +When called on an OClosure, the work is delegated to the generic +function @code{oclosure-interactive-form}. +@end defun + +@defun oclosure-interactive-form function +Just like @code{interactive-form}, this function takes a command and +returns its interactive form. The difference is that it is a generic +function and it is only called when @var{function} is an OClosure. +The purpose is to make it possible for some OClosure types to compute +their interactive forms dynamically instead of carrying it in one of +their slots. + +This is used for example for @code{kmacro} functions in order to +reduce their memory size, since they all share the same interactive +form. It is also used for @code{advice} functions, where the +interactive form is computed from the interactive forms of its +components, so as to make this computation more lazily and to +correctly adjust the interactive form when one of its component's +is redefined. @end defun =20 @node Interactive Codes diff --git a/etc/NEWS b/etc/NEWS index 3442ebd81b3..62b7128fea5 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1292,6 +1292,11 @@ remote host are shown. Alternatively, the user opti= on Allows the creation of "functions with slots" or "function objects" via the macros 'oclosure-define' and 'oclosure-lambda'. =20 +*** New generic function 'oclosure-interactive-form'. +Used by 'interactive-form' when called on an OClosure. +This allows specific OClosure types to compute their interactive specs +on demand rather than precompute them when created. + --- ** New theme 'leuven-dark'. This is a dark version of the 'leuven' theme. diff --git a/lisp/kmacro.el b/lisp/kmacro.el index 8a9d89929eb..5476c2395ca 100644 --- a/lisp/kmacro.el +++ b/lisp/kmacro.el @@ -820,13 +820,14 @@ kmacro (counter (or counter 0)) (format (or format "%d"))) (&optional arg) - (interactive "p") ;; Use counter and format specific to the macro on the ring! (let ((kmacro-counter counter) (kmacro-counter-format-start format)) (execute-kbd-macro keys arg #'kmacro-loop-setup-function) (setq counter kmacro-counter)))) =20 +(cl-defmethod oclosure-interactive-form ((_ kmacro)) '(interactive "p")) + ;;;###autoload (defun kmacro-lambda-form (mac &optional counter format) ;; Apparently, there are two different ways this is called: diff --git a/lisp/simple.el b/lisp/simple.el index 7e964c9d1d5..ead973d45e0 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -2389,6 +2389,15 @@ function-documentation (cl-defmethod function-documentation ((function accessor)) (oclosure--accessor-docstring function)) ;; FIXME: =CE=B7-reduce! =20 +;; This should be in `oclosure.el' but that file is loaded before `cl-gene= ric'. +(cl-defgeneric oclosure-interactive-form (_function) + "Return the interactive form of FUNCTION or nil if none. +This is called by `interactive-form' when invoked on OClosures. +Add your methods to this generic function, but always call `interactive-fo= rm' +instead." + ;; (interactive-form function) + nil) + (defun command-execute (cmd &optional record-flag keys special) ;; BEWARE: Called directly from the C code. "Execute CMD as an editor command. diff --git a/src/callint.c b/src/callint.c index 31919d6bb81..92bfaf8d397 100644 --- a/src/callint.c +++ b/src/callint.c @@ -315,7 +315,7 @@ DEFUN ("call-interactively", Fcall_interactively, Scall= _interactively, 1, 3, 0, Lisp_Object up_event =3D Qnil; =20 /* Set SPECS to the interactive form, or barf if not interactive. */ - Lisp_Object form =3D Finteractive_form (function); + Lisp_Object form =3D call1 (Qinteractive_form, function); if (! CONSP (form)) wrong_type_argument (Qcommandp, function); Lisp_Object specs =3D Fcar (XCDR (form)); diff --git a/src/data.c b/src/data.c index 72af8a6648e..e9aad75f59b 100644 --- a/src/data.c +++ b/src/data.c @@ -1072,6 +1072,7 @@ DEFUN ("interactive-form", Finteractive_form, Sintera= ctive_form, 1, 1, 0, (Lisp_Object cmd) { Lisp_Object fun =3D indirect_function (cmd); /* Check cycles. */ + bool genfun =3D false; =20 if (NILP (fun)) return Qnil; @@ -1113,6 +1114,12 @@ DEFUN ("interactive-form", Finteractive_form, Sinter= active_form, 1, 1, 0, /* Old form -- just the interactive spec. */ return list2 (Qinteractive, form); } + else if (PVSIZE (fun) > COMPILED_DOC_STRING) + { + Lisp_Object doc =3D AREF (fun, COMPILED_DOC_STRING); + /* An invalid "docstring" is a sign that we have an OClosure. */ + genfun =3D !(NILP (doc) || VALID_DOCSTRING_P (doc)); + } } #ifdef HAVE_MODULES else if (MODULE_FUNCTIONP (fun)) @@ -1135,13 +1142,21 @@ DEFUN ("interactive-form", Finteractive_form, Sinte= ractive_form, 1, 1, 0, if (EQ (funcar, Qclosure)) form =3D Fcdr (form); Lisp_Object spec =3D Fassq (Qinteractive, form); - if (NILP (Fcdr (Fcdr (spec)))) + if (NILP (spec) && VALID_DOCSTRING_P (CAR_SAFE (form))) + /* A "docstring" is a sign that we may have an OClosure. */ + genfun =3D true; + else if (NILP (Fcdr (Fcdr (spec)))) return spec; else return list2 (Qinteractive, Fcar (Fcdr (spec))); } } - return Qnil; + if (genfun + /* Avoid burping during bootstrap. */ + && !NILP (Fsymbol_function (Qoclosure_interactive_form))) + return call1 (Qoclosure_interactive_form, fun); + else + return Qnil; } =20 DEFUN ("command-modes", Fcommand_modes, Scommand_modes, 1, 1, 0, @@ -4123,6 +4138,7 @@ syms_of_data (void) DEFSYM (Qchar_table_p, "char-table-p"); DEFSYM (Qvector_or_char_table_p, "vector-or-char-table-p"); DEFSYM (Qfixnum_or_symbol_with_pos_p, "fixnum-or-symbol-with-pos-p"); + DEFSYM (Qoclosure_interactive_form, "oclosure-interactive-form"); =20 DEFSYM (Qsubrp, "subrp"); DEFSYM (Qunevalled, "unevalled"); diff --git a/src/doc.c b/src/doc.c index 5326195c6a0..71e66853b08 100644 --- a/src/doc.c +++ b/src/doc.c @@ -469,9 +469,7 @@ store_function_docstring (Lisp_Object obj, EMACS_INT of= fset) if (PVSIZE (fun) > COMPILED_DOC_STRING /* Don't overwrite a non-docstring value placed there, * such as the symbols used for Oclosures. */ - && (FIXNUMP (AREF (fun, COMPILED_DOC_STRING)) - || STRINGP (AREF (fun, COMPILED_DOC_STRING)) - || CONSP (AREF (fun, COMPILED_DOC_STRING)))) + && VALID_DOCSTRING_P (AREF (fun, COMPILED_DOC_STRING))) ASET (fun, COMPILED_DOC_STRING, make_fixnum (offset)); else { diff --git a/src/eval.c b/src/eval.c index 37bc03465cc..1de59518381 100644 --- a/src/eval.c +++ b/src/eval.c @@ -2032,8 +2032,7 @@ DEFUN ("commandp", Fcommandp, Scommandp, 1, 2, 0, (Lisp_Object function, Lisp_Object for_call_interactively) { register Lisp_Object fun; - register Lisp_Object funcar; - Lisp_Object if_prop =3D Qnil; + bool genfun =3D false; /* If true, we should consult `interactive-form'.= */ =20 fun =3D function; =20 @@ -2041,52 +2040,89 @@ DEFUN ("commandp", Fcommandp, Scommandp, 1, 2, 0, if (NILP (fun)) return Qnil; =20 - /* Check an `interactive-form' property if present, analogous to the - function-documentation property. */ - fun =3D function; - while (SYMBOLP (fun)) - { - Lisp_Object tmp =3D Fget (fun, Qinteractive_form); - if (!NILP (tmp)) - if_prop =3D Qt; - fun =3D Fsymbol_function (fun); - } - /* Emacs primitives are interactive if their DEFUN specifies an interactive spec. */ if (SUBRP (fun)) - return XSUBR (fun)->intspec.string ? Qt : if_prop; - + { + if (XSUBR (fun)->intspec.string) + return Qt; + } /* Bytecode objects are interactive if they are long enough to have an element whose index is COMPILED_INTERACTIVE, which is where the interactive spec is stored. */ else if (COMPILEDP (fun)) - return (PVSIZE (fun) > COMPILED_INTERACTIVE ? Qt : if_prop); + { + if (PVSIZE (fun) > COMPILED_INTERACTIVE) + return Qt; + else if (PVSIZE (fun) > COMPILED_DOC_STRING) + { + Lisp_Object doc =3D AREF (fun, COMPILED_DOC_STRING); + /* An invalid "docstring" is a sign that we have an OClosure. */ + genfun =3D !(NILP (doc) || VALID_DOCSTRING_P (doc)); + } + } =20 #ifdef HAVE_MODULES /* Module functions are interactive if their `interactive_form' field is non-nil. */ else if (MODULE_FUNCTIONP (fun)) - return NILP (module_function_interactive_form (XMODULE_FUNCTION (fun))) - ? if_prop - : Qt; + { + if (!NILP (module_function_interactive_form (XMODULE_FUNCTION (fun))= )) + return Qt; + } #endif =20 /* Strings and vectors are keyboard macros. */ - if (STRINGP (fun) || VECTORP (fun)) + else if (STRINGP (fun) || VECTORP (fun)) return (NILP (for_call_interactively) ? Qt : Qnil); =20 /* Lists may represent commands. */ if (!CONSP (fun)) return Qnil; - funcar =3D XCAR (fun); - if (EQ (funcar, Qclosure)) - return (!NILP (Fassq (Qinteractive, Fcdr (Fcdr (XCDR (fun))))) - ? Qt : if_prop); - else if (EQ (funcar, Qlambda)) - return !NILP (Fassq (Qinteractive, Fcdr (XCDR (fun)))) ? Qt : if_prop; - else if (EQ (funcar, Qautoload)) - return !NILP (Fcar (Fcdr (Fcdr (XCDR (fun))))) ? Qt : if_prop; + else + { + Lisp_Object funcar =3D XCAR (fun); + if (EQ (funcar, Qautoload)) + { + if (!NILP (Fcar (Fcdr (Fcdr (XCDR (fun)))))) + return Qt; + } + else + { + Lisp_Object body =3D CDR_SAFE (XCDR (fun)); + if (EQ (funcar, Qclosure)) + body =3D CDR_SAFE (body); + else if (!EQ (funcar, Qlambda)) + return Qnil; + if (!NILP (Fassq (Qinteractive, body))) + return Qt; + else if (VALID_DOCSTRING_P (CAR_SAFE (body))) + /* A "docstring" is a sign that we may have an OClosure. */ + genfun =3D true; + } + } + + /* By now, if it's not a function we already returned nil. */ + + /* Check an `interactive-form' property if present, analogous to the + function-documentation property. */ + fun =3D function; + while (SYMBOLP (fun)) + { + Lisp_Object tmp =3D Fget (fun, Qinteractive_form); + if (!NILP (tmp)) + error ("Found an 'interactive-form' property!"); + fun =3D Fsymbol_function (fun); + } + + /* If there's no immediate interactive form but it's an OClosure, + then delegate to the generic-function in case it has + a type-specific interactive-form. */ + if (genfun) + { + Lisp_Object iform =3D call1 (Qinteractive_form, fun); + return NILP (iform) ? Qnil : Qt; + } else return Qnil; } diff --git a/src/lisp.h b/src/lisp.h index 75f369f5245..1ad89fc4689 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -2185,6 +2185,16 @@ XSUBR (Lisp_Object a) return &XUNTAG (a, Lisp_Vectorlike, union Aligned_Lisp_Subr)->s; } =20 +/* Return whether a value might be a valid docstring. + Used to distinguish the presence of non-docstring in the docstring slot, + as in the case of OClosures. */ +INLINE bool +VALID_DOCSTRING_P (Lisp_Object doc) +{ + return FIXNUMP (doc) || STRINGP (doc) + || (CONSP (doc) && STRINGP (XCAR (doc)) && FIXNUMP (XCDR (doc))); +} + enum char_table_specials { /* This is the number of slots that every char table must have. This diff --git a/test/lisp/emacs-lisp/oclosure-tests.el b/test/lisp/emacs-lisp/= oclosure-tests.el index b6bdebc0a2b..1af40bcdab4 100644 --- a/test/lisp/emacs-lisp/oclosure-tests.el +++ b/test/lisp/emacs-lisp/oclosure-tests.el @@ -106,6 +106,27 @@ oclosure-test-limits (and (eq 'error (car err)) (string-match "Duplicate slot: fst$" (cadr err))))))) =20 +(cl-defmethod oclosure-interactive-form ((ot oclosure-test)) + (let ((snd (oclosure-test--snd ot))) + (if (stringp snd) (list 'interactive snd)))) + +(ert-deftest oclosure-test-interactive-form () + (should (equal (interactive-form + (oclosure-lambda (oclosure-test (fst 1) (snd 2)) + () fst)) + nil)) + (should (equal (interactive-form + (oclosure-lambda (oclosure-test (fst 1) (snd 2)) + () + (interactive "r") + fst)) + '(interactive "r"))) + (should (equal (interactive-form + (oclosure-lambda (oclosure-test (fst 1) (snd "P")) + () + fst)) + '(interactive "P")))) + (oclosure-define (oclosure-test-mut (:parent oclosure-test) (:copier oclosure-test-mut-copy)) From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 10:38:21 2022 Received: (at 54802-done) by debbugs.gnu.org; 26 Apr 2022 14:38:21 +0000 Received: from localhost ([127.0.0.1]:40232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njMKb-00054W-CL for submit@debbugs.gnu.org; Tue, 26 Apr 2022 10:38:21 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njMKa-00054J-3D for 54802-done@debbugs.gnu.org; Tue, 26 Apr 2022 10:38:20 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 728B710027D; Tue, 26 Apr 2022 10:38:14 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0C18810000A; Tue, 26 Apr 2022 10:38:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1650983893; bh=6esydPXX63VD8/AXsapR/FCGY1NKEd8Rvz5UcHAaG5s=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=eSfyI1ADh8M7IwjJV3CHFq1Pdl3aTHiYHU1oVoFGEitURKz3hhW7z6G94PPnhad48 pSLkaMZhNZaT3SSTQatlq+cz++gcEZV0/s4sb0tGcr7eAtBcr/2/FX0r/XACr6dZRo DTvhr5vuhTYzvuxx5mX6PDdlpxvGyQ1AEYDAbseqkfE2qz274Ai0Xn99vR7dKf0eW3 DvqNMwXbM9L1ol5W7FXv5+MaoyaPkLmtmmlEsGxgqtvCht4uWblNQ71PJZGH8gD0Dg PkTTWqgE4CTjbVnAjeQuKWlxVqXAP6+s1eGKyt7f938LO5pKEQG9wdpx7gqdTfSuS+ eqUzfH/mlRBfw== Received: from alfajor (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C58E7120790; Tue, 26 Apr 2022 10:38:12 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function Message-ID: References: <837d7luj3d.fsf@gnu.org> Date: Tue, 26 Apr 2022 10:38:11 -0400 In-Reply-To: (Stefan Monnier's message of "Tue, 19 Apr 2022 13:52:10 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.049 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802-done Cc: 54802-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > See updated patch after my sig. Pushed with a few more tweaks, Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 12:05:17 2022 Received: (at 54802) by debbugs.gnu.org; 27 Apr 2022 16:05:18 +0000 Received: from localhost ([127.0.0.1]:44026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njkAH-0002Mt-IY for submit@debbugs.gnu.org; Wed, 27 Apr 2022 12:05:17 -0400 Received: from mail-ed1-f44.google.com ([209.85.208.44]:37800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njkAG-0002Mb-2f for 54802@debbugs.gnu.org; Wed, 27 Apr 2022 12:05:16 -0400 Received: by mail-ed1-f44.google.com with SMTP id k27so2497055edk.4 for <54802@debbugs.gnu.org>; Wed, 27 Apr 2022 09:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=WV77YJwTZYfIMo/iDaVO4KMUgApIk7AYUBQJMGrqe5w=; b=KcjobXPKoSdyt3bmEvigRRuISnCusBE2KmYBd3mulHtp15i+VUV22BO0+hsNZ5DEgi KNN9VseoLVmezhHVfVvQtzorb3IKoXCSUE64Pj3wb9yuvhncF/ZEakELQSU433lUqaHJ Q/3VQzDsxtrjquRDeHCxt7qe/gYvQ7ggU+vOecIcCQBQaKYljqqGB5/KnP477Bjx67fq wKh30Cda2CL3VotJIpUQibNeJmqOTjkzDCc/eEw6cUp6LyYPz0UGUhfutVGs6n8SWmyU Y9n8lszjp/pYLnjFdPKaE3D5xC9ibvobcRSgzSqgTF6xfs2opRFeyQHgL5L5rzuHP49A uhbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=WV77YJwTZYfIMo/iDaVO4KMUgApIk7AYUBQJMGrqe5w=; b=zr+z3k6pRPScHC6n5DE8im9HyNSBunuBEhROvDjW57R+oKD7A7PvFn28rIUHqqdImo zBotsiyJ9jAPv2ZaDSOxAj/TAC5p1uz53X9nKeQ+gMvijlYqrSuBRShektxSZOs7XXC7 NqhvK1noqRVeakepfurY2wCFVlC8TjQFZKEMWiUjP5uWePfBi4U1XQT2hgYik6G7dvwJ 7/O+hBjmVnv1EoK1ZLs3jWb1Axv9hif89Q/8P+8uRznHTsqsW0q0mtMS3VhaoyrvCiZo D5QGsY5ddslc3Z1jJ+Ba6I7n/GVF7dU/Is54eZth69CAFcNuLK4bZTRoVzNjQZ1Bu9iF C6aw== X-Gm-Message-State: AOAM530AcoS3V85kqu+fBhhNBVuz+ve+uo3FhR5+XOldJ1m86J2rHC8N T8QWbB7neyKYV4Xvn8Etdt2w+w== X-Google-Smtp-Source: ABdhPJx9ThjoQdLumj6JNBOyJUiLdiH5fhSD3sTzzON4oHmepZnvdZkr+7hnoQl0sl5g4IQaSoZ7nQ== X-Received: by 2002:a50:8d09:0:b0:41c:b898:19a6 with SMTP id s9-20020a508d09000000b0041cb89819a6mr31611314eds.30.1651075505892; Wed, 27 Apr 2022 09:05:05 -0700 (PDT) Received: from localhost ([2a02:587:321e:9d88:abda:ed96:a296:cb1f]) by smtp.gmail.com with ESMTPSA id c6-20020a50f606000000b00425adbac753sm8691316edn.21.2022.04.27.09.05.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 09:05:05 -0700 (PDT) From: "Basil L. Contovounesios" To: Stefan Monnier Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <837d7luj3d.fsf@gnu.org> Date: Wed, 27 Apr 2022 19:05:03 +0300 In-Reply-To: (Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors"'s message of "Tue, 19 Apr 2022 13:52:10 -0400") Message-ID: <87h76e8qc0.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54802 Cc: Eli Zaretskii , 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text= editors" [2022-04-19 13:52 -0400] wrote: > @@ -2041,52 +2040,89 @@ DEFUN ("commandp", Fcommandp, Scommandp, 1, 2, 0, [...] > + /* By now, if it's not a function we already returned nil. */ > + > + /* Check an `interactive-form' property if present, analogous to the > + function-documentation property. */ > + fun =3D function; > + while (SYMBOLP (fun)) > + { > + Lisp_Object tmp =3D Fget (fun, Qinteractive_form); > + if (!NILP (tmp)) > + error ("Found an 'interactive-form' property!"); > + fun =3D Fsymbol_function (fun); > + } error ("Success!"); Why is it now an error for functions to have an interactive-form property? The Elisp manual is careful to describe this practice as unusual, but nevertheless supported, e.g. in cases such as: 0. emacs -Q -f toggle-debug-on-error 1. (progn (defun my-foo (&rest _)) (function-put 'my-foo 'interactive-form (interactive-form 'ignore))) 2. C-x C-e 3. M-x C-i Debugger entered--Lisp error: (error "Found an =E2=80=99interactive-form=E2= =80=99 property!") commandp(my-foo) [...] Thanks, --=20 Basil In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo versio= n 1.16.0, Xaw3d scroll bars) of 2022-04-27 built on tia Repository revision: 0beb8fd663663dcaa1bda4df5995d10f1ef615fb Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101003 System Description: Debian GNU/Linux bookworm/sid Configured using: 'configure 'CFLAGS=3D-Og -ggdb3' --config-cache --prefix /home/blc/.local --enable-checking=3Dstructs --with-x-toolkit=3Dlucid --with-file-notification=3Dyes --with-xinput2 --with-x' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB From unknown Sun Jun 22 03:56:30 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 26 May 2022 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 11 17:23:09 2022 Received: (at control) by debbugs.gnu.org; 11 Jun 2022 21:23:09 +0000 Received: from localhost ([127.0.0.1]:54139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o08ZZ-0001p0-5M for submit@debbugs.gnu.org; Sat, 11 Jun 2022 17:23:09 -0400 Received: from mail-ej1-f51.google.com ([209.85.218.51]:43905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o08ZV-0001oG-NW for control@debbugs.gnu.org; Sat, 11 Jun 2022 17:23:08 -0400 Received: by mail-ej1-f51.google.com with SMTP id m20so4199123ejj.10 for ; Sat, 11 Jun 2022 14:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=from:to:subject:date:message-id:mime-version; bh=obXNIn5QD29ulk/CjSqHRjGQa/1A4MeCwa3Z1lEvZi0=; b=ZVSmV2r59jXHuPuZuJDI8wsN48v+BoHbDsXcpOlhnOsNPg9EM+VsmJxZ8Tocf2F0v+ yDhAog2vx/tomshkzYcGQFvWG5eC44uE2kLoOD2aMaIAF1K9X6Ib2OpAXIyg59MPP7zz hRQsK52pn75ujxqZBgrtc6pmaN8JyWX3aTvjETh8yeMXaYhTmcwbfmI2DBs6zUURam5O rYOlXwQkBmGRn+5vIK+oL9xBeVF/sY6WG/kpYJw5hMUw+76cNZwHFmTnQ7rUI+LCLu3z f9D3IQjqrTf2JtRTLsTB/v80D4aTkBK+h5U/Po9T0FcNZUD4wpd7OxFjyqTCbHxi9YlQ OcNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=obXNIn5QD29ulk/CjSqHRjGQa/1A4MeCwa3Z1lEvZi0=; b=qiR5i+6sd1RYcNvKwiiTlLP/++aAG6qF3ltq7MhrrLLQ2Tb5+oJPElrbT5xeOBYLlT whWrA0kXlxZHCgJ44UR06TOQ5anVpwCp642d6ximzyApdO9IYcR9d//PBpfWx6IDf2Ua cS5E53+ACb+3WWXud0kmWSvwPPqzKRCHXi5VMbJXQO/LOXhfLdWcTUlBJ/6E3eAjuqLC 4vT0BYIqP1wd8BBuJY0Vul76+46/PnLNP7i7Y1QGrEyUxq++XniQZstJNAMMl+jVX/et Z3LIbpcQA9eZyrJ+MhEqbp8heDNTjgIW7vE+4RH+HwDPqWBKFto7i+A0xcWAMlctsNji UMyg== X-Gm-Message-State: AOAM530qme3+8NLMBYbMtmoTeWLxEszQlz71twDlK48Korz8ly/N1QLG oohR81CXg47NhCQcJB1p1u3wdi6PtTIy4w== X-Google-Smtp-Source: ABdhPJyeriiHsv0nt1ftD+irmA2se9GjzkWxrfrxg/I5DCjj41LHGZz0THE6PPLRyqvYv2LhiYDnMQ== X-Received: by 2002:a17:907:7781:b0:6fe:4398:47b3 with SMTP id ky1-20020a170907778100b006fe439847b3mr12584328ejc.513.1654982579393; Sat, 11 Jun 2022 14:22:59 -0700 (PDT) Received: from localhost ([2a02:587:322b:6f5e:dc92:136a:a7c4:dc8c]) by smtp.gmail.com with ESMTPSA id j10-20020a50d00a000000b004319b12371asm2043170edf.47.2022.06.11.14.22.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jun 2022 14:22:58 -0700 (PDT) From: "Basil L. Contovounesios" To: control@debbugs.gnu.org Subject: control message for bug #54802 Date: Sun, 12 Jun 2022 00:22:56 +0300 Message-ID: <87wndmzyhb.fsf@tcd.ie> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) unarchive 54802 quit From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 11 17:24:58 2022 Received: (at 54802) by debbugs.gnu.org; 11 Jun 2022 21:24:58 +0000 Received: from localhost ([127.0.0.1]:54150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o08bK-0001sF-KG for submit@debbugs.gnu.org; Sat, 11 Jun 2022 17:24:58 -0400 Received: from mail-ed1-f49.google.com ([209.85.208.49]:40458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o08bI-0001s2-Gq for 54802@debbugs.gnu.org; Sat, 11 Jun 2022 17:24:57 -0400 Received: by mail-ed1-f49.google.com with SMTP id w27so2856300edl.7 for <54802@debbugs.gnu.org>; Sat, 11 Jun 2022 14:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=rgLFGSI5qmJF6EG5ueF1erZX11+bf7TtYFb7DP5WOMM=; b=VugZQRIwq5972r8kAw6KTKOImeWdMHS7puhlw3F9tMMCUsHEbV1hemN927jZAijl2W e7ZwF8Lxvo6dUyaYfHNk488zvVpZhf+/z5KLklDrHaeyai2LkMcd1t1qO4qwwxXgUxEO XNczSwrLyQRpeoxAHif3EWpomzFbO+0ZCbeXhz2MzJgmn+CGHeP77YlxPMuM5W+zH5Xa x/Kti8Sfxz8e/HIqQOM/VhGKLjEyAeGcYq8h1lvB9kvl4/BGm4g2CvokJWj1d6v7HVSN 55Ijo6Xw2qadED5Uh++SXWFcaEHRpxuw9uQmD4aiOfySHsiojT+QNMacqeuo3rAarSwy UxYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=rgLFGSI5qmJF6EG5ueF1erZX11+bf7TtYFb7DP5WOMM=; b=7iqlYe08dBGjRjdtPFpb0lyYmixlh1R/wyxjmFeIoNG88wgTaApLMG6hvXplW2vCGV nKLoB0jlC7m0pXVcRWY/5DyS8Fsc8fr8rIRXEYHPDyl1VcqJGYEO8lje47W9DtjAHFH4 cts+PpR/Ff380QQz5sBLUSVdGAAdFH9wucesM63d72DYD0Sm4y4WNt/RY6iTpIcFCjFx +HM/TzWBtqY6YPIdiugNZE92MVv+5749g/bw1vKGqqgpO56vLmQREE5Sd9kKrVmv4MDM UFpLidNejsdyu+iAWx5vJNroFV84+pg/d4pzIeHEt+PMkYcp9Ytjs+8jxuajyguuaD9t 23lA== X-Gm-Message-State: AOAM533+9Kon8q4Gqn2rok+ghudKCsyxdca+v3n46jacFn8SGXI4bh+o +Nk4V31zYBcSV4Gb7ENpIxs9ZQ== X-Google-Smtp-Source: ABdhPJy0XH008kFYH2Ahunr2hqyYvQl04u9SGZcK8zYu/8cwxD9TUKHp7TPBxgqBTezJBv/y37FnHQ== X-Received: by 2002:aa7:d1ce:0:b0:42d:cf0e:3389 with SMTP id g14-20020aa7d1ce000000b0042dcf0e3389mr57879518edp.4.1654982690897; Sat, 11 Jun 2022 14:24:50 -0700 (PDT) Received: from localhost ([2a02:587:322b:6f5e:dc92:136a:a7c4:dc8c]) by smtp.gmail.com with ESMTPSA id d18-20020a1709067f1200b00711eea3fa9bsm1527011ejr.42.2022.06.11.14.24.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jun 2022 14:24:49 -0700 (PDT) From: "Basil L. Contovounesios" To: Stefan Monnier Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <837d7luj3d.fsf@gnu.org> <87h76e8qc0.fsf@tcd.ie> Date: Sun, 12 Jun 2022 00:24:48 +0300 In-Reply-To: <87h76e8qc0.fsf@tcd.ie> (Basil L. Contovounesios's message of "Wed, 27 Apr 2022 19:05:03 +0300") Message-ID: <87pmjezye7.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54802 Cc: Eli Zaretskii , 54802@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Basil L. Contovounesios [2022-04-27 19:05 +0300] wrote: > Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of te= xt editors" [2022-04-19 13:52 -0400] wrote: > >> @@ -2041,52 +2040,89 @@ DEFUN ("commandp", Fcommandp, Scommandp, 1, 2, 0, > > [...] > >> + /* By now, if it's not a function we already returned nil. */ >> + >> + /* Check an `interactive-form' property if present, analogous to the >> + function-documentation property. */ >> + fun =3D function; >> + while (SYMBOLP (fun)) >> + { >> + Lisp_Object tmp =3D Fget (fun, Qinteractive_form); >> + if (!NILP (tmp)) >> + error ("Found an 'interactive-form' property!"); >> + fun =3D Fsymbol_function (fun); >> + } > > error ("Success!"); > > Why is it now an error for functions to have an interactive-form > property? The Elisp manual is careful to describe this practice as > unusual, but nevertheless supported, e.g. in cases such as: > > 0. emacs -Q -f toggle-debug-on-error > 1. (progn > (defun my-foo (&rest _)) > (function-put 'my-foo 'interactive-form > (interactive-form 'ignore))) > 2. C-x C-e > 3. M-x C-i > > Debugger entered--Lisp error: (error "Found an =E2=80=99interactive-form= =E2=80=99 property!") > commandp(my-foo) > [...] In the meantime should I reopen this bug or report a new one, so this isn't forgotten about? Thanks, --=20 Basil From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 12 01:35:00 2022 Received: (at 54802) by debbugs.gnu.org; 12 Jun 2022 05:35:00 +0000 Received: from localhost ([127.0.0.1]:54403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0GFX-0007xT-VR for submit@debbugs.gnu.org; Sun, 12 Jun 2022 01:35:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0GFU-0007xF-SB for 54802@debbugs.gnu.org; Sun, 12 Jun 2022 01:34:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41002) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0GFN-0003nL-PO; Sun, 12 Jun 2022 01:34:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=tEQRmM8nJpyW/hxz1n69El4wH2a49OEkaDVCu1KKrRo=; b=b6fkYsViS4/It+bfAXug 022ILcmKdTd2/fy5bOneb5jXKGr55cVIM84ftxVT78cQoAYBBaszIFvsMaWDnAC7nkPwOmURDG2Rr wjhNzE6pn43/g9SLXNqN7ehXuKf3cTI/+LKrKFYwZe6PgMeHFFw7uCpiKnSWBHoXhRQoskHFza5j4 4L4arhRi2U+QdoL5QQDSA3aYWDLATZRdCA5mltRk6SJ37x2PYTNSv/7Mi04VUNDdbtONx3RcHufuR VDlmID4TP3wHMglv61c4U3DGq/65d4OMM31v7YypNQXrVnhmCpKy56JRXVVNmz8jMU8ms2d6Lp+xW fiDhEyEWPLJJNA==; Received: from [87.69.77.57] (port=4342 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0GFN-0008Oy-7m; Sun, 12 Jun 2022 01:34:49 -0400 Date: Sun, 12 Jun 2022 08:34:32 +0300 Message-Id: <83wndmwil3.fsf@gnu.org> From: Eli Zaretskii To: "Basil L. Contovounesios" In-Reply-To: <87pmjezye7.fsf@tcd.ie> (contovob@tcd.ie) Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <837d7luj3d.fsf@gnu.org> <87h76e8qc0.fsf@tcd.ie> <87pmjezye7.fsf@tcd.ie> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: "Basil L. Contovounesios" > Cc: Eli Zaretskii , 54802@debbugs.gnu.org > Date: Sun, 12 Jun 2022 00:24:48 +0300 > > > Why is it now an error for functions to have an interactive-form > > property? The Elisp manual is careful to describe this practice as > > unusual, but nevertheless supported, e.g. in cases such as: > > > > 0. emacs -Q -f toggle-debug-on-error > > 1. (progn > > (defun my-foo (&rest _)) > > (function-put 'my-foo 'interactive-form > > (interactive-form 'ignore))) > > 2. C-x C-e > > 3. M-x C-i > > > > Debugger entered--Lisp error: (error "Found an ’interactive-form’ property!") > > commandp(my-foo) > > [...] > > In the meantime should I reopen this bug or report a new one, so this > isn't forgotten about? Yes, please. A new bug is probably better. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 12 16:56:30 2022 Received: (at 54802) by debbugs.gnu.org; 12 Jun 2022 20:56:30 +0000 Received: from localhost ([127.0.0.1]:56579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0UdK-0005Qv-0W for submit@debbugs.gnu.org; Sun, 12 Jun 2022 16:56:30 -0400 Received: from mail-ej1-f43.google.com ([209.85.218.43]:44738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0UdG-0005Qf-Bg for 54802@debbugs.gnu.org; Sun, 12 Jun 2022 16:56:28 -0400 Received: by mail-ej1-f43.google.com with SMTP id kq6so7545701ejb.11 for <54802@debbugs.gnu.org>; Sun, 12 Jun 2022 13:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=s9WnLkrluHk5rApRgjXeyNkJNMBlcVkfxFUQRchcO7U=; b=RKEnRHitGIdon9eftS1k5ThhJWylDptGxJNr4vF7+amIdjBKI/y1D/05h3jg4Lugji dzTp6ZokoacnggLeEeWd7nlLipd3sTuzi8IoM+KDAP+gJs9rhvfeVSM9RRNattVRYJmR mjKpRZr7kka/P6d2Lem8TeXkuP+DElEngqqtZIqHvyqJpA68TT4ct6h3V6E0geo8ezjx 1ovG7guPINSVcy/RZTRl5DfWoZZyvaim+BsHGp4B5gmXX8SuOV/5tH7qZuCUfb41Mml0 8UELU7tzSEXt6OoixrFiI3h+rvpi7fvKmZa5cRf2BmMGMYieXQ9i4e8bPYtqqEEU9TZ/ OBtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=s9WnLkrluHk5rApRgjXeyNkJNMBlcVkfxFUQRchcO7U=; b=GemNHOSmFkLyRgbA58s4sfPSHUYT6bA4dH/c1wzxvm1fdUTGqMlhQC2YWY6eSm5XRY 2m8v0Ce0/aeTjwwQNdlpIs5R1ri0xAUy0PzhRC/Xr8ADank946V9PFObZMIjvlUiFnhC X8MjqOpTQqS9MXoZtkYcMTOOzKE6z9AMLDhmcAwbGeI49wgbDVH/s3yKlrD5cMa4bVLP QwnAiZ/v8LL7qC5eqWYK1/FbOqv2fXiKgFGVUyyAiOhPVb1fq9bPtff4J9GZ/FDi2jPp Haltawt8eqiM+vO6j3YzjUB/EDSWzF/63uBc94VZhjsBBCnMkYOKginJYcjaESrJNnTo csBA== X-Gm-Message-State: AOAM532Ytrfir9pfc7hPHxYettkUchv9TcZgGcQBjERrOYHRgHG0WkAJ /Afr+8XwdQodJsZQXEBaRJoiTg== X-Google-Smtp-Source: ABdhPJxSoUFKHnqgggMkw8d3bKvU6q2iytZ9gptDh3Esbfz+nVjXMk7ELPtVj5aQMll+JvV5nZBQqA== X-Received: by 2002:a17:906:d7bc:b0:70a:99ef:d0b8 with SMTP id pk28-20020a170906d7bc00b0070a99efd0b8mr50178896ejb.624.1655067380411; Sun, 12 Jun 2022 13:56:20 -0700 (PDT) Received: from localhost ([2a02:587:322b:6f5e:dc92:136a:a7c4:dc8c]) by smtp.gmail.com with ESMTPSA id dk16-20020a170906f0d000b0070f8590ee8fsm2873731ejb.159.2022.06.12.13.56.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Jun 2022 13:56:19 -0700 (PDT) From: "Basil L. Contovounesios" To: Eli Zaretskii Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function References: <837d7luj3d.fsf@gnu.org> <87h76e8qc0.fsf@tcd.ie> <87pmjezye7.fsf@tcd.ie> <83wndmwil3.fsf@gnu.org> Date: Sun, 12 Jun 2022 23:56:18 +0300 In-Reply-To: <83wndmwil3.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 12 Jun 2022 01:34:51 -0400") Message-ID: <8735g9k3d9.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54802 Cc: 54802@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii [2022-06-12 01:34 -0400] wrote: >> From: "Basil L. Contovounesios" >> Cc: Eli Zaretskii , 54802@debbugs.gnu.org >> Date: Sun, 12 Jun 2022 00:24:48 +0300 >> >> In the meantime should I reopen this bug or report a new one, so this >> isn't forgotten about? > > Yes, please. A new bug is probably better. Here it is, for posterity: https://bugs.gnu.org/55925 -- Basil From unknown Sun Jun 22 03:56:30 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 11 Jul 2022 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator