From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Aug 2013 16:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 15117@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.137675521417721 (code B ref -1); Sat, 17 Aug 2013 16:01:02 +0000 Received: (at submit) by debbugs.gnu.org; 17 Aug 2013 16:00:14 +0000 Received: from localhost ([127.0.0.1]:36927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VAivE-0004bi-0s for submit@debbugs.gnu.org; Sat, 17 Aug 2013 12:00:13 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46616) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VAiv9-0004aX-FA for submit@debbugs.gnu.org; Sat, 17 Aug 2013 12:00:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VAiuu-0006z5-5S for submit@debbugs.gnu.org; Sat, 17 Aug 2013 12:00:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-100.5 required=5.0 tests=BAYES_05, USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VAiuu-0006z1-2B for submit@debbugs.gnu.org; Sat, 17 Aug 2013 11:59:52 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VAiul-0003ED-C3 for bug-gnu-emacs@gnu.org; Sat, 17 Aug 2013 11:59:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VAiuZ-0006uc-ID for bug-gnu-emacs@gnu.org; Sat, 17 Aug 2013 11:59:43 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:46874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VAiuZ-0006uT-8P for bug-gnu-emacs@gnu.org; Sat, 17 Aug 2013 11:59:31 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7HFxT3x009801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Aug 2013 15:59:30 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HFxSHG014358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Aug 2013 15:59:29 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HFxSSS012578 for ; Sat, 17 Aug 2013 15:59:28 GMT MIME-Version: 1.0 Message-ID: <1dc76f7a-5481-41df-b976-ec22229d7283@default> Date: Sat, 17 Aug 2013 08:59:27 -0700 (PDT) From: Drew Adams X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.4 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.4 (--) These are motion functions, just like `goto-char' and `skip-chars-forward'. Their doc should specify the return value (regardless of whether it is a position, a Boolean, always nil, or anything else). If, for some special (good) reason, code should not rely on the return value of some function then this fact should be stated explicitly in the doc: "This function is used only for its side effects; the return value is undefined." This is Lisp, not C - return values are the norm, not the exception. The doc of `(forward|backward)-(word|line)' already correctly specifies the return value. Not so for other `(forward|backward)-*' functions, such as `(forward|backward)-sexp'. In GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-08-07 on ODIEONE Bzr revision: 113750 lekktu@gmail.com-20130808011911-0jzpc9xuncegg6x9 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=3D/c/Devel/emacs/binary --enable-checking=3Dyes,glyphs CFLAGS=3D-O0 -g3 LDFLAGS=3D-Lc:/Devel/emacs/lib CPPFLAGS=3D-Ic:/Devel/emacs/include' From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Feb 2014 05:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 15117@debbugs.gnu.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.13918361841066 (code B ref 15117); Sat, 08 Feb 2014 05:10:02 +0000 Received: (at 15117) by debbugs.gnu.org; 8 Feb 2014 05:09:44 +0000 Received: from localhost ([127.0.0.1]:56032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WC0Ai-0000H8-5O for submit@debbugs.gnu.org; Sat, 08 Feb 2014 00:09:44 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:48149) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WC0Ag-0000H0-3l for 15117@debbugs.gnu.org; Sat, 08 Feb 2014 00:09:42 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WC0AS-0005Qr-1P; Sat, 08 Feb 2014 06:09:28 +0100 From: Lars Ingebrigtsen References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> Date: Fri, 07 Feb 2014 21:08:19 -0800 In-Reply-To: <1dc76f7a-5481-41df-b976-ec22229d7283@default> (Drew Adams's message of "Sat, 17 Aug 2013 08:59:27 -0700 (PDT)") Message-ID: <874n4a42f0.fsf@building.gnus.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1WC0AS-0005Qr-1P X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392440968.53874@nYImfxE8vBSimrmn9dK3hQ X-Spam-Status: No X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 0.0 (/) Drew Adams writes: > These are motion functions, just like `goto-char' and > `skip-chars-forward'. Their doc should specify the return value > (regardless of whether it is a position, a Boolean, always nil, or > anything else). > > If, for some special (good) reason, code should not rely on the return > value of some function then this fact should be stated explicitly in > the doc: "This function is used only for its side effects; the return > value is undefined." This is Lisp, not C - return values are the norm, > not the exception. No, in Emacs we seldom say that. Functions used for side effect are quite normal. > The doc of `(forward|backward)-(word|line)' already correctly specifies > the return value. Not so for other `(forward|backward)-*' functions, > such as `(forward|backward)-sexp'. They don't seem to return anything useful. Closing. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 08 00:09:50 2014 Received: (at control) by debbugs.gnu.org; 8 Feb 2014 05:09:51 +0000 Received: from localhost ([127.0.0.1]:56035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WC0Ao-0000HS-F5 for submit@debbugs.gnu.org; Sat, 08 Feb 2014 00:09:50 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:48155) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WC0Am-0000HI-7V for control@debbugs.gnu.org; Sat, 08 Feb 2014 00:09:48 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WC0AY-0005R4-8r for control@debbugs.gnu.org; Sat, 08 Feb 2014 06:09:34 +0100 Date: Fri, 07 Feb 2014 21:08:26 -0800 Message-Id: <8738ju42et.fsf@building.gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #15117 X-MailScanner-ID: 1WC0AY-0005R4-8r X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392440974.79664@2QTs8N/xJq/JceTj005Ycw X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 0.0 (/) tags 15117 wontfix close 15117 From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2014 00:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Lars Ingebrigtsen Cc: 15117@debbugs.gnu.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139199115910901 (code B ref 15117); Mon, 10 Feb 2014 00:13:01 +0000 Received: (at 15117) by debbugs.gnu.org; 10 Feb 2014 00:12:39 +0000 Received: from localhost ([127.0.0.1]:32811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCeUI-0002pk-SB for submit@debbugs.gnu.org; Sun, 09 Feb 2014 19:12:39 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:19932) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCeUF-0002pN-Tw for 15117@debbugs.gnu.org; Sun, 09 Feb 2014 19:12:36 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1A0CYCc032708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Feb 2014 00:12:35 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1A0CY6G014595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 00:12:34 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s1A0CXCi006291; Mon, 10 Feb 2014 00:12:33 GMT MIME-Version: 1.0 Message-ID: <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> Date: Sun, 9 Feb 2014 16:12:31 -0800 (PST) From: Drew Adams References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> In-Reply-To: <874n4a42f0.fsf@building.gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.9 (--) > > These are motion functions, just like `goto-char' and > > `skip-chars-forward'. Their doc should specify the return value > > (regardless of whether it is a position, a Boolean, always nil, or > > anything else). > > > > If, for some special (good) reason,=20 What is that special, good reason? > > code should not rely on the return value of some function then > > this fact should be stated explicitly in the doc: "This function > > is used only for its side effects; the return value is undefined." > > This is Lisp, not C - return values are the norm, > > not the exception. >=20 > No, in Emacs we seldom say that. Functions used for side effect are > quite normal. Please _read_. No one said that side-effect functions are abnormal. These are NOT side-effect functions. They modify nothing except the cursor position. These are normal, ordinary, run-of-the-mill motion functions. Their return values should be specified. We do not proscribe users from using the return value of motion functions, in general - quite the contrary. > > The doc of `(forward|backward)-(word|line)' already correctly > > specifies the return value. Not so for other > > `(forward|backward)-*' functions, such as `(forward|backward)-sexp'. >=20 > They don't seem to return anything useful. Closing. Where do you get off saying that? Of course it is useful to use the return value of a motion function. It saves a call to `point', which can simplify the code. (Yes, simple and beautiful is in the eye of the reader. But the point is that it is normal for users to make use of the return value of a motion function that is side-effect free. Reopening. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2014 02:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Drew Adams Cc: 15117@debbugs.gnu.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139200006610868 (code B ref 15117); Mon, 10 Feb 2014 02:42:02 +0000 Received: (at 15117) by debbugs.gnu.org; 10 Feb 2014 02:41:06 +0000 Received: from localhost ([127.0.0.1]:33031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCgny-0002pD-1a for submit@debbugs.gnu.org; Sun, 09 Feb 2014 21:41:06 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:41867) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCgnv-0002p4-F7 for 15117@debbugs.gnu.org; Sun, 09 Feb 2014 21:41:03 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WCgng-0004TR-Vi; Mon, 10 Feb 2014 03:40:49 +0100 From: Lars Ingebrigtsen References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> Date: Sun, 09 Feb 2014 18:39:36 -0800 In-Reply-To: <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> (Drew Adams's message of "Sun, 9 Feb 2014 16:12:31 -0800 (PST)") Message-ID: <87fvnry9lj.fsf@building.gnus.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1WCgng-0004TR-Vi X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392604849.51628@+cuj7hWTb1fdxeyD/3dcyQ X-Spam-Status: No X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 0.0 (/) Drew Adams writes: >> They don't seem to return anything useful. Closing. > > Where do you get off saying that? Of course it is useful to > use the return value of a motion function. It saves a call to > `point', which can simplify the code. (Yes, simple and beautiful > is in the eye of the reader. But the point is that it is normal > for users to make use of the return value of a motion function > that is side-effect free. Reopening. If other developers disagree with my closing the bug, they can reopen. Reclosing. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 09 21:41:31 2014 Received: (at control) by debbugs.gnu.org; 10 Feb 2014 02:41:32 +0000 Received: from localhost ([127.0.0.1]:33034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCgoN-0002pz-MI for submit@debbugs.gnu.org; Sun, 09 Feb 2014 21:41:31 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:41873) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCgoM-0002ps-Ki for control@debbugs.gnu.org; Sun, 09 Feb 2014 21:41:30 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WCgo8-0004Tw-Su for control@debbugs.gnu.org; Mon, 10 Feb 2014 03:41:17 +0100 Date: Sun, 09 Feb 2014 18:40:03 -0800 Message-Id: <87eh3by9ks.fsf@building.gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #15117 X-MailScanner-ID: 1WCgo8-0004Tw-Su X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392604877.48181@BgQAvh6mlz2I2oghQwKAhw X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 0.0 (/) tags 15117 wontfix close 15117 From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2014 02:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Lars Ingebrigtsen Cc: 15117@debbugs.gnu.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139200033213776 (code B ref 15117); Mon, 10 Feb 2014 02:46:02 +0000 Received: (at 15117) by debbugs.gnu.org; 10 Feb 2014 02:45:32 +0000 Received: from localhost ([127.0.0.1]:33049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCgsG-0003Zl-6d for submit@debbugs.gnu.org; Sun, 09 Feb 2014 21:45:32 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:47604) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCgsE-0003Xi-Jp for 15117@debbugs.gnu.org; Sun, 09 Feb 2014 21:45:31 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1A2jTnh009299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Feb 2014 02:45:30 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1A2jTIw021175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 02:45:29 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1A2jSD4007372; Mon, 10 Feb 2014 02:45:28 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 9 Feb 2014 18:45:26 -0800 (PST) From: Drew Adams References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <87fvnry9lj.fsf@building.gnus.org> In-Reply-To: <87fvnry9lj.fsf@building.gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.9 (--) > >> They don't seem to return anything useful. Closing. > > > > Where do you get off saying that? Of course it is useful to > > use the return value of a motion function. It saves a call to > > `point', which can simplify the code. (Yes, simple and beautiful > > is in the eye of the reader. But the point is that it is normal > > for users to make use of the return value of a motion function > > that is side-effect free. Reopening. >=20 > If other developers disagree with my closing the bug, they can > reopen. >=20 > Reclosing. I already did disagree. This is quite ludicrous. Just how do you think you are improving things by doing this? From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2014 16:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Drew Adams Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.13920496616097 (code B ref 15117); Mon, 10 Feb 2014 16:28:02 +0000 Received: (at 15117) by debbugs.gnu.org; 10 Feb 2014 16:27:41 +0000 Received: from localhost ([127.0.0.1]:41508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCths-0001aG-7e for submit@debbugs.gnu.org; Mon, 10 Feb 2014 11:27:40 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:47271) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCthp-0001a2-BM for 15117@debbugs.gnu.org; Mon, 10 Feb 2014 11:27:37 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFHO+KAF/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IPAS-Result: Av8EABK/CFHO+KAF/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="47203613" Received: from 206-248-160-5.dsl.teksavvy.com (HELO pastel.home) ([206.248.160.5]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 Feb 2014 11:27:31 -0500 Received: by pastel.home (Postfix, from userid 20848) id 0FF7D616C6; Mon, 10 Feb 2014 11:27:31 -0500 (EST) From: Stefan Monnier Message-ID: References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> Date: Mon, 10 Feb 2014 11:27:31 -0500 In-Reply-To: <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> (Drew Adams's message of "Sun, 9 Feb 2014 16:12:31 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 0.3 (/) > These are NOT side-effect functions. They modify nothing except > the cursor position. How is that not a side-effect? Stefan From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2014 21:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Stefan Monnier Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139206700124711 (code B ref 15117); Mon, 10 Feb 2014 21:17:01 +0000 Received: (at 15117) by debbugs.gnu.org; 10 Feb 2014 21:16:41 +0000 Received: from localhost ([127.0.0.1]:41857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCyDY-0006QV-KW for submit@debbugs.gnu.org; Mon, 10 Feb 2014 16:16:40 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:29526) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCyDW-0006QH-PT for 15117@debbugs.gnu.org; Mon, 10 Feb 2014 16:16:39 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1ALGVCY013677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Feb 2014 21:16:32 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1ALGTZP026309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 21:16:30 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s1ALGSD4000815; Mon, 10 Feb 2014 21:16:28 GMT MIME-Version: 1.0 Message-ID: <2fefcbaf-9417-4f57-93af-490ea73aea98@default> Date: Mon, 10 Feb 2014 13:16:27 -0800 (PST) From: Drew Adams References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.9 (--) > > These are NOT side-effect functions. They modify nothing except > > the cursor position. >=20 > How is that not a side-effect? You are clearly arguing for the sake of arguing, now. Everything in the universe has side effects. Ohhmmmm. It's true. Motion functions are not what is typically meant by a side-effect function. They do not change the contents of the buffer, for example, in the sense of `buffer-modified-p'. These functions are like `goto-char' and `skip-chars-forward', as mentioned in the bug report. They are also like `forward-line', another motion function whose return value we document. And `beginning-of-defun' - another. By your (newfound) logic, you will presumably remove mention of the return value from the doc for those functions. The same logic behind documenting their return value applies to these other motion functions. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 01:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Drew Adams Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen , Stefan Monnier Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139208088818779 (code B ref 15117); Tue, 11 Feb 2014 01:09:01 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 01:08:08 +0000 Received: from localhost ([127.0.0.1]:42158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD1pX-0004so-Sd for submit@debbugs.gnu.org; Mon, 10 Feb 2014 20:08:08 -0500 Received: from mail-ee0-f47.google.com ([74.125.83.47]:61822) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD1pV-0004sH-Nb for 15117@debbugs.gnu.org; Mon, 10 Feb 2014 20:08:06 -0500 Received: by mail-ee0-f47.google.com with SMTP id d49so3266809eek.20 for <15117@debbugs.gnu.org>; Mon, 10 Feb 2014 17:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=mQVReeEjr6fb+ZViYkfcmmOzWl+0badFH41utaXYs+Y=; b=JDtrsHIJinlOaGjJzhnL2VroMpfaaAuGQh1iVAzflgqagQJ/ALBcaJmpjuu9rh6Asn 6mO5xddY98W8i0rrFUj8K1C0kpaRFDuI1OxbI3no/GEelFwvf6+xz4YX9skNyTlUGyHr XkMEhwg9pFylf8TToMDazNUb71iLajPQ48fUaiLq9nrtWcYsy+qQYeT7fFQmkNgFeSKr qfZX4yxbOXuDwdzgKMyI22FKVMsl7H16HHb+oul0cFxV7g4AlcncMPuzQmanmGghhtw8 EOpJJoN7y2VzanE/xOAAUGvjkObPihK3+6E3Ih9sP61qD+dhXNm8uzf/7eCV2AiBUltf Mkmg== X-Received: by 10.14.177.1 with SMTP id c1mr40390589eem.8.1392080879813; Mon, 10 Feb 2014 17:07:59 -0800 (PST) Received: from axl (62-36-157.netrun.cytanet.com.cy. [62.228.36.157]) by mx.google.com with ESMTPSA id n41sm31237787eeg.16.2014.02.10.17.07.56 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 10 Feb 2014 17:07:58 -0800 (PST) From: Dmitry Gutov References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> Date: Tue, 11 Feb 2014 03:07:50 +0200 In-Reply-To: <2fefcbaf-9417-4f57-93af-490ea73aea98@default> (Drew Adams's message of "Mon, 10 Feb 2014 13:16:27 -0800 (PST)") Message-ID: <87mwhy4ftl.fsf@yandex.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -0.7 (/) Drew Adams writes: > Everything in the universe has side effects. Ohhmmmm. It's true. You should look up "referential transparency". > Motion functions are not what is typically meant by a side-effect > function. They do not change the contents of the buffer, for > example, in the sense of `buffer-modified-p'. Please read http://en.wikipedia.org/wiki/Side_effect_(computer_science) "function with side effects" is a pretty well-defined term. A function does not necessarily have to modify an Emacs buffer to be termed as such. > By your (newfound) logic, you will presumably remove mention of > the return value from the doc for those functions. The same > logic behind documenting their return value applies to these > other motion functions. The logic is simple: if the return value is documented, the caller should be able to depend on it, and "undocumenting" it retroactively isn't an option. As long as the return value is undocumented, but the function can still be useful without it, it can stay that way indefinitely. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 01:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Drew Adams Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen , Stefan Monnier Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139208217120825 (code B ref 15117); Tue, 11 Feb 2014 01:30:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 01:29:31 +0000 Received: from localhost ([127.0.0.1]:42164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD2AE-0005Pp-Sx for submit@debbugs.gnu.org; Mon, 10 Feb 2014 20:29:31 -0500 Received: from mail-yh0-f41.google.com ([209.85.213.41]:50374) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD2AC-0005PW-Pc for 15117@debbugs.gnu.org; Mon, 10 Feb 2014 20:29:29 -0500 Received: by mail-yh0-f41.google.com with SMTP id f73so6171930yha.28 for <15117@debbugs.gnu.org>; Mon, 10 Feb 2014 17:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=0brDIp72JQJ64wuuYJSCTR0/24qDOiLp/FXtFkQDKYA=; b=IXZrrlr1htk3Wtcn83qkiAWQ0qbcBsJD/DBaJ9FkSEzVGk1iX2F1kU6HwAMGZD+Wo+ UsTpdVJDu/4shHdUbMBAmEqzpy/pKW54OBC+8isdUyKkRqB68pBFtbB1zhErpz2wzklb 5fHyLFv35kyT5OaTvR61vj1saGM/Q56TI9uOvxljImJR7sCJW7Z1zE2T8RS9BhN2YGs2 UMM7g5+7C6ogcTnJmlf93mS2tDqAFWnbeMXtBGkAfA4iAwo59nqzUXPOQxHjygg+xtws SCyCAwEe0/VdjnHlVQpmtrK/eohqmSsWCf1Dy+BSUrVeLajMghvS+2g1JnvknOMNOwEP /C1w== X-Received: by 10.236.191.67 with SMTP id f43mr5696063yhn.60.1392082163050; Mon, 10 Feb 2014 17:29:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.84.65 with HTTP; Mon, 10 Feb 2014 17:28:42 -0800 (PST) In-Reply-To: <2fefcbaf-9417-4f57-93af-490ea73aea98@default> References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> From: Juanma Barranquero Date: Tue, 11 Feb 2014 02:28:42 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -0.7 (/) On Mon, Feb 10, 2014 at 10:16 PM, Drew Adams wrote: > Motion functions are not what is typically meant by a side-effect > function. Why not? Functions intended to move the point are as prototypically side-effect functions as you can get. That goto-char returns POSITION is a moderately useful, but not-at-all necessary commodity. goto-char moving the point as a side effect is its whole raison d'=C3=AAtre. > They do not change the contents of the buffer, for > example, in the sense of `buffer-modified-p'. Why would you restrict the definition of "side effects" to changing the buffer? `recenter' has no documented return value, and does not modify the buffer. Would you deny that it exists to recenter as a side effect? J From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Glenn Morris Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 02:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: 15117@debbugs.gnu.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139208714228941 (code B ref 15117); Tue, 11 Feb 2014 02:53:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 02:52:22 +0000 Received: from localhost ([127.0.0.1]:42219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD3SP-0007Wj-LW for submit@debbugs.gnu.org; Mon, 10 Feb 2014 21:52:21 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:59392 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD3SN-0007Wb-Oh for 15117@debbugs.gnu.org; Mon, 10 Feb 2014 21:52:20 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WD3SM-00075o-Vl; Mon, 10 Feb 2014 21:52:19 -0500 From: Glenn Morris References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> X-Spook: JUWTF SP4 kilderkin lynch FTS2000 Cocaine e-bomb IMF X-Ran: s.!d76_pWD~%D_iB%u1-4Y4n5s?YU#9|uBMNqTRpU{\WoR!GC{9RS1JmgtAW(;Y}LmFqG~ X-Hue: green X-Attribution: GM Date: Mon, 10 Feb 2014 21:52:18 -0500 In-Reply-To: <2fefcbaf-9417-4f57-93af-490ea73aea98@default> (Drew Adams's message of "Mon, 10 Feb 2014 13:16:27 -0800 (PST)") Message-ID: <52ha86l5st.fsf@fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.9 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -4.9 (----) Drew Adams wrote: > You are clearly arguing for the sake of arguing, now. Oh, the irony. >> If other developers disagree with my closing the bug, they can reopen. > I already did disagree. You are not an Emacs developer. To those are who are, I would like to say this: There are more open Emacs issues than we can ever hope to fix. So I suggest being selective about which ones you try to deal with. Getting sucked into long debates about trivia is not a productive use of time. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 04:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Drew Adams Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.13920913257985 (code B ref 15117); Tue, 11 Feb 2014 04:03:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 04:02:05 +0000 Received: from localhost ([127.0.0.1]:42302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD4Xs-00024i-JM for submit@debbugs.gnu.org; Mon, 10 Feb 2014 23:02:04 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:52198) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD4Xq-00024E-E8 for 15117@debbugs.gnu.org; Mon, 10 Feb 2014 23:02:02 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFFpZGC/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLY4uglwDiGGcGYFegmor X-IPAS-Result: Av8EABK/CFFFpZGC/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLY4uglwDiGGcGYFegmor X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="47261265" Received: from 69-165-145-130.dsl.teksavvy.com (HELO pastel.home) ([69.165.145.130]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 Feb 2014 23:01:56 -0500 Received: by pastel.home (Postfix, from userid 20848) id 6DB2A60825; Mon, 10 Feb 2014 23:01:56 -0500 (EST) From: Stefan Monnier Message-ID: References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> Date: Mon, 10 Feb 2014 23:01:56 -0500 In-Reply-To: <2fefcbaf-9417-4f57-93af-490ea73aea98@default> (Drew Adams's message of "Mon, 10 Feb 2014 13:16:27 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: 0.3 (/) >> > These are NOT side-effect functions. They modify nothing except >> > the cursor position. >> How is that not a side-effect? > You are clearly arguing for the sake of arguing, now. Not at all. > Motion functions are not what is typically meant by a side-effect > function. Says you. For me (and most definitions of side-effects I've ever seen), a side-effecting function is something like a function where the calls can't simply be replaced by their return value. Stefan From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 06:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Dmitry Gutov Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen , Stefan Monnier Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139210084227774 (code B ref 15117); Tue, 11 Feb 2014 06:41:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 06:40:42 +0000 Received: from localhost ([127.0.0.1]:42402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD71M-0007Dp-Bh for submit@debbugs.gnu.org; Tue, 11 Feb 2014 01:40:41 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:41612) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD71H-0007DV-2Y for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 01:40:36 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1B6eSXV021583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Feb 2014 06:40:28 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s1B6eQ3B013544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 06:40:28 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1B6eQ1q002066; Tue, 11 Feb 2014 06:40:26 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 10 Feb 2014 22:40:25 -0800 (PST) From: Drew Adams References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <87mwhy4ftl.fsf@yandex.ru> In-Reply-To: <87mwhy4ftl.fsf@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.9 (--) > > Everything in the universe has side effects. Ohhmmmm. It's true. >=20 > You should look up "referential transparency". Perhaps you should give me the benefit of the doubt. I'm actually well aware of referential transparency. That might even have been the case before you uttered your first side-effect cry. ;-) > Please read > http://en.wikipedia.org/wiki/Side_effect_(computer_science) Please spare me the comp-sci lesson. FYI, I was at the Santa Fe graph-reduction workshop in 1986, discussing what would ultimately become Haskell with John Hughes, Phil Wadler, Paul Hudak, and Simon Peyton-Jones. That's only to assure you that I am somewhat at home in this forest. I've been a proponent of purely functional and logic programming for over 30 years. And yet I have also enjoyed programming in nasty old Lisp for the same period. ;-) Go figure. > "function with side effects" is a pretty well-defined term. A > function does not necessarily have to modify an Emacs buffer to > be termed as such. Cough, gag. Yes, indeed. I really did not mean to suggest otherwise. > > By your (newfound) logic, you will presumably remove mention of > > the return value from the doc for those functions. The same > > logic behind documenting their return value applies to these > > other motion functions. >=20 > The logic is simple:=20 So are you arguing that we should not document the return value of those functions either? Meme combat. > if the return value is documented, the caller should be able to > depend on it,=20 Yes, that's the idea. > and "undocumenting" it retroactively isn't an option. As long as > the return value is undocumented, but the function can still be > useful without it, it can stay that way indefinitely. When have you ever seen Emacs Dev worry a lot about changing something, let alone undocumenting a return value retroactively? Let's not exaggerate. Yes, the return value for these simple motion functions should be documented, and thus users should be able to depend on it. That is no more of a constraint on Emacs-Lisp implementors than is letting users depend on the value of `point' when the function is finished. We are not designing a language standard that will be implemented here and there around the world using different teams and different technologies for different purposes for the next 100 years. This is Emacs Lisp, not Common Lisp. Let's not get carried away. And even Common Lisp defines return values for the vast majority of its functions, whether or not they perform side effects. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 06:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Juanma Barranquero Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen , Stefan Monnier Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139210100028046 (code B ref 15117); Tue, 11 Feb 2014 06:44:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 06:43:20 +0000 Received: from localhost ([127.0.0.1]:42411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD73v-0007IH-9b for submit@debbugs.gnu.org; Tue, 11 Feb 2014 01:43:20 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:42496) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD73s-0007I0-B7 for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 01:43:17 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1B6hAkk023958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Feb 2014 06:43:10 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s1B6h9cr018647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 06:43:10 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1B6h95J007454; Tue, 11 Feb 2014 06:43:09 GMT MIME-Version: 1.0 Message-ID: <68a64949-d801-4d09-8dc8-4b6ae0824855@default> Date: Mon, 10 Feb 2014 22:43:08 -0800 (PST) From: Drew Adams References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.9 (--) > > Motion functions are not what is typically meant by a > > side-effect function. In Emacs, in the sense of modifying buffer contents. That was what I meant. No, I was not clear enough. But it doesn't really matter. That is anyway *not* a criterion I use for whether a Lisp function should have a defined and documented return value. My criterion for that is just whether such a value is useful and can be counted on. If so, then I say we should let users know that they can count on it. Simple as that. > Why not? Functions intended to move the point are as prototypically > side-effect functions as you can get. That goto-char returns > POSITION is a moderately useful, but not-at-all necessary commodity. > goto-char moving the point as a side effect is its whole raison d'=C3=AAt= re. Agreed; it is. And the resulting position is thus an important part of its effect. And it is handy to use that value directly. It always has been. There is nothing special about this. And nothing special about `goto-char' or `skip-chars-forward' vs `forward-char'. That's the point. Are you arguing not to document `goto-char's return value, as well? And so to discourage its use? After all, one doesn't need to depend on it - it's certainly enough to depend on the side effect and then call `point' to get the new position. If so, go for it. Then what have you gained? Greater liberty for the implementation to change? Bof. More readable code? Bof. Code that is more functional or side-effect free? Certainly not. > > They do not change the contents of the buffer, for > > example, in the sense of `buffer-modified-p'. >=20 > Why would you restrict the definition of "side effects" to > changing the buffer? I don't, actually. Whether something constitutes a "side effect" is relative. This is what I wrote, which engendered the current excitement: If, for some special (good) reason, code should not rely on the return value of some function, then this fact should be stated explicitly in the doc: "This function is used only for its side effects; the return value is undefined." This is Lisp, not C - return values are the norm, not the exception. I was suggesting boilerplate text similar to what we often write for functions, such as `mapc', where we point out that the return value is not to be relied on. We mention side effects here because if the return value is not to be depended on then what else is there, besides the side effect? Nada. We let users know that side effects are (necessarily) the "whole raison d'=C3=AAtre" in that case. That is precisely what the Common Lisp doc does, for example: call attention to the relatively *few* cases where the return value is *not* to be counted on. Lisps have always tended to provide reasonable return values as a general rule. Regardless, BTW, of whether a given function happens to perform side effects. It is not because a function performs side effects that its return value should not be counted on (and so documented). It is because the return value of a given function should not be counted on that it should not be documented (actually, it should be documented that the return value cannot be counted on). And such functions are therefore used for side effect only. There are certain Common Lisp "functions" for which no return value is documented, and which are _called out as such_, explicitly. (And the doc typically says something like what I said above: Use this for its side effects only; do not count on its return value being anything in particular (it can vary among implementations etc.) Such functions are the exception to the rule - in spite of the fact that most Common Lisp "functions" can have side effects. And such an exception is often for reasons of implementation - in particular, to allow different implementors more freedom of implementation. (Common Lisp, unlike GNU Emacs, is intended to have multiple implementations, including for unforeseen situations and uses.) So really the question has nothing particularly to do with side effects, beyond the concerns just mentioned. I should not have mentioned not-even-modifying-buffer-contents in this context. It's all about what we want for programmers. Should they get a useful return value for the given function or not? That's the only question. Consider `when', for instance. I, for one, adopt the convention often used with Common Lisp of NOT using the return value. Why? To signal the programmer intention that what is happening is for the side effects and not for the return value - i.e., that in that particular context, the return value is not important. IOW, this is to help readers of the code; nothing more. That convention makes sense for `when' and `unless' especially because there are alternatives to signal just the opposite programmer intention: I use `if', `and', or `or' when the return value is significant, precisely to show that, for readability. If you were to argue that we should not document the return value of `when' or `unless' you would get no argument from me. (Well, actually, I would again suggest saying explicitly that one should not count on the return value.) This, in spite of the fact that `if', `and', and `or' can, just like `when' and `unless', be used in code that produces side effects. It's really not about side effects at all. (I find it ironic that some of those who've jumped on this to scream that programmers should not be able to count on the return value of `forward-sexp' nevertheless count on the return value of `when' in the code they write, something I won't do.) So I am not against documenting return values for some, even most, functions that perform side effects, including effects that might modify the buffer, if it can be shown that: (a) there is no special benefit (e.g. wrt implementation or for users) to *not* guaranteeing a known return value for users or (b) there is no particularly useful value to return. In the case of the motion functions, there is a useful value to return: the destination position. And my question about that is "Why not?". I've seen no response to that question, so far. Why not? > `recenter' has no documented return value, and does not > modify the buffer. Would you deny that it exists to recenter > as a side effect? No more than I would deny that `goto-char' or `skip-chars-forward' exists to move point. I don't see why that prohibits providing the new `point' (or perhaps even the starting position) as a useful return value, however. I'm not sure the resulting position is particularly useful in the case of `recenter', but if you proposed returning it and documenting that, I might not object. Why not? I don't have a great reason why not for `recenter' - do you? Let's be clear. No one is proposing that additional side effects be introduced anywhere here! This is not pure-function-vs-procedure. These are all procedures. They move point. The position attained is in most cases a reasonable return value, and costs little or nothing to return. So why not? That's all. It is natural to return a value readily available from the implementation. I would not propose that a definition go out of its way to obtain a useful value to return in such cases. But it seems obvious to me that there is no a priori reason for a simple motion function *not* to return a known value such as the position moved to. I gave several examples of motion functions where we already do that. Why do we? Why shouldn't we? Look at those functions. See if you would really argue that we should not document their return values and let users depend on them. See if you want to shout "side effects!" or some other battle cry as a reason for making such a change. Then tell me what we would gain by that. Just what do we gain by not returning the new position or not telling users that we return it? That's really the only question here. And I haven't heard a single argument about that yet. Forget about whether this or that function performs side effects. Please answer the question of why we should not let users write code that counts on the moved-to position as a return value. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Andreas =?UTF-8?Q?R=C3=B6hler?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 10:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: 15117@debbugs.gnu.org Cc: Stefan Monnier , Drew Adams X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.139211574020702 (code B ref -1); Tue, 11 Feb 2014 10:49:01 +0000 Received: (at submit) by debbugs.gnu.org; 11 Feb 2014 10:49:00 +0000 Received: from localhost ([127.0.0.1]:45784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDAtf-0005Nq-U5 for submit@debbugs.gnu.org; Tue, 11 Feb 2014 05:49:00 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37482) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDAtd-0005Na-Rr for submit@debbugs.gnu.org; Tue, 11 Feb 2014 05:48:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDAtP-0006Hs-5A for submit@debbugs.gnu.org; Tue, 11 Feb 2014 05:48:52 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:52343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDAtP-0006Ho-1V for submit@debbugs.gnu.org; Tue, 11 Feb 2014 05:48:43 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDAtH-0000Lt-N0 for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 05:48:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDAtA-0006E8-Cz for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 05:48:35 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]:60851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDAtA-0006DW-3f for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 05:48:28 -0500 Received: from purzel.sitgens (brln-4d0c6463.pool.mediaWays.net [77.12.100.99]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0LhePx-1VQJOe2Cll-00mors; Tue, 11 Feb 2014 11:48:22 +0100 Message-ID: <52FA00E7.2050108@easy-emacs.de> Date: Tue, 11 Feb 2014 11:52:23 +0100 From: Andreas =?UTF-8?Q?R=C3=B6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:5opES/hN+tFLc9+x09gotIk11oALni45oHlHoPdhnlE KFQLdHF5aPeZtBRQFITNq3bFZe4RF0JMDJhfJZVwXOYlgqkidS fzp/QV9yMKQEMG8DOwfLKG6b012dk1wN9LTbnmxCl+2+DYGNaS sTRj25XaQutoaqKBqpS3/JQCBB12U0o8OCdtXUUbu2NqXwoKzh D1wJmhlMFxBiIDt44hzMShgQ3wT8sKulVU6PE9DFnwQl1rVCM4 70+TMHp53L2oe2Z/G4K71yCcU0CE4CUsZAkUUNbw1a+EmKb2Vx /LWCIZQi/ah0JhOI2r91e+JF0NLungo6A1tuNJVApl/S5BBNml qOyp3kQIbv38jv1E9EqX3m+5Yu/k3LiVBhSGIBnMM X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.0 (-----) Am 11.02.2014 05:01, schrieb Stefan Monnier: >>>> These are NOT side-effect functions. They modify nothing except >>>> the cursor position. >>> How is that not a side-effect? >> You are clearly arguing for the sake of arguing, now. > > Not at all. > >> Motion functions are not what is typically meant by a side-effect >> function. > > Says you. For me (and most definitions of side-effects I've ever seen), > a side-effecting function is something like a function where the calls > can't simply be replaced by their return value. > > Can't see a logic link between a possible return value and the notion of side-effect. It all depends from the purpose of the function. Avoiding side-effects as a goal tries to avoid complexity. While asking for (documented) return-values some times ago, being well aware these might constitute side-effects - but must not. I.e. if a move-function reaches position, the buffer state is changed, but that's not a side effect, as it's the purpose. If this function returns position for possibly receiving functions, would consider it a side-effect. So if avoiding complexity is a goal, delivering a smart language is another one. Not all side-effects are of same severity or same urgence to avoid. Remains to decide. In case of move-functions, being in favor of returning position reached. Documenting return-values is another --quite useful-- thing. Cheers, Andreas From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Nicolas Richard Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 11:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Andreas =?UTF-8?Q?R=C3=B6hler?= Cc: 15117@debbugs.gnu.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139211740423476 (code B ref 15117); Tue, 11 Feb 2014 11:17:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 11:16:44 +0000 Received: from localhost ([127.0.0.1]:45805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDBKV-00066Y-TY for submit@debbugs.gnu.org; Tue, 11 Feb 2014 06:16:44 -0500 Received: from mxin.ulb.ac.be ([164.15.128.112]:25053) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDBKS-00066K-KW for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 06:16:41 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAIAPYF+lKkD4Xx/2dsb2JhbABZg0SDWKRoApZ6gSV0giUBAQQBI1YFCwgDGgIFIQICDwEESROHcAEMCA2oWFOXEwGIPBeBKYZHhlYzB4JvgUkEmCqGMItwgy47 Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 11 Feb 2014 12:16:39 +0100 From: Nicolas Richard References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <52FA00E7.2050108@easy-emacs.de> Date: Tue, 11 Feb 2014 12:16:38 +0100 In-Reply-To: <52FA00E7.2050108@easy-emacs.de> ("Andreas \=\?utf-8\?Q\?R\=C3\=B6h\?\= \=\?utf-8\?Q\?ler\=22's\?\= message of "Tue, 11 Feb 2014 11:52:23 +0100") Message-ID: <87vbwl99wp.fsf@yahoo.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) 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.15 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 (--) Andreas R=C3=B6hler writes: > Am 11.02.2014 05:01, schrieb Stefan Monnier: >> Says you. For me (and most definitions of side-effects I've ever seen), >> a side-effecting function is something like a function where the calls >> can't simply be replaced by their return value. > Can't see a logic link between a possible return value and the notion of = side-effect. > It all depends from the purpose of the function. I guess this is a slight misunderstanding. The notion of side-effect is well defined in CS: =C2=AB a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world. =C2=BB (http://en.wikipedia.org/wiki/Side_effect_%28computer_science%29) The notions of "mostly-unintended effect" (like so: (defun my-point-at-eol (progn (end-of-line) (point)))) or "multi-purpose functions by means of global variables" (e.g. the use of 'org-ts-what in org-at-timestamp-p -- which is kind of scary if I may say) are only special cases of side effects. --=20 Nico. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Andreas =?UTF-8?Q?R=C3=B6hler?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 12:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Nicolas Richard Cc: 15117@debbugs.gnu.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139212038610455 (code B ref 15117); Tue, 11 Feb 2014 12:07:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 12:06:26 +0000 Received: from localhost ([127.0.0.1]:45971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDC6c-0002iY-1h for submit@debbugs.gnu.org; Tue, 11 Feb 2014 07:06:26 -0500 Received: from moutng.kundenserver.de ([212.227.17.9]:57961) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDC6Z-0002iI-L7 for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 07:06:24 -0500 Received: from purzel.sitgens (brln-4d0c6463.pool.mediaWays.net [77.12.100.99]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0MeBeI-1Vpblx3zEU-00PrsZ; Tue, 11 Feb 2014 13:06:16 +0100 Message-ID: <52FA132F.2030906@easy-emacs.de> Date: Tue, 11 Feb 2014 13:10:23 +0100 From: Andreas =?UTF-8?Q?R=C3=B6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <52FA00E7.2050108@easy-emacs.de> <87vbwl99wp.fsf@yahoo.fr> In-Reply-To: <87vbwl99wp.fsf@yahoo.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:+ZjjFn/v4nWcPMreODbEiU6N7CDntqcvHSOTfY6mXDv chVn14eEGhwyBNAv5ZHT/oumbjOq4mkl5XUoTd/+eFwBJBgTG8 wUO7wirJwb6os+jDaviIJtWgTv2qcB7EdeFtkjpyBIoyNfD/ca YnFl0gNgOhEuB7mGKqgb1dCIdlEAngcfUYRnGxtj8B7CCz9jOY sKmyXMIvpg+NwJpP+s3URIg2sJmpGDUhj8Dx3M4mxCRzY9l5Pg ISlakpjOigxMz7/dmF5X+CtpdIp70CpQcC+z/7rgwC3lux1sCs uOIChb6ewLgiiXLVpl3vIjh0fD6TTd6aJIVH3Y2AcHj2RrNapt eomYa/gKItpJYXw+lBT+eIrRXnjEXeHBIjfXziK// X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -0.0 (/) Am 11.02.2014 12:16, schrieb Nicolas Richard: > Andreas Röhler writes: >> Am 11.02.2014 05:01, schrieb Stefan Monnier: >>> Says you. For me (and most definitions of side-effects I've ever seen), >>> a side-effecting function is something like a function where the calls >>> can't simply be replaced by their return value. > >> Can't see a logic link between a possible return value and the notion of side-effect. >> It all depends from the purpose of the function. > > I guess this is a slight misunderstanding. The notion of side-effect is > well defined in CS: « a function or expression is said to have a side > effect if, in addition to returning a value, it also modifies some state > or has an observable interaction with calling functions or the outside > world. » > (http://en.wikipedia.org/wiki/Side_effect_%28computer_science%29) > WP is often good, sometimes bad, sometimes just an agent of CIA, NSA and their satellites. Saying in WP is no proof at all. If you read "in addition to returning a value": functions must not return a value, but might have side-effects > The notions of "mostly-unintended effect" (like so: (defun > my-point-at-eol (progn (end-of-line) (point)))) or "multi-purpose > functions by means of global variables" (e.g. the use of 'org-ts-what in > org-at-timestamp-p -- which is kind of scary if I may say) are only > special cases of side effects. > It's also not about unintended side-effect, also also about intended. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 16:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Drew Adams Cc: 15117@debbugs.gnu.org, lekktu@gmail.com, larsi@gnus.org Reply-To: Eli Zaretskii Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139213633925329 (code B ref 15117); Tue, 11 Feb 2014 16:33:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 16:32:19 +0000 Received: from localhost ([127.0.0.1]:47636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGFr-0006aO-5d for submit@debbugs.gnu.org; Tue, 11 Feb 2014 11:32:19 -0500 Received: from mtaout25.012.net.il ([80.179.55.181]:59921) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDGFk-0006Zw-S8 for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 11:32:12 -0500 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N0U00700B1KCM00@mtaout25.012.net.il> for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 18:31:06 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0U007CWB7U3610@mtaout25.012.net.il>; Tue, 11 Feb 2014 18:31:06 +0200 (IST) Date: Tue, 11 Feb 2014 18:31:50 +0200 From: Eli Zaretskii In-reply-to: <68a64949-d801-4d09-8dc8-4b6ae0824855@default> X-012-Sender: halo1@inter.net.il Message-id: <8361oltxu1.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <68a64949-d801-4d09-8dc8-4b6ae0824855@default> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (+) > Date: Mon, 10 Feb 2014 22:43:08 -0800 (PST) > From: Drew Adams > Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen > > > > Motion functions are not what is typically meant by a > > > side-effect function. > > In Emacs, in the sense of modifying buffer contents. That was > what I meant. No, I was not clear enough. But it doesn't really > matter. That is anyway *not* a criterion I use for whether a Lisp > function should have a defined and documented return value. > > My criterion for that is just whether such a value is useful and > can be counted on. If so, then I say we should let users know that > they can count on it. Simple as that. > > > Why not? Functions intended to move the point are as prototypically > > side-effect functions as you can get. That goto-char returns > > POSITION is a moderately useful, but not-at-all necessary commodity. > > goto-char moving the point as a side effect is its whole raison d'être. > > Agreed; it is. And the resulting position is thus an important part > of its effect. And it is handy to use that value directly. It always > has been. There is nothing special about this. And nothing special > about `goto-char' or `skip-chars-forward' vs `forward-char'. That's > the point. With all due respect to the philosophical argument raging through this thread, it has nothing at all to do with the original bug report. If you (Drew) want that something productive comes out of this, please point out specific forward/backward-* functions that return non-trivial values, and those values are not documented. The only 2 functions mentioned since the beginning of this discussion are forward/backward-sexp, which always return nil, a.k.a. "nothing". I also tried a couple of other random functions, and they seem all to be of this "nothing" kind. So I wonder whether we have any real problem here. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 17:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Eli Zaretskii Cc: 15117@debbugs.gnu.org, lekktu@gmail.com, larsi@gnus.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.13921397784171 (code B ref 15117); Tue, 11 Feb 2014 17:30:03 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 17:29:38 +0000 Received: from localhost ([127.0.0.1]:47740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDH9N-00015C-NC for submit@debbugs.gnu.org; Tue, 11 Feb 2014 12:29:38 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:25565) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDH9L-00014w-2S for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 12:29:35 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1BHTS9j019402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Feb 2014 17:29:28 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1BHTPkC009479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 17:29:26 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1BHTPTo013492; Tue, 11 Feb 2014 17:29:25 GMT MIME-Version: 1.0 Message-ID: <67b917ca-8b69-49fd-9e12-68da310f7567@default> Date: Tue, 11 Feb 2014 09:29:24 -0800 (PST) From: Drew Adams References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <68a64949-d801-4d09-8dc8-4b6ae0824855@default> <8361oltxu1.fsf@gnu.org> In-Reply-To: <8361oltxu1.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.0 (---) > If you (Drew) want that something productive comes out of this, > please point out specific forward/backward-* functions that return > non-trivial values, and those values are not documented. The only 2 > functions mentioned since the beginning of this discussion are > forward/backward-sexp, which always return nil, a.k.a. "nothing". I > also tried a couple of other random functions, and they seem all to > be of this "nothing" kind. So I wonder whether we have any real > problem here. I would like to see functions that are purely motion functions return `point', the destination position, unless there is a more useful return value (as is already the case for a function such as `forward-comment' or `forward-button'). IOW, some useful value is better than none. Note: I have nothing against picking a _more_ useful value than `point'. Point is just a default suggestion. For an example of a more useful value, see `forward-comment': it sets `point' but returns t or nil. And document that return value. Here are some candidates, for a start (likewise, their backward relatives, and other relatives, such as `up-list', `down-list', `backward-up-list'...). forward-char forward-list ; already returns `point' forward-page ; returns count forward-same-syntax forward-sentence forward-sexp forward-symbol forward-thing forward-to-indentation forward-visible-line forward-whitespace forward-word We can look for other motion functions to treat similarly after this start. Assuming there is any will to do this. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 17:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Drew Adams Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen , Stefan Monnier Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.13921402579611 (code B ref 15117); Tue, 11 Feb 2014 17:38:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 17:37:37 +0000 Received: from localhost ([127.0.0.1]:47744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDHH6-0002Uw-1q for submit@debbugs.gnu.org; Tue, 11 Feb 2014 12:37:36 -0500 Received: from mail-yh0-f42.google.com ([209.85.213.42]:57642) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDHH2-0002Ud-NZ for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 12:37:33 -0500 Received: by mail-yh0-f42.google.com with SMTP id a41so7191098yho.29 for <15117@debbugs.gnu.org>; Tue, 11 Feb 2014 09:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=S2k+S5svAbq2Ut2z2C5VpZzmLGuOlTupu5AJBg3DDdo=; b=nvMWgEf0PttldYNGh3wEzSN7tY6wHioYENwct6Km5qaygXsP+FbkgQ1rV/RbzyF18r ps1/+JMGB3wZ4r46L6uY/k19A0OWZHyLAOuR3+PVtm0gJf77UliVvkQpgqi4q6TsCQzP 0Fc8mQVDupXZl6NXl8tWqUSSvwUcmHx0ZA625XsZ/oUQiWpKgwjZRSTEy7lPMnoRV0fq j+eZWBVJ5Qf0bi0DxiL11ocQD7pwR9U7NM6Rbbf6knkST2l1SIvn3p9ausuQ2qnAbXTQ VDBIf3Sftu3slXVY6g/XMOqAqBpcUbdKXUHiIpZT7ISYTsin25RzHDcapX+g/0sgWqMs nCng== X-Received: by 10.236.144.103 with SMTP id m67mr1689677yhj.146.1392140246958; Tue, 11 Feb 2014 09:37:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.84.65 with HTTP; Tue, 11 Feb 2014 09:36:46 -0800 (PST) In-Reply-To: <68a64949-d801-4d09-8dc8-4b6ae0824855@default> References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <68a64949-d801-4d09-8dc8-4b6ae0824855@default> From: Juanma Barranquero Date: Tue, 11 Feb 2014 18:36:46 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -0.7 (/) On Tue, Feb 11, 2014 at 7:43 AM, Drew Adams wrote: > That is anyway *not* a criterion I use for whether a Lisp > function should have a defined and documented return value. The only criteria that make sense IMHO about whether a function should have a defined and documented return value are: - That the return value is useful and non-trivial. - That it is somewhat related to the function's purpose. As an example, goto-char has a documented return value, POSITION, identical to its only argument. I suppose it is so for historical reasons and I'm not proposing to undocument it, but if goto-char were introduced now, I would, because the only thing you gain from it is saving a `let' binding every now and then (perhaps 100 times out of ~12,000 calls to goto-char in the sources). > Agreed; it is. And the resulting position is thus an important part > of its effect. And it is handy to use that value directly. The result of goto-char is NOT "the resulting position". Try (with-temp-buffer (goto-char 1000)) => 1000 or (let ((p (point-marker))) (eq p (goto-char p))) => t The result of goto-char is *its argument*, even if it does not make sense. > Are you arguing not to document `goto-char's return value, as well? > And so to discourage its use? After all, one doesn't need to depend > on it - it's certainly enough to depend on the side effect and then > call `point' to get the new position. As said above, I would, if it were a new function, yes. > If so, go for it. Then what have you gained? Greater liberty > for the implementation to change? Bof. More readable code? Bof. Your "bof" is my "hell, yeah". > Code that is more functional or side-effect free? Certainly not. I wouldn't presume to make a side-effect function side-effect free. That'd be weird ;-) > Whether something constitutes a "side effect" > is relative. I don't think so. > If, for some special (good) reason, code should not rely on the > return value of some function, then this fact should be stated > explicitly in the doc: "This function is used only for its side > effects; the return value is undefined." This is Lisp, not C - > return values are the norm, not the exception. Not documenting a return value is, in fact, a way of saying "this function is used only for its side effects; the return value is undefined". It's just that it is a way of saying it that you dislike, but it has a long history. > It is not because a function performs side effects that its > return value should not be counted on (and so documented). No, it is because it is trivial, or irrelevant, or an accident of implementation. > It's all about what we want for programmers. Should they get > a useful return value for the given function or not? That's > the only question. The answer to that question is already there: some do (return a useful value), some don't. What you're saying instead is that, in your opinion, *most* functions should have its return value documented, because that's more "lispy". But Elisp is not just a lisp, it's the high-level implementation language of a text editor, and as such, there are many functions intended to produce side effects in the text; that they return a value is a consequence of these functions being implemented in lisp, which does not have a concept of not returning anything at all. > Consider `when', for instance. I, for one, adopt the convention > often used with Common Lisp of NOT using the return value. Why? > To signal the programmer intention that what is happening is for > the side effects and not for the return value - i.e., that in > that particular context, the return value is not important. IOW, > this is to help readers of the code; nothing more. I do, too. But in fact, I think that function is an argument for my position, not yours, exactly because of this: > If you were to argue that we should not document the return > value of `when' or `unless' you would get no argument from > me. (Well, actually, I would again suggest saying explicitly > that one should not count on the return value.) Exactly. I would prefer that `when' and `unless' had their return values undefined, and people had to use (if X Y nil) or (if X nil Y). > In the case of the motion functions, there is a useful value > to return: the destination position. And my question about > that is "Why not?". I've seen no response to that question, > so far. Why not? See above. If the function is moving the point in a non trivial way, it makes sense to return the new position. If not, not. There's nothing special about motion functions. > I'm not sure the resulting position is particularly useful in > the case of `recenter', but if you proposed returning it and > documenting that, I might not object. Why not? I don't have > a great reason why not for `recenter' - do you? recenter does not move the point. It could return `point', but, what for? > Look at those functions. See if you would really argue that > we should not document their return values and let users > depend on them. See if you want to shout "side effects!" > or some other battle cry as a reason for making such a change. Drew, I didn't enter the discussion to defend function purity, just to try to understand why did you define obvious side-effects as "no side effects". That said, I do think that in many cases documenting the return value has as a net negative effect in that it does not add value and limits implementation. But there's nothing new there, we've had this discussion before. > Please answer the > question of why we should not let users write code that > counts on the moved-to position as a return value. I think it is a good idea to encourage the users to use functions that return the position as their *main* effect. J From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 18:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Drew Adams Cc: 15117@debbugs.gnu.org, lekktu@gmail.com, larsi@gnus.org Reply-To: Eli Zaretskii Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139214194812702 (code B ref 15117); Tue, 11 Feb 2014 18:06:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 18:05:48 +0000 Received: from localhost ([127.0.0.1]:47772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDHiJ-0003If-OU for submit@debbugs.gnu.org; Tue, 11 Feb 2014 13:05:47 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:33559) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDHiA-0003IC-RG for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 13:05:39 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N0U00A00FEXAB00@mtaout26.012.net.il> for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 20:04:05 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0U009RYFIT0M10@mtaout26.012.net.il>; Tue, 11 Feb 2014 20:04:05 +0200 (IST) Date: Tue, 11 Feb 2014 20:05:15 +0200 From: Eli Zaretskii In-reply-to: <67b917ca-8b69-49fd-9e12-68da310f7567@default> X-012-Sender: halo1@inter.net.il Message-id: <8338jpttic.fsf@gnu.org> References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <68a64949-d801-4d09-8dc8-4b6ae0824855@default> <8361oltxu1.fsf@gnu.org> <67b917ca-8b69-49fd-9e12-68da310f7567@default> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (+) > Date: Tue, 11 Feb 2014 09:29:24 -0800 (PST) > From: Drew Adams > Cc: lekktu@gmail.com, 15117@debbugs.gnu.org, larsi@gnus.org > > I would like to see functions that are purely motion functions > return `point', the destination position, unless there is a more > useful return value (as is already the case for a function such as > `forward-comment' or `forward-button'). That's a different issue: you are asking to change the functions rather than to document what they currently do. Let's stay with the latter. > And document that return value. Here are some candidates, for a > start (likewise, their backward relatives, and other relatives, > such as `up-list', `down-list', `backward-up-list'...). > > forward-char Returns nil, so I don't see what is there to document. > forward-list ; already returns `point' > forward-page ; returns count Returns nil, not count. > forward-same-syntax Returns nil. > forward-sentence > forward-sexp Returns nil. > forward-symbol > forward-thing Always returns t, so not interesting. > forward-to-indentation The value is random, so not interesting > forward-visible-line Always nil. > forward-whitespace > forward-word Value is documented. Looks like only 4 functions of the list return something non-trivial. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 18:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Eli Zaretskii Cc: 15117@debbugs.gnu.org, lekktu@gmail.com, larsi@gnus.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139214248213679 (code B ref 15117); Tue, 11 Feb 2014 18:15:01 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 18:14:42 +0000 Received: from localhost ([127.0.0.1]:47784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDHr0-0003YY-1s for submit@debbugs.gnu.org; Tue, 11 Feb 2014 13:14:42 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:16739) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDHqy-0003YF-Rm for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 13:14:41 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1BIEXoM013163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Feb 2014 18:14:34 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1BIEWEK002275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 18:14:32 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1BIERYP002047; Tue, 11 Feb 2014 18:14:27 GMT MIME-Version: 1.0 Message-ID: <5889df4e-4343-4136-ae49-4062659da625@default> Date: Tue, 11 Feb 2014 10:14:26 -0800 (PST) From: Drew Adams References: <<1dc76f7a-5481-41df-b976-ec22229d7283@default>> <<874n4a42f0.fsf@building.gnus.org>> <<1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default>> <> <<2fefcbaf-9417-4f57-93af-490ea73aea98@default>> <> <<68a64949-d801-4d09-8dc8-4b6ae0824855@default>> <<8361oltxu1.fsf@gnu.org>> <<67b917ca-8b69-49fd-9e12-68da310f7567@default>> <<8338jpttic.fsf@gnu.org>> In-Reply-To: <<8338jpttic.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.0 (---) > Looks like only 4 functions of the list return something non- > trivial. 1. So fix those four functions, as a start. Plus their backward etc. relatives - that brings it to 8 + 3 =3D 11 functions (including *-list). And if you look, you will find others. `forward-*' are not the only motion functions. 2. I guess you want a separate bug report for fixing the other functions themselves, so they return something useful. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 18:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Drew Adams Cc: 15117@debbugs.gnu.org, lekktu@gmail.com, larsi@gnus.org Reply-To: Eli Zaretskii Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139214267314084 (code B ref 15117); Tue, 11 Feb 2014 18:18:01 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 18:17:53 +0000 Received: from localhost ([127.0.0.1]:47789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDHu1-0003ez-I9 for submit@debbugs.gnu.org; Tue, 11 Feb 2014 13:17:53 -0500 Received: from mtaout24.012.net.il ([80.179.55.180]:37463) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDHtv-0003eZ-EN for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 13:17:47 -0500 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N0U00000FROX300@mtaout24.012.net.il> for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 20:16:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0U00I39G3SIA90@mtaout24.012.net.il>; Tue, 11 Feb 2014 20:16:41 +0200 (IST) Date: Tue, 11 Feb 2014 20:17:25 +0200 From: Eli Zaretskii In-reply-to: <5889df4e-4343-4136-ae49-4062659da625@default> X-012-Sender: halo1@inter.net.il Message-id: <831tz9tsy2.fsf@gnu.org> References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <68a64949-d801-4d09-8dc8-4b6ae0824855@default> <8361oltxu1.fsf@gnu.org> <67b917ca-8b69-49fd-9e12-68da310f7567@default> <8338jpttic.fsf@gnu.org> <5889df4e-4343-4136-ae49-4062659da625@default> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (+) > Date: Tue, 11 Feb 2014 10:14:26 -0800 (PST) > From: Drew Adams > Cc: lekktu@gmail.com, 15117@debbugs.gnu.org, larsi@gnus.org > > 2. I guess you want a separate bug report for fixing the other > functions themselves, so they return something useful. It deserves a separate discussion, but I'm not sure their current non-values constitute a bug. There's nothing wrong in returning nil. In any case, each function should be discussed separately, because the fact that the name starts with "forward-" says nothing about possible useful values it could return. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 18:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Eli Zaretskii Cc: 15117@debbugs.gnu.org, lekktu@gmail.com, larsi@gnus.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139214319015057 (code B ref 15117); Tue, 11 Feb 2014 18:27:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 18:26:30 +0000 Received: from localhost ([127.0.0.1]:47806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDI2Q-0003um-7S for submit@debbugs.gnu.org; Tue, 11 Feb 2014 13:26:30 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:43537) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDI2N-0003uW-7Q for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 13:26:28 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1BIQKa0014323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Feb 2014 18:26:21 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1BIQJw2007295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Feb 2014 18:26:19 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1BIQJvc007289; Tue, 11 Feb 2014 18:26:19 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 11 Feb 2014 10:26:18 -0800 (PST) From: Drew Adams References: <<1dc76f7a-5481-41df-b976-ec22229d7283@default>> <<874n4a42f0.fsf@building.gnus.org>> <<1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default>> <> <<2fefcbaf-9417-4f57-93af-490ea73aea98@default>> <> <<68a64949-d801-4d09-8dc8-4b6ae0824855@default>> <<8361oltxu1.fsf@gnu.org>> <<67b917ca-8b69-49fd-9e12-68da310f7567@default>> <<8338jpttic.fsf@gnu.org>> <<5889df4e-4343-4136-ae49-4062659da625@default>> <<831tz9tsy2.fsf@gnu.org>> In-Reply-To: <<831tz9tsy2.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.0 (---) > > 2. I guess you want a separate bug report for fixing the other > > functions themselves, so they return something useful. >=20 > It deserves a separate discussion, but I'm not sure their current > non-values constitute a bug. There's nothing wrong in returning > nil. It's an enhancement request - or it will be: Return a useful value when possible, for motion functions. > In any case, each function should be discussed separately, because > the fact that the name starts with "forward-" says nothing about > possible useful values it could return. The set of candidate functions for enhancement are motion functions. Yes, each needs to be checked in detail. That should not mean that a separate enhancement request is needed for each function. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Andreas =?UTF-8?Q?R=C3=B6hler?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 18:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: 15117@debbugs.gnu.org Cc: Drew Adams X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.139214395916557 (code B ref -1); Tue, 11 Feb 2014 18:40:01 +0000 Received: (at submit) by debbugs.gnu.org; 11 Feb 2014 18:39:19 +0000 Received: from localhost ([127.0.0.1]:47815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDIEp-0004Iw-0C for submit@debbugs.gnu.org; Tue, 11 Feb 2014 13:39:19 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43873) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDIEm-0004Ie-1T for submit@debbugs.gnu.org; Tue, 11 Feb 2014 13:39:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDIEX-0004VS-DJ for submit@debbugs.gnu.org; Tue, 11 Feb 2014 13:39:10 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:50683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDIEX-0004VO-At for submit@debbugs.gnu.org; Tue, 11 Feb 2014 13:39:01 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDIEP-0006Oh-W7 for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 13:39:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDIEI-0004RF-FN for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 13:38:53 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]:51426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDIEI-0004R1-4r for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 13:38:46 -0500 Received: from purzel.sitgens (brln-4d0c6463.pool.mediaWays.net [77.12.100.99]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0Lh6mt-1VRpul2mfP-00oZKb; Tue, 11 Feb 2014 19:38:45 +0100 Message-ID: <52FA6F2C.3010602@easy-emacs.de> Date: Tue, 11 Feb 2014 19:42:52 +0100 From: Andreas =?UTF-8?Q?R=C3=B6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <68a64949-d801-4d09-8dc8-4b6ae0824855@default> <8361oltxu1.fsf@gnu.org> <67b917ca-8b69-49fd-9e12-68da310f7567@default> In-Reply-To: <67b917ca-8b69-49fd-9e12-68da310f7567@default> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:IQ0yu2yGbMfPd+x/lkpxO/fcWg9g4O80gLszuyUNXe/ EQ26EJF5VqVP1POsPWTY0SGpw0E56GgKP3qBqehbhpnhA9Oc3R IgEOgEzIA3YKTWsd8uZacOILtVQGcvqTRwzIqkfG9lAc1AfZEn 09gWTeFXXQoKngYjx6o5M/gJHzCCImbmq9H/oyQiUrk5WtMMrg Dj0/M6v7/EAWzxd1XLja1CvaPqTdpU7TUL7Zz/TBXz5zzVdjjq w2FD618Uge7iDshUTH7naHJXz0tYOI69ELgjEnMONASC6dOmQb 28jzr8DRc3AgI8KbvMSD+QyuH4DzbMDUXrNSZA/6toUmMPyE+c ETltKPOzDbiwBhUGh0zYYkz0Na3S+mwXu6JnfvCwr X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -5.0 (-----) Am 11.02.2014 18:29, schrieb Drew Adams: >> If you (Drew) want that something productive comes out of this, >> please point out specific forward/backward-* functions that return >> non-trivial values, and those values are not documented. The only 2 >> functions mentioned since the beginning of this discussion are >> forward/backward-sexp, which always return nil, a.k.a. "nothing". I >> also tried a couple of other random functions, and they seem all to >> be of this "nothing" kind. So I wonder whether we have any real >> problem here. > > I would like to see functions that are purely motion functions > return `point', the destination position, unless there is a more > useful return value (as is already the case for a function such as > `forward-comment' or `forward-button'). > > IOW, some useful value is better than none. Note: I have nothing > against picking a _more_ useful value than `point'. Point is just > a default suggestion. For an example of a more useful value, see > `forward-comment': it sets `point' but returns t or nil. IMO these functions should return point if successful, i.e. if point was moved, but nil otherwise, for example at EOB. As point --a number-- evals to `t', a respective check might be set upon from receiving function. > > And document that return value. Here are some candidates, for a > start (likewise, their backward relatives, and other relatives, > such as `up-list', `down-list', `backward-up-list'...). > > forward-char > forward-list ; already returns `point' > forward-page ; returns count > forward-same-syntax > forward-sentence > forward-sexp > forward-symbol > forward-thing > forward-to-indentation > forward-visible-line > forward-whitespace > forward-word > > We can look for other motion functions to treat similarly after > this start. Assuming there is any will to do this. > > > > From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 19:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Andreas =?UTF-8?Q?R=C3=B6hler?= Cc: 15117@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139214514623090 (code B ref 15117); Tue, 11 Feb 2014 19:00:02 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 18:59:06 +0000 Received: from localhost ([127.0.0.1]:47831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDIXx-00060M-Fk for submit@debbugs.gnu.org; Tue, 11 Feb 2014 13:59:05 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:47296) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDIXu-0005zn-1e for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 13:59:03 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N0U00B00HQ6EQ00@mtaout28.012.net.il> for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 20:59:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0U00215I3VO6A0@mtaout28.012.net.il>; Tue, 11 Feb 2014 20:59:55 +0200 (IST) Date: Tue, 11 Feb 2014 20:58:43 +0200 From: Eli Zaretskii In-reply-to: <52FA6F2C.3010602@easy-emacs.de> X-012-Sender: halo1@inter.net.il Message-id: <83zjlxscgs.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <68a64949-d801-4d09-8dc8-4b6ae0824855@default> <8361oltxu1.fsf@gnu.org> <67b917ca-8b69-49fd-9e12-68da310f7567@default> <52FA6F2C.3010602@easy-emacs.de> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (+) > Date: Tue, 11 Feb 2014 19:42:52 +0100 > From: Andreas Röhler > > IMO these functions should return point if successful, i.e. if point was moved, but nil otherwise, for example at EOB. Why point? E.g., forward-to-indentation could returns the column where it ended up, forward-same-syntax could return the syntax class, forward-visible-line could return the number of screen lines traversed, etc. Once again, the potentially useful value might well be different for each function, and needs to be considered separately for each. There's no "one fits all" here. From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 19:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Eli Zaretskii , Andreas =?UTF-8?Q?R=C3=B6hler?= Cc: 15117@debbugs.gnu.org Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139214604224756 (code B ref 15117); Tue, 11 Feb 2014 19:15:01 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 19:14:02 +0000 Received: from localhost ([127.0.0.1]:47843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDImP-0006Qw-2k for submit@debbugs.gnu.org; Tue, 11 Feb 2014 14:14:01 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:50649) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDImL-0006QS-2c for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 14:13:58 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1BJDovm021896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Feb 2014 19:13:50 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1BJDmPx006427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 19:13:49 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1BJDmFe028946; Tue, 11 Feb 2014 19:13:48 GMT MIME-Version: 1.0 Message-ID: <342d1809-3109-4629-8599-0b99727a96bd@default> Date: Tue, 11 Feb 2014 11:13:47 -0800 (PST) From: Drew Adams References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <68a64949-d801-4d09-8dc8-4b6ae0824855@default> <8361oltxu1.fsf@gnu.org> <67b917ca-8b69-49fd-9e12-68da310f7567@default> <52FA6F2C.3010602@easy-emacs.de> <83zjlxscgs.fsf@gnu.org> In-Reply-To: <83zjlxscgs.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.0 (---) > > IMO these functions should return point if successful, i.e. if > > point was moved, but nil otherwise, for example at EOB. >=20 > Why point? E.g., forward-to-indentation could returns the column > where it ended up, forward-same-syntax could return the syntax > class, forward-visible-line could return the number of screen lines > traversed, etc. >=20 > Once again, the potentially useful value might well be different for > each function, and needs to be considered separately for each. > There's no "one fits all" here. I agree 100%, and said the same thing earlier. Point is likely a reasonable value for some functions, for which there is no more useful value. But we should think carefully about each function, especially in terms of its common use case(s). From unknown Tue Jun 17 01:43:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Resent-From: Andreas =?UTF-8?Q?R=C3=B6hler?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 19:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix To: Eli Zaretskii Cc: 15117@debbugs.gnu.org, Drew Adams Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139214657625697 (code B ref 15117); Tue, 11 Feb 2014 19:23:01 +0000 Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 19:22:56 +0000 Received: from localhost ([127.0.0.1]:47852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDIuz-0006gL-HN for submit@debbugs.gnu.org; Tue, 11 Feb 2014 14:22:55 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]:59854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WDIuu-0006g0-7L for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 14:22:49 -0500 Received: from purzel.sitgens (brln-4d0c6463.pool.mediaWays.net [77.12.100.99]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0M1XmT-1VKdxp3fLd-00tXIN; Tue, 11 Feb 2014 20:22:41 +0100 Message-ID: <52FA7978.7070007@easy-emacs.de> Date: Tue, 11 Feb 2014 20:26:48 +0100 From: Andreas =?UTF-8?Q?R=C3=B6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <68a64949-d801-4d09-8dc8-4b6ae0824855@default> <8361oltxu1.fsf@gnu.org> <67b917ca-8b69-49fd-9e12-68da310f7567@default> <52FA6F2C.3010602@easy-emacs.de> <83zjlxscgs.fsf@gnu.org> In-Reply-To: <83zjlxscgs.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:K7o08xZ3RGiTRAtG8r24yXuRDLWB9tBCpSioywP47ZV 6ypKeCzCaACf/Sx/kvVaQgOnD/q+2+l5vHMS/PRX83h8NN0F+k pkgkPJr9tVN/yllp3uH+KQjhBEcYJ97snoVTQoK4pPOqOWbhwf WWbHX4FaIa7Y6dwQqrJ1OKhD8UWj4VwuUxYuRHy6lqPm+yDAd0 EwUBN56stA0ud3gWmYkclU2bzOzcPKkvfKwtkEZMeMuXmkHGWY YuSh9tmUfJun/PKVfDyPgsr/beA3UpJ8SmjqPPnmIFGbAtGu4h 0ExG2lzcc1b636GNghGJvGw7kDl4ftzNX1FzKta39mBoYxq7zX 0atuwwAEqEL9LgSviXq1odTuWQYazuWnUQw1OfQQ4 X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -0.0 (/) Am 11.02.2014 19:58, schrieb Eli Zaretskii: >> Date: Tue, 11 Feb 2014 19:42:52 +0100 >> From: Andreas Röhler >> >> IMO these functions should return point if successful, i.e. if point was moved, but nil otherwise, for example at EOB. > > Why point? E.g., forward-to-indentation could returns the column > where it ended up, forward-same-syntax could return the syntax class, > forward-visible-line could return the number of screen lines > traversed, etc. > > Once again, the potentially useful value might well be different for > each function, and needs to be considered separately for each. > There's no "one fits all" here. > > Agreed. Saying "these" was a way too general.