From unknown Fri Aug 15 15:26:58 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#6486 <6486@debbugs.gnu.org> To: bug#6486 <6486@debbugs.gnu.org> Subject: Status: documentation of `byte-code-function-p' should mention `symbol-function' and xref manual Reply-To: bug#6486 <6486@debbugs.gnu.org> Date: Fri, 15 Aug 2025 22:26:58 +0000 retitle 6486 documentation of `byte-code-function-p' should mention `symbo= l-function' and xref manual reassign 6486 emacs submitter 6486 MON KEY severity 6486 minor tag 6486 notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 21 13:36:35 2010 Received: (at submit) by debbugs.gnu.org; 21 Jun 2010 17:36:35 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OQkvC-0005zL-OM for submit@debbugs.gnu.org; Mon, 21 Jun 2010 13:36:35 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OQkvA-0005zE-M2 for submit@debbugs.gnu.org; Mon, 21 Jun 2010 13:36:32 -0400 Received: from lists.gnu.org ([199.232.76.165]:37235) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OQkv6-0005qJ-2t for submit@debbugs.gnu.org; Mon, 21 Jun 2010 13:36:28 -0400 Received: from [140.186.70.92] (port=59005 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OQkv4-0003Rg-JK for bug-gnu-emacs@gnu.org; Mon, 21 Jun 2010 13:36:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OQkv3-0001qV-7s for bug-gnu-emacs@gnu.org; Mon, 21 Jun 2010 13:36:26 -0400 Received: from mail-yx0-f169.google.com ([209.85.213.169]:34902) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OQkv3-0001qJ-5j for bug-gnu-emacs@gnu.org; Mon, 21 Jun 2010 13:36:25 -0400 Received: by yxd39 with SMTP id 39so196418yxd.0 for ; Mon, 21 Jun 2010 10:36:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.150.10 with SMTP id x10mr4665484ybd.176.1277141782922; Mon, 21 Jun 2010 10:36:22 -0700 (PDT) Received: by 10.151.10.5 with HTTP; Mon, 21 Jun 2010 10:36:22 -0700 (PDT) Date: Mon, 21 Jun 2010 13:36:22 -0400 X-Google-Sender-Auth: LVF1Z_SIPg75ESg2kldM9fjzwdg Message-ID: Subject: documentation of `byte-code-function-p' should mention `symbol-function' and xref manual From: MON KEY To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.0 (-----) The documentation of function `byte-code-function-p' should mention usage requires `symbol-function', and/or should refer to a relevant portion of the manual. ,---- (documentation 'byte-code-function-p) | | Return t if OBJECT is a byte-compiled function object. | | (fn OBJECT) | `---- The above docs do not adequately indicate that the OBJECT arg is as per the return value of `symbol-function'. e.g.: (byte-code-function-p 'disassemble) ;=> nil (byte-code-function-p (symbol-function 'disassemble)) ;=> t How is the user supposed to know that OBJECT will only return t if it is the unreadable vector returned by `symbol-function'? Please add documentation of such, along with info node xref such as: See info node `(elisp) Byte-Code Objects' Also, note that the nature of the data-structure/readability of a byte-code'd function can not be deduced by the user by simply reading the manual section: (info "(elisp)What Is a Function") -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 22 00:53:29 2010 Received: (at submit) by debbugs.gnu.org; 22 Jun 2010 04:53:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OQvUG-0003an-Oa for submit@debbugs.gnu.org; Tue, 22 Jun 2010 00:53:29 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OQvUC-0003ab-PO for submit@debbugs.gnu.org; Tue, 22 Jun 2010 00:53:25 -0400 Received: from lists.gnu.org ([199.232.76.165]:47656) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OQvU9-00071W-Ha for submit@debbugs.gnu.org; Tue, 22 Jun 2010 00:53:21 -0400 Received: from [140.186.70.92] (port=56240 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OQvU8-00010X-8v for bug-gnu-emacs@gnu.org; Tue, 22 Jun 2010 00:53:21 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_RP_MATCHES_RCVD, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OQvU7-0005qI-3x for bug-gnu-emacs@gnu.org; Tue, 22 Jun 2010 00:53:19 -0400 Received: from lo.gmane.org ([80.91.229.12]:40528) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OQvU6-0005q2-MS for bug-gnu-emacs@gnu.org; Tue, 22 Jun 2010 00:53:19 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OQvU0-0001RM-0t for bug-gnu-emacs@gnu.org; Tue, 22 Jun 2010 06:53:12 +0200 Received: from c-71-237-24-138.hsd1.co.comcast.net ([71.237.24.138]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2010 06:53:12 +0200 Received: from kevin.d.rodgers by c-71-237-24-138.hsd1.co.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2010 06:53:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Kevin Rodgers Subject: Re: bug#6486: documentation of `byte-code-function-p' should mention `symbol-function' and xref manual Date: Mon, 21 Jun 2010 22:53:08 -0600 Lines: 76 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-71-237-24-138.hsd1.co.comcast.net User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -4.9 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.8 (-----) MON KEY wrote: > The documentation of function `byte-code-function-p' should mention > usage requires `symbol-function', and/or should refer to a relevant > portion of the manual. > > ,---- (documentation 'byte-code-function-p) > | > | Return t if OBJECT is a byte-compiled function object. > | > | (fn OBJECT) > | > `---- > > The above docs do not adequately indicate that the OBJECT arg is as > per the return value of `symbol-function'. e.g.: > > (byte-code-function-p 'disassemble) > ;=> nil > > (byte-code-function-p (symbol-function 'disassemble)) > ;=> t > > How is the user supposed to know that OBJECT will only return t if it > is the unreadable vector returned by `symbol-function'? From (elisp)What Is a Function: Unlike `functionp', the next three functions do _not_ treat a symbol as its function definition. -- Function: subrp object ... -- Function: byte-code-function-p object This function returns `t' if OBJECT is a byte-code function. For example: (byte-code-function-p (symbol-function 'next-line)) => t -- Function: subr-arity subr ... > Please add documentation of such, along with info node xref such as: > > See info node `(elisp) Byte-Code Objects' Nah, that is why we have M-x elisp-index-search -- although it might be nice if such links were automatically generated by the describe-* commands. > Also, note that the nature of the data-structure/readability of a > byte-code'd function can not be deduced by the user by simply reading > the manual section: > > (info "(elisp)What Is a Function") The nature of several types can't be deduced by the node that describes the corresponding predicate, but by the node that actually describes the type (under the Programming Types or Editing Types node). (elisp)What Is a Function does say: "byte-code function" A "byte-code function" is a function that has been compiled by the byte compiler. *Note Byte-Code Type::. And (elisp)Byte-Code Type (referenced above) says: The printed representation and read syntax for a byte-code function object is like that for a vector, with an additional `#' before the opening `['. -- Kevin Rodgers Denver, Colorado, USA From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 22 17:56:23 2010 Received: (at 6486) by debbugs.gnu.org; 22 Jun 2010 21:56:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORBSA-000399-D3 for submit@debbugs.gnu.org; Tue, 22 Jun 2010 17:56:23 -0400 Received: from mail-gx0-f172.google.com ([209.85.161.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORBS8-000394-K1 for 6486@debbugs.gnu.org; Tue, 22 Jun 2010 17:56:21 -0400 Received: by gxk8 with SMTP id 8so467151gxk.3 for <6486@debbugs.gnu.org>; Tue, 22 Jun 2010 14:56:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.160.18 with SMTP id i18mr6828137ybe.100.1277243776444; Tue, 22 Jun 2010 14:56:16 -0700 (PDT) Received: by 10.150.181.11 with HTTP; Tue, 22 Jun 2010 14:56:16 -0700 (PDT) Date: Tue, 22 Jun 2010 17:56:16 -0400 X-Google-Sender-Auth: oaa5nL4zPJyCoJ0IoYuWBlgzUIE Message-ID: Subject: bug#6486: documentation of `byte-code-function-p' should mention `symbol-function' and xref manual From: MON KEY To: 6486@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: 6486 Cc: kevin.d.rodgers@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) Kevin Rodgers wrote: >> How is the user supposed to know that OBJECT will only return t if >> it is the unreadable vector returned by `symbol-function'? > From (elisp)What Is a Function: > Unlike `functionp', the next three functions do _not_ treat a > symbol as its function definition. This doesn't address the "unreadable vector" return value though. It says (briefly) that we may have such a thing returned but not under which circumstances nor does it say what to do with such a thing once we have hold of it. e.g. that (require 'disass) ;; assuming it isn't loaded yet (vconcat (symbol-function 'disassemble-internal)) will return something readable. >> Please add documentation of such, along with info node xref such >> as: See info node `(elisp) Byte-Code Objects' > Nah, that is why we have M-x elisp-index-search -- So why then do certain function docs do have info node xrefs. If including info xrefs in docstrings extends clarity where there was none before what is the disadvantage to adding one here for `byte-code-function-p' as well? Why is Juri Linkov working on extending info like capablities to `help-mode' and vice versa? Because having relevant documentation at hand is useful. Especially so since, "Emacs is the extensible, customizable, --> self-documenting real-time display editor." Besides, last I checked Info was a separate (though incestuously coupled) facility from Emacs. e.g. from command-line: $> info emacs The point being that where info might provide additional relevant information w/re `byte-code-function-p' it does so only tangentially. IOW `byte-code-function-p' is to Emacs-Lisp as the `lsearch' function is to libc. That each is documented by the Info facility does not mean that Emacs Lisp doesnn't maintain an internal documentation consistent with its usage. > although it might be nice if such links were automatically generated > by the describe-* commands. Yes well, hooking this into describe-* commands will most-likely require the implementor(s) to understand usage of the `byte-code-function-p' predicate :P This goes doubly so for those wishing to extend such a feature to third party packages... >> Also, note that the nature of the data-structure/readability of a >> byte-code'd function can not be deduced by the user by simply >> reading the manual section: >> (info "(elisp)What Is a Function") > The nature of several types can't be deduced by the node that > describes the corresponding predicate, but by the node that actually > describes the type (under the Programming Types or Editing Types > node). The problem in this particular circumstance is that the objects returnd by `symbol-function' and `indirect-function' are: a) variadic according to whether the function is subr'd, byte-code'd, interpreted, indirect'd, macro'd, autoload'd (byte-code-function-p (symbol-function 'concat)) ;=> nil (symbol-function 'concat) ;=> # (subrp (symbol-function 'concat)) ;=>t (symbol-function 'with-current-buffer) ;=> (macro . #[ ... ]) (symbol-function 'lisp-mode) ;=> #[ ... ] (symbol-function 'common-lisp-mode) ;=> lisp-mode (indirect-function 'common-lisp-mode) ;=> #[ ... ] (eq (indirect-function 'common-lisp-mode) (symbol-function 'lisp-mode)) ;=> t (symbol-function 'dunnet) ;=> (autoload "dunnet" 940287 t nil) (byte-code-function-p (symbol-function 'dunnet)) ;=> nil (require 'dunnet) ;=> brought autoload'd symbol `dunnet' into environment. (symbol-function 'dunnet) ;=> #[ ... ] (byte-code-function-p (symbol-function 'dunnet)) ;=> t (defun my-bubba (x) "bubba returns t when X is eq X." (eq x x)) (symbol-function 'my-bubba) ;=> (lambda (x) "bubba returns t when X is eq X." (eq x x)) (defalias 'bubba-in-disguise 'my-bubba) (symbol-function 'bubba-in-disguise) ;=> my-bubba (indirect-function 'bubba-in-disguise) ;=> (lambda (x) "bubba returns t when X is eq X." (eq x x)) (byte-compile 'my-bubba) ;=> #[(x) "\x8\211=\207" [x] 2 "bubba returns t when X is eq X."] (symbol-function 'my-bubba) ;=> #[(x) "\x8\211=\207" [x] 2 "bubba returns t when X is eq X."] (symbol-function 'bubba-in-disguise) ;=> my-bubba (indirect-function 'bubba-in-disguise) ;=> #[(x) "\x8\211=\207" [x] 2 "bubba returns t when X is eq X."] b) apropos a two of the "types" of return values above aren't readable c) apropos b one of the "types" can't even be coerced into readability. e.g. this is coercable: (vconcat (cdr (symbol-function 'with-current-buffer))) :NOTE FOLLOWING FORM MAY HANG EVAL IN A DISPOSABLE Emacs! this is not: (read (symbol-function 'concat)) c) apropos b and c, and because we don't have features like `print-unreadable-object' or `readably-printable' to help us w/ frobbing "type" it is important that the user be afforded some additional clarity within the docs independently of the manual w/re how to accomplish such things. > (elisp)What Is a Function does say: > "byte-code function" > A "byte-code function" is a function that has been compiled by the > byte compiler. *Note Byte-Code Type::. Unless it is a subr or an autoload or a macro... See above. > And (elisp)Byte-Code Type (referenced above) says: > > The printed representation and read syntax for a byte-code function > object is like that for a vector, with an additional `#' before the > opening `['. So, currently an un-informed user now has to xref 3x info nodes: (info "(elisp)Byte-Code Type") (info "(elisp)Byte-Code Objects") (info "(elisp)What Is a Function") To reach the conclusion that the OBJECT arg to byte-code-function-p is (with qualifications) per the return value of `symbol-function', `indirect-function'. This is why I feel justified in asserting that the docstring of `byte-code-function-p', "does not adequately indicate that the OBJECT arg is as per the return value of `symbol-function'." And requested that, "documentation of such, along with info node xref such as: See info node `(elisp) Byte-Code Objects'" be provided. Neither of which strike me as all that unreasonable. > Kevin Rodgers -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 13 18:29:35 2011 Received: (at 6486) by debbugs.gnu.org; 13 Jul 2011 22:29:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qh7vz-0004DV-3p for submit@debbugs.gnu.org; Wed, 13 Jul 2011 18:29:35 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qh7vw-0004D5-V4 for 6486@debbugs.gnu.org; Wed, 13 Jul 2011 18:29:33 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=quimbies.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Qh7vl-0006Ms-8N; Thu, 14 Jul 2011 00:29:21 +0200 From: Lars Magne Ingebrigtsen To: Kevin Rodgers Subject: Re: bug#6486: documentation of `byte-code-function-p' should mention `symbol-function' and xref manual In-Reply-To: (Kevin Rodgers's message of "Mon, 21 Jun 2010 22:53:08 -0600") Date: Thu, 14 Jul 2011 00:29:01 +0200 Message-ID: References: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-Now-Playing: David Byrne and Brian Eno's _My Life In The Bush Of Ghosts_: "Qu'ran" X-Hashcash: 1:23:110713:6486@debbugs.gnu.org::0nAd+lnpjeKxulaq:0000000000000000000000000000000000000000033mX X-Hashcash: 1:23:110713:kevin.d.rodgers@gmail.com::GfXFNO/tTh3THuYQ:000000000000000000000000000000000000640U MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1Qh7vl-0006Ms-8N X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1311200961.75147@yEcY+DT/+fSCCqU9Euk1Sw X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 6486 Cc: 6486@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Kevin Rodgers writes: >> Please add documentation of such, along with info node xref such as: >> >> See info node `(elisp) Byte-Code Objects' > > Nah, that is why we have M-x elisp-index-search -- although it might > be nice if such links were automatically generated by the describe-* > commands. True. But I don't think there's a bug in this report, so I'm closing it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 13 18:29:29 2011 Received: (at control) by debbugs.gnu.org; 13 Jul 2011 22:29:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qh7vs-0004DB-Pg for submit@debbugs.gnu.org; Wed, 13 Jul 2011 18:29:28 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qh7vr-0004Cv-HD for control@debbugs.gnu.org; Wed, 13 Jul 2011 18:29:27 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=quimbies.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Qh7vg-0006Mg-RS for control@debbugs.gnu.org; Thu, 14 Jul 2011 00:29:16 +0200 Date: Thu, 14 Jul 2011 00:29:16 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #6486 X-MailScanner-ID: 1Qh7vg-0006Mg-RS X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1311200956.92275@+ikikpWLxJke7bCNiVG5tw X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) tags 6486 notabug close 6486 From unknown Fri Aug 15 15:26:58 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, 11 Aug 2011 11:24:07 +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