From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Ulrich =?UTF-8?Q?M=C3=BCller?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Oct 2024 14:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 73886@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.172934870013644 (code B ref -1); Sat, 19 Oct 2024 14:39:01 +0000 Received: (at submit) by debbugs.gnu.org; 19 Oct 2024 14:38:20 +0000 Received: from localhost ([127.0.0.1]:44256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2Aay-0003Y0-8K for submit@debbugs.gnu.org; Sat, 19 Oct 2024 10:38:20 -0400 Received: from lists.gnu.org ([209.51.188.17]:52896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2Aav-0003Xs-Om for submit@debbugs.gnu.org; Sat, 19 Oct 2024 10:38:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2AaX-0000Sm-LF for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2024 10:37:53 -0400 Received: from woodpecker.gentoo.org ([140.211.166.183] helo=smtp.gentoo.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1t2AaW-0006WU-13 for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2024 10:37:53 -0400 From: Ulrich =?UTF-8?Q?M=C3=BCller?= Date: Sat, 19 Oct 2024 16:37:33 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=140.211.166.183; envelope-from=ulm@gentoo.org; helo=smtp.gentoo.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) 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.6 (--) Section 13.9 "Accessing Function Cell Contents" of the GNU Emacs Lisp Reference Manual emphasizes the distinction between void and nil in function cells: | Note that void is not the same as =E2=80=98nil=E2=80=99 or the symbol = =E2=80=98void=E2=80=99. | The symbols =E2=80=98nil=E2=80=99 and =E2=80=98void=E2=80=99 are Lisp obj= ects, and can be stored into | a function cell just as any other object can be (and =E2=80=98void=E2=80= =99 can be a | valid function if you define it with =E2=80=98defun=E2=80=99). A void fu= nction cell | contains no object whatsoever. | You can test the voidness of a symbol's function definition with | =E2=80=98fboundp=E2=80=99. After you have given a symbol a function defi= nition, you | can make it void once more using =E2=80=98fmakunbound=E2=80=99. Also, for "fboundp": | This function returns =E2=80=98t=E2=80=99 if the symbol has an objec= t in its | function cell, =E2=80=98nil=E2=80=99 otherwise. It does not check t= hat the | object is a legitimate function. It seems that the actual behavior does not reflect this, i.e. there is no distinction between nil and void: (fmakunbound 'foo) (fboundp 'foo) =E2=87=92 nil (fset 'foo nil) ;; according to the manual, the following should return t ;; because nil is a Lisp object: (fboundp 'foo) =E2=87=92 nil Is the manual wrong, or am I missing something? From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Oct 2024 17:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ulrich =?UTF-8?Q?M=C3=BCller?= , Stefan Monnier Cc: 73886@debbugs.gnu.org Received: via spool by 73886-submit@debbugs.gnu.org id=B73886.172935999613955 (code B ref 73886); Sat, 19 Oct 2024 17:47:02 +0000 Received: (at 73886) by debbugs.gnu.org; 19 Oct 2024 17:46:36 +0000 Received: from localhost ([127.0.0.1]:44697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2DX9-0003d1-LY for submit@debbugs.gnu.org; Sat, 19 Oct 2024 13:46:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2DX7-0003cm-Tr for 73886@debbugs.gnu.org; Sat, 19 Oct 2024 13:46:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2DWY-0003dG-0p; Sat, 19 Oct 2024 13:46:00 -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=TyUakcgIYvW8JnEevWyG8pMTosSwoWPL7DD8d3a7fVM=; b=hPq9KhGX0Hf7SIRLTkuB MzFHGMGHNhnH6BCImG1olVmEurWQmh/8O64mVUKHlqvdB9Zos6iOBqGjSxp4PXzLcf1yiN49snMf+ BgSXm/OGJw7/H8ZsPQDu459Vuy1V7xSvc0WUD/STg97TKTM8NIQu1LFuiy9ccb3vn/AC2fznEGzH5 yAY2w7c/Eb6AuiuGNv8iMz49uBgGBWsL/3sqe1ynf/NGi/K8LWeqRykonv/Du4tT/5MCBd2MC0/Hh AuDVJlgaSx6LCZJxg/jokKPUpMuROI0/0SyNPmtMNYdL/3HEsvUeulWKKTW3Jozti9scbUib7I8FY g5abUUbI287lOg==; Date: Sat, 19 Oct 2024 20:45:55 +0300 Message-Id: <86ldykj8a4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Ulrich =?UTF-8?Q?M=C3=BCller?= on Sat, 19 Oct 2024 16:37:33 +0200) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) 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: Ulrich Müller > Date: Sat, 19 Oct 2024 16:37:33 +0200 > > Section 13.9 "Accessing Function Cell Contents" of the GNU Emacs Lisp > Reference Manual emphasizes the distinction between void and nil > in function cells: > > | Note that void is not the same as ‘nil’ or the symbol ‘void’. > | The symbols ‘nil’ and ‘void’ are Lisp objects, and can be stored into > | a function cell just as any other object can be (and ‘void’ can be a > | valid function if you define it with ‘defun’). A void function cell > | contains no object whatsoever. > > | You can test the voidness of a symbol's function definition with > | ‘fboundp’. After you have given a symbol a function definition, you > | can make it void once more using ‘fmakunbound’. > > Also, for "fboundp": > > | This function returns ‘t’ if the symbol has an object in its > | function cell, ‘nil’ otherwise. It does not check that the > | object is a legitimate function. > > It seems that the actual behavior does not reflect this, i.e. there > is no distinction between nil and void: > > (fmakunbound 'foo) > (fboundp 'foo) ⇒ nil > > (fset 'foo nil) > ;; according to the manual, the following should return t > ;; because nil is a Lisp object: > (fboundp 'foo) ⇒ nil > > Is the manual wrong, or am I missing something? I think the manual is wrong. I think it tries to explain wrt void functions the same it says about void variables, but we handle void variables differently from void functions: void variables have a distinct value in their value cell, whereas void functions have nil in their function cell. Stefan, am I right? From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Andreas Schwab Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Oct 2024 19:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ulrich =?UTF-8?Q?M=C3=BCller?= Cc: 73886@debbugs.gnu.org Received: via spool by 73886-submit@debbugs.gnu.org id=B73886.172936491328081 (code B ref 73886); Sat, 19 Oct 2024 19:09:02 +0000 Received: (at 73886) by debbugs.gnu.org; 19 Oct 2024 19:08:33 +0000 Received: from localhost ([127.0.0.1]:44813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2EoS-0007Ir-PG for submit@debbugs.gnu.org; Sat, 19 Oct 2024 15:08:33 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:50150) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2EoQ-0007Ii-8a for 73886@debbugs.gnu.org; Sat, 19 Oct 2024 15:08:31 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4XWB104rzpz1qsNv; Sat, 19 Oct 2024 21:08:03 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 4XWB0z6BK9z1qqlS; Sat, 19 Oct 2024 21:08:03 +0200 (CEST) X-Virus-Scanned: amavis at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024) with ESMTP id 8w1UUKyh42_C; Sat, 19 Oct 2024 21:08:03 +0200 (CEST) X-Auth-Info: 87fl60VrEoo4GzoO7pByYx9uvaXhJAzWMKkpmxDqRHKRq1MqTJiEg9wcv9xV6wMf Received: from igel.home (aftr-82-135-83-57.dynamic.mnet-online.de [82.135.83.57]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Sat, 19 Oct 2024 21:08:03 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id F18542C1A54; Sat, 19 Oct 2024 21:08:02 +0200 (CEST) From: Andreas Schwab In-Reply-To: ("Ulrich =?UTF-8?Q?M=C3=BCller?="'s message of "Sat, 19 Oct 2024 16:37:33 +0200") References: X-Yow: Gee, I feel kind of LIGHT in the head now, knowing I can't make my satellite dish PAYMENTS! Date: Sat, 19 Oct 2024 21:08:02 +0200 Message-ID: <87frorykq5.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.4 (/) 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.4 (-) On Okt 19 2024, Ulrich Müller wrote: > Is the manual wrong, or am I missing something? That changed in commit eadf1faa3cb, but the manual wasn't updated. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Ulrich =?UTF-8?Q?M=C3=BCller?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Oct 2024 21:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andreas Schwab Cc: 73886@debbugs.gnu.org Received: via spool by 73886-submit@debbugs.gnu.org id=B73886.172937212416289 (code B ref 73886); Sat, 19 Oct 2024 21:09:01 +0000 Received: (at 73886) by debbugs.gnu.org; 19 Oct 2024 21:08:44 +0000 Received: from localhost ([127.0.0.1]:44932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2Ggm-0004Ef-AT for submit@debbugs.gnu.org; Sat, 19 Oct 2024 17:08:44 -0400 Received: from woodpecker.gentoo.org ([140.211.166.183]:50420 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2Ggk-0004EP-Lv for 73886@debbugs.gnu.org; Sat, 19 Oct 2024 17:08:43 -0400 From: Ulrich =?UTF-8?Q?M=C3=BCller?= In-Reply-To: <87frorykq5.fsf@igel.home> (Andreas Schwab's message of "Sat, 19 Oct 2024 21:08:02 +0200") References: <87frorykq5.fsf@igel.home> Date: Sat, 19 Oct 2024 23:07:37 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) 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 (---) >>>>> On Sat, 19 Oct 2024, Andreas Schwab wrote: > On Okt 19 2024, Ulrich M=C3=BCller wrote: >> Is the manual wrong, or am I missing something? > That changed in commit eadf1faa3cb, but the manual wasn't updated. Then the respective docstrings are also outdated, i.e. the term "void" shouldn't occur in any of these: (fboundp SYMBOL) Return t if SYMBOL=E2=80=99s function definition is not void. (fmakunbound SYMBOL) Make SYMBOL=E2=80=99s function definition be void. Return SYMBOL. (symbol-function SYMBOL) Return SYMBOL=E2=80=99s function definition, or nil if that is void. From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Oct 2024 02:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Ulrich =?UTF-8?Q?M=C3=BCller?= , 73886@debbugs.gnu.org Received: via spool by 73886-submit@debbugs.gnu.org id=B73886.17293904125423 (code B ref 73886); Sun, 20 Oct 2024 02:14:02 +0000 Received: (at 73886) by debbugs.gnu.org; 20 Oct 2024 02:13:32 +0000 Received: from localhost ([127.0.0.1]:45253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2LRj-0001PO-Vm for submit@debbugs.gnu.org; Sat, 19 Oct 2024 22:13:32 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57319) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2LRh-0001P9-Ts for 73886@debbugs.gnu.org; Sat, 19 Oct 2024 22:13:30 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 618B4441858; Sat, 19 Oct 2024 22:12:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1729390377; bh=4lWjcnZ0870zWTn4rIEKGpRBXoTw03jLhrRiGgMSqf0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=IFe+5C6Sfz5fuXK2dQ3sjerai4fM98iG3wOg8xp7yG5DkVZlNUsyDB+77uzChiqsq NzoKTG6QX4wYyERNvDU1Dvm8wn3gKEA08r6hGYjbOYiDdne/7ffg3Hopl8feJIOKZQ bVl05cCphcI01P0qGVbUSsYCumWnBn6jh//cG9kHd/fxroQkfZVWr/9YkyViCTYKuR QT+n6R8NNlqaMkbEsuE35e+T0hhTZEKnh5PSQHwGP0KpqGjUNq1lxrFkpO89UF6ogy wbjDHCMxdxWl3TjGMZKRnB+GSl1sAPApUdr1hOWOoYiy2bSxWy5I8MrfhAqxfo/GoL OuuEch9SraCdg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 674844402CF; Sat, 19 Oct 2024 22:12:57 -0400 (EDT) Received: from pastel (69-196-161-60.dsl.teksavvy.com [69.196.161.60]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3934B120490; Sat, 19 Oct 2024 22:12:57 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86ldykj8a4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 19 Oct 2024 20:45:55 +0300") Message-ID: References: <86ldykj8a4.fsf@gnu.org> Date: Sat, 19 Oct 2024 22:12:48 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) 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 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> Section 13.9 "Accessing Function Cell Contents" of the GNU Emacs Lisp >> Reference Manual emphasizes the distinction between void and nil >> in function cells: >>=20 >> | Note that void is not the same as =E2=80=98nil=E2=80=99 or the symb= ol =E2=80=98void=E2=80=99. >> | The symbols =E2=80=98nil=E2=80=99 and =E2=80=98void=E2=80=99 are Lisp = objects, and can be stored into >> | a function cell just as any other object can be (and =E2=80=98void=E2= =80=99 can be a >> | valid function if you define it with =E2=80=98defun=E2=80=99). A void= function cell >> | contains no object whatsoever. Oops. Looks like I missed this part when I changed it back around Emacs-24.4: ** In 'symbol-function', nil and "unbound" are indistinguishable. 'symbol-function' does not signal a 'void-function' error any more. To determine if a symbol's function definition is void, use 'fboundp'. > I think the manual is wrong. Indeed. It was right for Emacs<24.4, tho. Stefan From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Oct 2024 05:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: ulm@gentoo.org, 73886@debbugs.gnu.org Received: via spool by 73886-submit@debbugs.gnu.org id=B73886.17294015526635 (code B ref 73886); Sun, 20 Oct 2024 05:20:02 +0000 Received: (at 73886) by debbugs.gnu.org; 20 Oct 2024 05:19:12 +0000 Received: from localhost ([127.0.0.1]:45453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2OLQ-0001ix-0q for submit@debbugs.gnu.org; Sun, 20 Oct 2024 01:19:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2OLL-0001id-TZ for 73886@debbugs.gnu.org; Sun, 20 Oct 2024 01:19:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2OKr-0007T6-57; Sun, 20 Oct 2024 01:18:37 -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=ZpNOYi/4CMyhOKE18ImMl3NAIExOqjY/qXTxFFMThP8=; b=DcXZwRYMbG+K+4upiEgI hp43wLnxhuFQYfRI1SwBTrK4w0Day+lCaSocXsr4uYhkjOi3H7bQhevzdzAK5y9yMC6FTgzLoCWqB NrWl8+13VJ5xDyKNmUz+jvypuuIqPxPiSnxc4sy0i3ALAGhFZ2/JQ9gPP6nMwT2SJI8Vls6hDwXhg 2HF3RkG6awzd+RFvAp69RXNy5MZj5keu2sSUN9CaLmHjalVZjUQKn6mKslGRPbO82Ej67DQcURDQE MxOTgT+bq+pNCFte/qXZyHcaDN3wFEa9xJiKWx3QFxjenEGC0c3T455ouO0ddF+EsbC9WhM0Sb8CU zgrPAmdU5+RtLg==; Date: Sun, 20 Oct 2024 08:18:34 +0300 Message-Id: <86frorjqs5.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sat, 19 Oct 2024 22:12:48 -0400) References: <86ldykj8a4.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) 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: Ulrich Müller , > 73886@debbugs.gnu.org > Date: Sat, 19 Oct 2024 22:12:48 -0400 > > >> Section 13.9 "Accessing Function Cell Contents" of the GNU Emacs Lisp > >> Reference Manual emphasizes the distinction between void and nil > >> in function cells: > >> > >> | Note that void is not the same as ‘nil’ or the symbol ‘void’. > >> | The symbols ‘nil’ and ‘void’ are Lisp objects, and can be stored into > >> | a function cell just as any other object can be (and ‘void’ can be a > >> | valid function if you define it with ‘defun’). A void function cell > >> | contains no object whatsoever. > > Oops. Looks like I missed this part when I changed it back around > Emacs-24.4: > > ** In 'symbol-function', nil and "unbound" are indistinguishable. > 'symbol-function' does not signal a 'void-function' error any more. > To determine if a symbol's function definition is void, use 'fboundp'. Could you explain the rationale for that change? I tried to look for relevant discussions around that date, but came up empty-handed. From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Oct 2024 16:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: ulm@gentoo.org, 73886@debbugs.gnu.org Received: via spool by 73886-submit@debbugs.gnu.org id=B73886.17294434006629 (code B ref 73886); Sun, 20 Oct 2024 16:57:01 +0000 Received: (at 73886) by debbugs.gnu.org; 20 Oct 2024 16:56:40 +0000 Received: from localhost ([127.0.0.1]:48313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2ZEO-0001iq-A2 for submit@debbugs.gnu.org; Sun, 20 Oct 2024 12:56:40 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43237) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2ZEL-0001iY-BT for 73886@debbugs.gnu.org; Sun, 20 Oct 2024 12:56:37 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1BB488093F; Sun, 20 Oct 2024 12:56:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1729443365; bh=a5R6SKuv7dhGJUDvsgtV6bwSK0EYeeArT0D+ImSIoLA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QD/tSh/FPOXDIpN107Ht+Xch4DelgNhmVNjRpR37rMzn0EPUBlotxrULUSPpB7KHY wSaOgPEvJaJGxUdJ33Q8jiuXhBY2Nje8IjM4ILypGy+Ft3ifkSj5jb6AnKjn2sCi5E yoMn8dSaYQlAOKpc7WQQpJLiP5FKHXW+7ep8Pil7ACe5JSTI3Oams/nRQom7uMF0ys ibM0D29TcsKVK0CnYNAwVBS4paougfs8JNLg0Itna40hKmCEquEfhAbiruCqnZMVIq 1E3CI5UMAXWCxhX6DInFWjGXuo+ELImKSAH9y8Uns0YzEL5QEil6BY5vgQbK11iz/e cl+0J/j01TYJw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2901B803A3; Sun, 20 Oct 2024 12:56:05 -0400 (EDT) Received: from pastel (69-196-161-60.dsl.teksavvy.com [69.196.161.60]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EF4E31200E4; Sun, 20 Oct 2024 12:56:04 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86frorjqs5.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 20 Oct 2024 08:18:34 +0300") Message-ID: References: <86ldykj8a4.fsf@gnu.org> <86frorjqs5.fsf@gnu.org> Date: Sun, 20 Oct 2024 12:56:03 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) 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 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> Oops. Looks like I missed this part when I changed it back around >> Emacs-24.4: >> >> ** In 'symbol-function', nil and "unbound" are indistinguishable. >> 'symbol-function' does not signal a 'void-function' error any more. >> To determine if a symbol's function definition is void, use 'fboundp'. > > Could you explain the rationale for that change? I tried to look for > relevant discussions around that date, but came up empty-handed. I can't remember discussing it, no. It was a kind of "executive decision". Having a special "void" (`Qundefined`) non-value for the `symbol-value` is needed for `boundp` since variables can contain *any* value, but not for the `symbol-function` part where we can use any normal value (I chose `nil`) to play this role as long as it doesn't collide with values normally held in the `symbol-function` slot, like function names, function values, cons cells, vectors, ... The upside was a simplification in various chunks of code which used to do things like `(and (fboundp SYM) (symbol-function SYM))` which can now be simplified to `(symbol-function SYM)`. I remember two "motivators", i.e. places where the need to pay attention to the special void case annoyed me enough to look into this and make the change, one was `nadvice.el` and the other was `cl-letf`. [ So, it was no accident that the change happened in the same release as the addition of `nadvice.el`. ] In both cases the issue is that we want to deal with "places" (generalized variables) and that abstraction works well for those places which *always* contain a value, but not as well for those special places that can be "unbound", so removing the "unbound" case from `symbol-function` resulted in a welcome simplification. For the same reason I dislike EIEIO's notion of `slot-boundp` and have already considered marking it obsolete. Stefan From unknown Sat Aug 16 15:53:04 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Ulrich =?UTF-8?Q?M=C3=BCller?= Subject: bug#73886: closed (Re: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual) Message-ID: References: <864j4xaj6l.fsf@gnu.org> X-Gnu-PR-Message: they-closed 73886 X-Gnu-PR-Package: emacs Reply-To: 73886@debbugs.gnu.org Date: Sun, 27 Oct 2024 11:19:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1730027942-914-1" This is a multi-part message in MIME format... ------------=_1730027942-914-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #73886: 29.4; Confusing info about void function cells in Emacs Lisp manual which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 73886@debbugs.gnu.org. --=20 73886: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D73886 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1730027942-914-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 73886-done) by debbugs.gnu.org; 27 Oct 2024 11:18:41 +0000 Received: from localhost ([127.0.0.1]:44063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t51I8-0000Dz-QE for submit@debbugs.gnu.org; Sun, 27 Oct 2024 07:18:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t51I6-0000Di-9h for 73886-done@debbugs.gnu.org; Sun, 27 Oct 2024 07:18:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t51HR-0002gD-AE; Sun, 27 Oct 2024 07:17:57 -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=bSh7LhFFJMuN1RatejvrmbsD6MqajhfEMBRHQ+Emnsk=; b=CEhxLjWcZY+E ENhlzX5snDrLO01h3jZRoDJoksgFn4EcK+7hCes/J5pynd1u1+G4RYp+zGnumzUEkrv2AkyZTj8N2 ryswn9NLYMBcvVUwVV39ijJd6VaE20bPgUp7c+byJbaOVA1iEM6kdIyEah740RXcgPSZaTP5/UuA2 sD2w7WVPWb/wKFPr6T2yG1eaur2RLtlyRnfcSfRzACWSahezfvOsybIY6ymEhq5bu2lju+Ml3KdPm RFheYuBmLpBpzHKMUXwETz+rECy1k6asMHVolpbZ0lF/8FyEERaPNIWoOfbt3wSEpGtNauQd4cfsH no7gEzTqbG6wwK4yWWEdYQ==; Date: Sun, 27 Oct 2024 13:17:54 +0200 Message-Id: <864j4xaj6l.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sun, 20 Oct 2024 12:56:03 -0400) Subject: Re: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual References: <86ldykj8a4.fsf@gnu.org> <86frorjqs5.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73886-done Cc: ulm@gentoo.org, 73886-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 (---) > From: Stefan Monnier > Cc: ulm@gentoo.org, 73886@debbugs.gnu.org > Date: Sun, 20 Oct 2024 12:56:03 -0400 > > >> Oops. Looks like I missed this part when I changed it back around > >> Emacs-24.4: > >> > >> ** In 'symbol-function', nil and "unbound" are indistinguishable. > >> 'symbol-function' does not signal a 'void-function' error any more. > >> To determine if a symbol's function definition is void, use 'fboundp'. > > > > Could you explain the rationale for that change? I tried to look for > > relevant discussions around that date, but came up empty-handed. > > I can't remember discussing it, no. It was a kind of "executive > decision". > > Having a special "void" (`Qundefined`) non-value for the `symbol-value` > is needed for `boundp` since variables can contain *any* value, but not > for the `symbol-function` part where we can use any normal value (I > chose `nil`) to play this role as long as it doesn't collide with values > normally held in the `symbol-function` slot, like function names, > function values, cons cells, vectors, ... > > The upside was a simplification in various chunks of code which used to > do things like `(and (fboundp SYM) (symbol-function SYM))` which can now > be simplified to `(symbol-function SYM)`. > > I remember two "motivators", i.e. places where the need to pay attention > to the special void case annoyed me enough to look into this and make > the change, one was `nadvice.el` and the other was `cl-letf`. > [ So, it was no accident that the change happened in the same release as > the addition of `nadvice.el`. ] > > In both cases the issue is that we want to deal with "places" > (generalized variables) and that abstraction works well for those places > which *always* contain a value, but not as well for those special places > that can be "unbound", so removing the "unbound" case from > `symbol-function` resulted in a welcome simplification. > For the same reason I dislike EIEIO's notion of `slot-boundp` and have > already considered marking it obsolete. Thanks, I've now updated the documentation, and I'm closing this bug. ------------=_1730027942-914-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 19 Oct 2024 14:38:20 +0000 Received: from localhost ([127.0.0.1]:44256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2Aay-0003Y0-8K for submit@debbugs.gnu.org; Sat, 19 Oct 2024 10:38:20 -0400 Received: from lists.gnu.org ([209.51.188.17]:52896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2Aav-0003Xs-Om for submit@debbugs.gnu.org; Sat, 19 Oct 2024 10:38:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2AaX-0000Sm-LF for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2024 10:37:53 -0400 Received: from woodpecker.gentoo.org ([140.211.166.183] helo=smtp.gentoo.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1t2AaW-0006WU-13 for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2024 10:37:53 -0400 From: Ulrich =?utf-8?Q?M=C3=BCller?= To: bug-gnu-emacs@gnu.org Subject: 29.4; Confusing info about void function cells in Emacs Lisp manual Date: Sat, 19 Oct 2024 16:37:33 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=140.211.166.183; envelope-from=ulm@gentoo.org; helo=smtp.gentoo.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) 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.6 (--) Section 13.9 "Accessing Function Cell Contents" of the GNU Emacs Lisp Reference Manual emphasizes the distinction between void and nil in function cells: | Note that void is not the same as =E2=80=98nil=E2=80=99 or the symbol = =E2=80=98void=E2=80=99. | The symbols =E2=80=98nil=E2=80=99 and =E2=80=98void=E2=80=99 are Lisp obj= ects, and can be stored into | a function cell just as any other object can be (and =E2=80=98void=E2=80= =99 can be a | valid function if you define it with =E2=80=98defun=E2=80=99). A void fu= nction cell | contains no object whatsoever. | You can test the voidness of a symbol's function definition with | =E2=80=98fboundp=E2=80=99. After you have given a symbol a function defi= nition, you | can make it void once more using =E2=80=98fmakunbound=E2=80=99. Also, for "fboundp": | This function returns =E2=80=98t=E2=80=99 if the symbol has an objec= t in its | function cell, =E2=80=98nil=E2=80=99 otherwise. It does not check t= hat the | object is a legitimate function. It seems that the actual behavior does not reflect this, i.e. there is no distinction between nil and void: (fmakunbound 'foo) (fboundp 'foo) =E2=87=92 nil (fset 'foo nil) ;; according to the manual, the following should return t ;; because nil is a Lisp object: (fboundp 'foo) =E2=87=92 nil Is the manual wrong, or am I missing something? ------------=_1730027942-914-1-- From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Ulrich =?UTF-8?Q?M=C3=BCller?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2024 13:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Stefan Monnier , 73886-done@debbugs.gnu.org Received: via spool by 73886-done@debbugs.gnu.org id=D73886.173003651427086 (code D ref 73886); Sun, 27 Oct 2024 13:42:01 +0000 Received: (at 73886-done) by debbugs.gnu.org; 27 Oct 2024 13:41:54 +0000 Received: from localhost ([127.0.0.1]:44305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t53Wk-00072o-3S for submit@debbugs.gnu.org; Sun, 27 Oct 2024 09:41:54 -0400 Received: from woodpecker.gentoo.org ([140.211.166.183]:46460 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t53Wi-00072Z-RN for 73886-done@debbugs.gnu.org; Sun, 27 Oct 2024 09:41:53 -0400 From: Ulrich =?UTF-8?Q?M=C3=BCller?= In-Reply-To: <864j4xaj6l.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Oct 2024 13:17:54 +0200") References: <86ldykj8a4.fsf@gnu.org> <86frorjqs5.fsf@gnu.org> <864j4xaj6l.fsf@gnu.org> Date: Sun, 27 Oct 2024 14:40:36 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) 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 (---) >>>>> On Sun, 27 Oct 2024, Eli Zaretskii wrote: > Thanks, I've now updated the documentation, and I'm closing this bug. TBH, I find the new wording still confusing: "It is impossible to distinguish between a function cell that is void and one set to nil." After commit eadf1faa3cb5eea8c25a5166a9a97ebd63525c56 there are no void function cells any more. They start out as nil and they always contain a lisp object. So, differentiating between nil and void in the manual seems a little artificial. Also, there is the following paragraph in symbols.texi which probably should be updated (regardless of what I said above): | The function cell or the value cell may be @dfn{void}, which means | that the cell does not reference any object. (This is not the same | thing as holding the symbol @code{void}, nor the same as holding the | symbol @code{nil}.) Examining a function or value cell that is void | results in an error, such as @samp{Symbol's value as variable is void}. From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2024 14:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ulrich =?UTF-8?Q?M=C3=BCller?= Cc: monnier@iro.umontreal.ca, 73886-done@debbugs.gnu.org Received: via spool by 73886-done@debbugs.gnu.org id=D73886.1730038149997 (code D ref 73886); Sun, 27 Oct 2024 14:10:02 +0000 Received: (at 73886-done) by debbugs.gnu.org; 27 Oct 2024 14:09:09 +0000 Received: from localhost ([127.0.0.1]:45839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t53x7-0000G0-8l for submit@debbugs.gnu.org; Sun, 27 Oct 2024 10:09:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t53x5-0000Fd-B4 for 73886-done@debbugs.gnu.org; Sun, 27 Oct 2024 10:09:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t53wQ-0002fH-Er; Sun, 27 Oct 2024 10:08:26 -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=9i7wLgwNHUKPU2GTObDlcLV388asyYKL5Ys4W5sGaU4=; b=UMMkijuiJTrMhlhJ0sU9 AsL3kZ4QnutrG37ivQAvll4TSrC4v9bZBE8Vq4AZGGWDzDD8pFwAXNn7QRkCkCHKxKMLVRz2uD17V Yh7RAbSqdFCxmrMqC9ojElFGSPiWLOBk3DHVfBLnazXOXIfifvJCBmPGhh4ZiewrYWKuJnSw7mf0u i8nWxipvq1UdXbI+1TqzT4I0YPbVj6f1jbIcP8QR1pUmu6IYp8KDsOvmFMcBYJYaUCsomneA4gmcT e7MHKc/okF2NcCxtDZvpNg8mGWnGRsTBhN1DV59BeVhO5O9AN84ddE+55kzmAE2B7BKdBl1jbvMkO TcrTSEpeRNsdBw==; Date: Sun, 27 Oct 2024 16:08:23 +0200 Message-Id: <86msip8wq0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Ulrich =?UTF-8?Q?M=C3=BCller?= on Sun, 27 Oct 2024 14:40:36 +0100) References: <86ldykj8a4.fsf@gnu.org> <86frorjqs5.fsf@gnu.org> <864j4xaj6l.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) 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: Ulrich Müller > Cc: Stefan Monnier , 73886-done@debbugs.gnu.org > Date: Sun, 27 Oct 2024 14:40:36 +0100 > > >>>>> On Sun, 27 Oct 2024, Eli Zaretskii wrote: > > > Thanks, I've now updated the documentation, and I'm closing this bug. > > TBH, I find the new wording still confusing: "It is impossible to > distinguish between a function cell that is void and one set to nil." > After commit eadf1faa3cb5eea8c25a5166a9a97ebd63525c56 there are no void > function cells any more. A function that was not defined at all is void. > They start out as nil and they always contain a lisp object. That's an implementation detail. The ELisp manual does not describe the implementation, not on such a low level. The previous text didn't mention the implementation (the special symbol 'unbound') either. > So, differentiating between nil and void in the manual seems a > little artificial. Which is what the text now says. > Also, there is the following paragraph in symbols.texi which probably > should be updated (regardless of what I said above): Thanks, fixed. From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2024 15:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Ulrich =?UTF-8?Q?M=C3=BCller?= , 73886-done@debbugs.gnu.org Received: via spool by 73886-done@debbugs.gnu.org id=D73886.17300412199741 (code D ref 73886); Sun, 27 Oct 2024 15:01:01 +0000 Received: (at 73886-done) by debbugs.gnu.org; 27 Oct 2024 15:00:19 +0000 Received: from localhost ([127.0.0.1]:45914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t54kc-0002X3-JJ for submit@debbugs.gnu.org; Sun, 27 Oct 2024 11:00:19 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t54kW-0002Va-Dg for 73886-done@debbugs.gnu.org; Sun, 27 Oct 2024 11:00:15 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0C6BB100180; Sun, 27 Oct 2024 10:59:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730041165; bh=SfgFE0pj0T0iL0seOlzwIcmly0QLqjYbD1CUxddbUWY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=K3wwqGV8Q6/VptsUr8DOD7ywUvIrdOOP1b3EPgk88fu9g6598kNo3ROppcWj6GeNu IiZzWBxiDzemUDTS5sSY6TQVH1yfPKN04TzkcZ+mYARUr159IrO+L5t7CHSoH172IR FG+mhnkfGflnR97iP2cmphwI5B2IYYsJYHUpg96SjD77rPTKIzF6wkDrRS4ZIGrtRr uLIDGpzh5VnLuUnDNWzFNjME45VoZYah1FYdTproDTrTzM3Lyj1oehFYg9QVCOOrwq Bj6/ISthCV/0wk4LX09xkNdApq2WXqiBeMD05BStXYriRLuY6zNQ87qzjm9ikiAZvs vy+rSdlAuJeFg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0B4D5100043; Sun, 27 Oct 2024 10:59:25 -0400 (EDT) Received: from pastel (69-196-161-60.dsl.teksavvy.com [69.196.161.60]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D0013120418; Sun, 27 Oct 2024 10:59:24 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86msip8wq0.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Oct 2024 16:08:23 +0200") Message-ID: References: <86ldykj8a4.fsf@gnu.org> <86frorjqs5.fsf@gnu.org> <864j4xaj6l.fsf@gnu.org> <86msip8wq0.fsf@gnu.org> Date: Sun, 27 Oct 2024 10:59:23 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) 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.046 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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, I've now updated the documentation, and I'm closing this bug. >> TBH, I find the new wording still confusing: "It is impossible to >> distinguish between a function cell that is void and one set to nil." >> After commit eadf1faa3cb5eea8c25a5166a9a97ebd63525c56 there are no void >> function cells any more. > A function that was not defined at all is void. How 'bout the patch below, which tries to eliminate the notion that a function cell ever contains "void", reducing "void function" to just a terminology to describe the nil value in function cells? Stefan diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi index bfb8789d05b..3a6da5c31e6 100644 --- a/doc/lispref/functions.texi +++ b/doc/lispref/functions.texi @@ -1511,10 +1511,6 @@ Function Cells This returns the object in the function cell of @var{symbol}. It does not check that the returned object is a legitimate function. -If the function cell is void, the return value is @code{nil}. It is -impossible to distinguish between a function cell that is void and one -set to @code{nil}. - @example @group (defun bar (n) (+ n 2)) @@ -1533,9 +1529,9 @@ Function Cells @end defun @cindex void function cell - If you have never given a symbol any function definition, we say -that that symbol's function cell is @dfn{void}. In other words, the -function cell does not have any Lisp object in it. If you try to call + If you have never given a symbol any function definition, its function +cell contains the default value @code{nil} and we say +that that symbol's function cell is @dfn{void}. If you try to call the symbol as a function, Emacs signals a @code{void-function} error. Unlike with void variables (@pxref{Void Variables}), a symbol's diff --git a/src/data.c b/src/data.c index bf83755bff3..904eaf35c1a 100644 --- a/src/data.c +++ b/src/data.c @@ -756,7 +756,7 @@ DEFUN ("boundp", Fboundp, Sboundp, 1, 1, 0, breaking backward compatibility, as some users of fboundp may expect t in particular, rather than any true value. */ DEFUN ("fboundp", Ffboundp, Sfboundp, 1, 1, 0, - doc: /* Return t if SYMBOL's function definition is neither void nor nil. */) + doc: /* Return t if SYMBOL's function definition is not nil. */) (Lisp_Object symbol) { CHECK_SYMBOL (symbol); @@ -785,7 +785,7 @@ DEFUN ("fmakunbound", Ffmakunbound, Sfmakunbound, 1, 1, 0, doc: /* Make SYMBOL's function definition be nil. Return SYMBOL. -If a function definition is nil or void, trying to call a function by +If a function definition is nil, trying to call a function by that name will cause a `void-function' error. For more details, see Info node `(elisp) Function Cells'. @@ -800,7 +800,7 @@ DEFUN ("fmakunbound", Ffmakunbound, Sfmakunbound, 1, 1, 0, } DEFUN ("symbol-function", Fsymbol_function, Ssymbol_function, 1, 1, 0, - doc: /* Return SYMBOL's function definition, or nil if that is void or nil. */) + doc: /* Return SYMBOL's function definition. */) (Lisp_Object symbol) { CHECK_SYMBOL (symbol); From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2024 16:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: ulm@gentoo.org, 73886@debbugs.gnu.org Received: via spool by 73886-submit@debbugs.gnu.org id=B73886.173004784829278 (code B ref 73886); Sun, 27 Oct 2024 16:51:02 +0000 Received: (at 73886) by debbugs.gnu.org; 27 Oct 2024 16:50:48 +0000 Received: from localhost ([127.0.0.1]:46036 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t56TY-0007cA-0x for submit@debbugs.gnu.org; Sun, 27 Oct 2024 12:50:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57992) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t56TW-0007XW-R8 for 73886@debbugs.gnu.org; Sun, 27 Oct 2024 12:50:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t56Sr-0008NG-0V; Sun, 27 Oct 2024 12:50:05 -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=UYtdMF52I8s6CZKGkgPxpLgr8rQ/IdjOJN5RGpsKpQE=; b=BBNQV25vcl+1FYa2HFE7 k7Sdeo/HyMR5aezfDTFNbwczDdV+UIBrTvO8HZOVifGmGFcQ9hjZ8ejL+HhJDJAYovAVAll1pq7mT VEYrcv6b7OZ5uBvfWj7BlYVXuGSPfaY/ORuqO/AqYuvUOsWjpz6HIjc1MlABPUcvAyjFyZdJJz7ct P7JeT2m9x+EmSTm5jUPAmWQvz67Qe8BzXO6ZQu/1UJ6C28AhW/yS54A+VdWnZf6lc0svEZ55cw5I6 PRXYxVfc5l/tRGo6fkjbMyvi2UEBnejNoD1kMhi09TKah/SZNJEc5NpPT8Wj5f4Ne646yeQilHc7l EaK+cG7FN0h4yg==; Date: Sun, 27 Oct 2024 18:50:02 +0200 Message-Id: <86ldy98p8l.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sun, 27 Oct 2024 10:59:23 -0400) References: <86ldykj8a4.fsf@gnu.org> <86frorjqs5.fsf@gnu.org> <864j4xaj6l.fsf@gnu.org> <86msip8wq0.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) 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: Ulrich Müller , > 73886-done@debbugs.gnu.org > Date: Sun, 27 Oct 2024 10:59:23 -0400 > > How 'bout the patch below, which tries to eliminate the notion that > a function cell ever contains "void", reducing "void function" to just > a terminology to describe the nil value in function cells? Fine by me, with one exception: > -If the function cell is void, the return value is @code{nil}. It is > -impossible to distinguish between a function cell that is void and one > -set to @code{nil}. I would leave the second sentence here alone, but if you don't want to say "function cell is void", just say "function that is void". I would not recommend to never use "void function" because otherwise the error message we show in those cases will not make sense. From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2024 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: ulm@gentoo.org, 73886@debbugs.gnu.org Received: via spool by 73886-submit@debbugs.gnu.org id=B73886.1730049072326 (code B ref 73886); Sun, 27 Oct 2024 17:12:02 +0000 Received: (at 73886) by debbugs.gnu.org; 27 Oct 2024 17:11:12 +0000 Received: from localhost ([127.0.0.1]:46062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t56nG-000055-3D for submit@debbugs.gnu.org; Sun, 27 Oct 2024 13:11:12 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t56nE-00004r-Ii for 73886@debbugs.gnu.org; Sun, 27 Oct 2024 13:11:09 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C25B2441652; Sun, 27 Oct 2024 13:10:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730049024; bh=GMb/BTyXRU/jN03eERHiFIPjAw/zLf2ZxGePQzVUlU0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ozWXnCV+Ta6PbDaDDP4oCpD24mFGClTZI9X0wSCRK4B4lzmqJBJSiGnLuz+vDa+rU DihrXG6yTxFgy0jVK0JOq1rasseUeMwmfjEz9uZKkq8dVMfEXzyymuqhnaY+bfkfO4 5WnRtsGDMKpWC9xTVogbu8pvBn0hNrCzALGQMoIHAsm6IFVLuthiEYH51PK3rDlpPH JAtreNDItDHy7ydYBxxSsGIrFhVswUD8h1ItCABd4tEgAysuN3VzvyvAQDz8n3LLcf z2M3Kf0A4mOHWuV35+LdQS0xiiAzd9nJaBQhjICZysKlalLrNVKKEusFxBB+lEuX6M FZzUWILlg+utA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8979A44124A; Sun, 27 Oct 2024 13:10:24 -0400 (EDT) Received: from pastel (69-196-161-60.dsl.teksavvy.com [69.196.161.60]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5761B1202C4; Sun, 27 Oct 2024 13:10:24 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86ldy98p8l.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Oct 2024 18:50:02 +0200") Message-ID: References: <86ldykj8a4.fsf@gnu.org> <86frorjqs5.fsf@gnu.org> <864j4xaj6l.fsf@gnu.org> <86msip8wq0.fsf@gnu.org> <86ldy98p8l.fsf@gnu.org> Date: Sun, 27 Oct 2024 13:10:23 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) 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.141 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> -If the function cell is void, the return value is @code{nil}. It is >> -impossible to distinguish between a function cell that is void and one >> -set to @code{nil}. > > I would leave the second sentence here alone, but if you don't want to > say "function cell is void", just say "function that is void". I > would not recommend to never use "void function" because otherwise the > error message we show in those cases will not make sense. IMO, we should talk about a function being void, but not about its function cell being void. And I'd rather not suggest that distinguishing void from nil is even a meaningful question. How 'bout the patch below? Stefan diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi index bfb8789d05b..7fb9fb37c0a 100644 --- a/doc/lispref/functions.texi +++ b/doc/lispref/functions.texi @@ -1510,10 +1510,7 @@ Function Cells @kindex void-function This returns the object in the function cell of @var{symbol}. It does not check that the returned object is a legitimate function. - -If the function cell is void, the return value is @code{nil}. It is -impossible to distinguish between a function cell that is void and one -set to @code{nil}. +If the function is void, the return value is @code{nil}. @example @group @@ -1533,9 +1530,9 @@ Function Cells @end defun @cindex void function cell - If you have never given a symbol any function definition, we say -that that symbol's function cell is @dfn{void}. In other words, the -function cell does not have any Lisp object in it. If you try to call + If you have never given a symbol any function definition, its function +cell contains the default value @code{nil} and we say +that that function is @dfn{void}. If you try to call the symbol as a function, Emacs signals a @code{void-function} error. Unlike with void variables (@pxref{Void Variables}), a symbol's From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2024 17:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: ulm@gentoo.org, 73886@debbugs.gnu.org Received: via spool by 73886-submit@debbugs.gnu.org id=B73886.17300497062131 (code B ref 73886); Sun, 27 Oct 2024 17:22:02 +0000 Received: (at 73886) by debbugs.gnu.org; 27 Oct 2024 17:21:46 +0000 Received: from localhost ([127.0.0.1]:46079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t56xV-0000YI-OR for submit@debbugs.gnu.org; Sun, 27 Oct 2024 13:21:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t56xT-0000Y3-NJ for 73886@debbugs.gnu.org; Sun, 27 Oct 2024 13:21:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t56wo-0002aI-Bt; Sun, 27 Oct 2024 13:21:02 -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=ZuJUgZDcDuPk7HcgV+3AuNkw1MIe8XW4MUUv6Tak1pA=; b=fpZIyRhgNdCr WVlYZJBUyKbNA9yJ9LqaRbdVo4FjOUXksn379Bf//eYJnD7pXMuqYJS02TPlIwByWhKI6dGuxH7DH xF7m4OOzqpAhkhCldlV3cuqvFWDSN2+gz+VT/5lHRGtB3Xk+ZBaERpVNlA/CLVLGFtRHUq9tyRv/k 73FDJxdRzeMAbNBOXRnaUD8RQDaWftuMyNZARx0b2AB6wAizTA149zwnE9VyJKo8HmORIDTOqw1yC EDY0iPAuDM/9q/NzYyHPTuSMBaFri8rEfeESrVtY1h6mpMW9oqzBSg27yXKAKDhPPhOfz86EKCqd7 5UosdN91iAVcdo8cpaArLA==; Date: Sun, 27 Oct 2024 19:20:58 +0200 Message-Id: <86froh8nt1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sun, 27 Oct 2024 13:10:23 -0400) References: <86ldykj8a4.fsf@gnu.org> <86frorjqs5.fsf@gnu.org> <864j4xaj6l.fsf@gnu.org> <86msip8wq0.fsf@gnu.org> <86ldy98p8l.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: ulm@gentoo.org, 73886@debbugs.gnu.org > Date: Sun, 27 Oct 2024 13:10:23 -0400 > > IMO, we should talk about a function being void, but not about its > function cell being void. And I'd rather not suggest that > distinguishing void from nil is even a meaningful question. > > How 'bout the patch below? Fine by me. From unknown Sat Aug 16 15:53:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2024 18:54:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: ulm@gentoo.org, 73886-done@debbugs.gnu.org Received: via spool by 73886-done@debbugs.gnu.org id=D73886.173005522619175 (code D ref 73886); Sun, 27 Oct 2024 18:54:03 +0000 Received: (at 73886-done) by debbugs.gnu.org; 27 Oct 2024 18:53:46 +0000 Received: from localhost ([127.0.0.1]:46336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t58OX-0004zD-Mg for submit@debbugs.gnu.org; Sun, 27 Oct 2024 14:53:45 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t58OW-0004yw-H6 for 73886-done@debbugs.gnu.org; Sun, 27 Oct 2024 14:53:44 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2EBAA100180; Sun, 27 Oct 2024 14:53:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730055182; bh=8JirXVbStJ//RIjqwyMmMfn0iifq3e5d3GSo9e0mkoQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I6pB5kHUlqgkzgEZiisp8zHOSamWgi2eC65zDy/8XFZdEMygxqamb/nV7GJDeOdmN nJ1yjfeoC8R/cRIS4hTrCW7JCw3qGPhPWnRY3js+o8E6/njBgkp80nnhNL2gDlzqHn ADrtAUo2zt8OSFuV+hLT4soWdGG0eFsA9GbY19ComV2l3xF9WrNa4y40svs2m0p5Qw pvAEMRs4271pG1Fflrmz0cJtlGeWrz+HKxyC1sD+36jcHVSImavI5pfBpQZTOD0OCN Rxe/f4dyTl9E4jMBeOe3PYPx5M7pemXpXBkNim9V9dX8RNup1bOVzi+E5wyYFqBBG9 K5kjuwjc6Jieg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7B65D100043; Sun, 27 Oct 2024 14:53:02 -0400 (EDT) Received: from pastel (unknown [69.196.161.60]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4F54612013C; Sun, 27 Oct 2024 14:53:02 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86froh8nt1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Oct 2024 19:20:58 +0200") Message-ID: References: <86ldykj8a4.fsf@gnu.org> <86frorjqs5.fsf@gnu.org> <864j4xaj6l.fsf@gnu.org> <86msip8wq0.fsf@gnu.org> <86ldy98p8l.fsf@gnu.org> <86froh8nt1.fsf@gnu.org> Date: Sun, 27 Oct 2024 14:53:00 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) 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.043 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> How 'bout the patch below? > Fine by me. Thanks, pushed to `emacs-30`. Stefan