From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vivek Dasmohapatra Newsgroups: gmane.emacs.bugs Subject: bug#20587: 24.1 forward-line docs inconsistent/surprising return value Date: Sat, 23 May 2015 03:50:10 +0100 (BST) Message-ID: References: <83d221gfsn.fsf@gnu.org> <83y4kofy7p.fsf@gnu.org> <83vbfsfvtw.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-263827489-1432349416=:18547" X-Trace: ger.gmane.org 1432349484 12358 80.91.229.3 (23 May 2015 02:51:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 May 2015 02:51:24 +0000 (UTC) Cc: 20587@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 23 04:51:16 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YvzWt-0003vr-AA for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 May 2015 04:51:15 +0200 Original-Received: from localhost ([::1]:36638 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvzWs-0000OD-J1 for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 May 2015 22:51:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvzWl-0000O4-VF for bug-gnu-emacs@gnu.org; Fri, 22 May 2015 22:51:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvzWh-0004KB-8C for bug-gnu-emacs@gnu.org; Fri, 22 May 2015 22:51:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvzWh-0004K3-53 for bug-gnu-emacs@gnu.org; Fri, 22 May 2015 22:51:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YvzWg-000281-Ms for bug-gnu-emacs@gnu.org; Fri, 22 May 2015 22:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Vivek Dasmohapatra Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 May 2015 02:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20587 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20587-submit@debbugs.gnu.org id=B20587.14323494448153 (code B ref 20587); Sat, 23 May 2015 02:51:02 +0000 Original-Received: (at 20587) by debbugs.gnu.org; 23 May 2015 02:50:44 +0000 Original-Received: from localhost ([127.0.0.1]:53374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YvzWI-00027L-Ni for submit@debbugs.gnu.org; Fri, 22 May 2015 22:50:43 -0400 Original-Received: from ceres.etla.org ([85.119.82.193]:60266) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YvzWB-000278-S0 for 20587@debbugs.gnu.org; Fri, 22 May 2015 22:50:37 -0400 Original-Received: from [2a01:4f8:201:6f00::2001] by ceres.etla.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YvzVw-0006iT-8x; Sat, 23 May 2015 03:50:28 +0100 X-X-Sender: vivek@platypus.pepperfish.net In-Reply-To: <83vbfsfvtw.fsf@gnu.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam_report: Spam detection software, running on the system "ceres.etla.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > With positive N, a non-empty line at the end counts as one line > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > successfully moved (for the return value). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > If those 2 sentences don't describe the situation with a buffer that > ends in a line without a newline, then what is missing or unclear > here, in your opinion? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- --------------------- X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:103075 Archived-At: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-263827489-1432349416=:18547 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > With positive N, a non-empty line at the end counts as one line > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > successfully moved (for the return value). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > If those 2 sentences don't describe the situation with a buffer that > ends in a line without a newline, then what is missing or unclear > here, in your opinion? What is unclear or misleading is, imo, the following: - The docstring begins by defining moving forward 1 line as moving to the start of the next line. - It then states that the function will return the number of lines left to move (compared to what the user requested) - It states that failing to move the requested number of lines is not an error. So far, so good. However, it then says, as a sparse footnote: “With positive N, a non-empty line at the end counts as one line” So we have a problem of description: “a non-empty line at the end counts as one line” is being used to mean “a partial final line counts as a whole line”. I think this is obscure, and its meaning is only evident in hindsight, having used the function and discovered that forward-line returns its complete-success value (0) even when it has not moved forward a line (per its own definition). I also happen to think the behaviour is not sensible: If I ask to move forward 1 (complete) line and this canot be satisfied, the function should return 1, as there is still 1 line left to move (but I acknowledge that this is an old function and many things use it, and this may not be a safe change). --8323329-263827489-1432349416=:18547--