From unknown Wed Jun 25 00:21:49 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#17511 <17511@debbugs.gnu.org> To: bug#17511 <17511@debbugs.gnu.org> Subject: Status: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear Reply-To: bug#17511 <17511@debbugs.gnu.org> Date: Wed, 25 Jun 2025 07:21:49 +0000 retitle 17511 24.4.50; `line-move-ignore-invisible': doc and purpose not cl= ear reassign 17511 emacs submitter 17511 Drew Adams severity 17511 minor thanks From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 16:53:40 2014 Received: (at submit) by debbugs.gnu.org; 16 May 2014 20:53:41 +0000 Received: from localhost ([127.0.0.1]:37703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlP8O-0007L4-9m for submit@debbugs.gnu.org; Fri, 16 May 2014 16:53:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45850) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlP8L-0007Km-Ls for submit@debbugs.gnu.org; Fri, 16 May 2014 16:53:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlP86-0006Sh-0x for submit@debbugs.gnu.org; Fri, 16 May 2014 16:53:32 -0400 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_20 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:44343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlP85-0006Sd-V0 for submit@debbugs.gnu.org; Fri, 16 May 2014 16:53:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlP7x-000055-6o for bug-gnu-emacs@gnu.org; Fri, 16 May 2014 16:53:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlP7o-0006P4-9Y for bug-gnu-emacs@gnu.org; Fri, 16 May 2014 16:53:13 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:24816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlP7o-0006Op-2o for bug-gnu-emacs@gnu.org; Fri, 16 May 2014 16:53:04 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4GKr1w7001380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 May 2014 20:53:02 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4GKr18W022051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 May 2014 20:53:01 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s4GKqxKt026112 for ; Fri, 16 May 2014 20:53:00 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 16 May 2014 13:52:58 -0700 (PDT) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.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-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: -4.0 (----) X-Debbugs-Envelope-To: submit 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.0 (----) 1. The doc string says only that `next-line' and `previous-line' ignore invisible lines. What does it mean for these commands to "ignore invisible lines" - what does "ignore" mean here? What's the user-visible BEHAVIOR difference between a nil and a non-nil value? Why/when might a user change the value to nil? 2. The doc string speaks of invisible lines. But (elisp) `Invisible Text' speaks of "invisible newlines" (not lines), which is presumably something different (newline chars vs lines of any chars except newline, possibly including the separating newlines). Are both true? Which? 3 The manual speaks of "the user-level line motion commands", not just `next-line' and `previous-line'. Is there a difference? What other commands are involved here, besides those two? 4. This Elisp manual node is not very clear in general. Again, what does it mean for these line commands to ignore invisible newlines? Or, for that matter, for them to "not care whether the text is invisible"? What user-visible BEHAVIOR difference is there? 5. After saying that we provide option `line-move-ignore-invisible' specifically to let you prevent line motion commands from ignoring invisible newlines (whatever that might mean!), this node says that if ANY command ends with point in a certain position relative to invisible text, then the cursor is automatically moved past that stretch of invisible text (one direction or the other). How is this related to the previous text about line motion commands and `line-move-ignore-invisible'? If a user ends up understanding something coherent and useful from this text, s?he is lucky indeed. In GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-04-29 on ODIEONE Bzr revision: 117031 monnier@iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut= 08 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=3D/c/Devel/emacs/snapshot/trunk --enable-checking=3Dyes,glyphs 'CFLAGS=3D-O0 -g3' LDFLAGS=3D-Lc:/Devel/emacs/lib 'CPPFLAGS=3D-DGC_MCHECK=3D1 -Ic:/Devel/emacs/include'' From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 05:00:19 2014 Received: (at 17511) by debbugs.gnu.org; 17 May 2014 09:00:19 +0000 Received: from localhost ([127.0.0.1]:51146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlaTa-0006tD-Tl for submit@debbugs.gnu.org; Sat, 17 May 2014 05:00:19 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:50590) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlaTW-0006rz-Ks for 17511@debbugs.gnu.org; Sat, 17 May 2014 05:00:16 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N5P00J00MQ02H00@mtaout24.012.net.il> for 17511@debbugs.gnu.org; Sat, 17 May 2014 11:57:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N5P00EWANJESK70@mtaout24.012.net.il>; Sat, 17 May 2014 11:57:14 +0300 (IDT) Date: Sat, 17 May 2014 12:00:11 +0300 From: Eli Zaretskii Subject: Re: bug#17511: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83iop4eq5h.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17511 Cc: 17511@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: Fri, 16 May 2014 13:52:58 -0700 (PDT) > From: Drew Adams > > 1. The doc string says only that `next-line' and `previous-line' ignore > invisible lines. What does it mean for these commands to "ignore > invisible lines" - what does "ignore" mean here? What's the > user-visible BEHAVIOR difference between a nil and a non-nil value? > Why/when might a user change the value to nil? I changed the doc string to this: "Non-nil means commands that move by lines ignore invisible newlines. When this option is non-nil, \\[next-line], \\[previous-line], \\[move-end-of-line], and \\[move-beginning-of-line] behave as if newlines that are invisible didn't exist, and count only visible newlines. Thus, moving across across 2 newlines one of which is invisible will be counted as a one-line move. Also, a non-nil value causes invisible text to be ignored when counting columns for the purposes of keeping point in the same column by \\[next-line] and \\[previous-line]. Outline mode sets this." I hope this answers all of your questions in #1. > 2. The doc string speaks of invisible lines. But (elisp) `Invisible > Text' speaks of "invisible newlines" (not lines), which is presumably > something different (newline chars vs lines of any chars except newline, > possibly including the separating newlines). Are both true? Which? I think the doc string now clarifies this as well. > 3 The manual speaks of "the user-level line motion commands", not just > `next-line' and `previous-line'. Is there a difference? What other > commands are involved here, besides those two? Again, I believe the doc string now clarifies that. > 4. This Elisp manual node is not very clear in general. Again, what > does it mean for these line commands to ignore invisible newlines? Or, > for that matter, for them to "not care whether the text is invisible"? > What user-visible BEHAVIOR difference is there? I clarified in that paragraph that "ignoring" invisible text means behaving as if it didn't exist in the buffer. This implies that an invisible newline does not count as a newline, so when invisible text is ignored, such a line is considered to be part of the next line. IOW, commands that count lines will not count a line whose newline is invisible, when this option is non-nil, so, e.g., "C-u 10 C-n" will not decrement its counter when it moves across an invisible newline. > 5. After saying that we provide option `line-move-ignore-invisible' > specifically to let you prevent line motion commands from ignoring > invisible newlines (whatever that might mean!), this node says that if > ANY command ends with point in a certain position relative to invisible > text, then the cursor is automatically moved past that stretch of > invisible text (one direction or the other). How is this related to the > previous text about line motion commands and > `line-move-ignore-invisible'? It isn't related to line-move-ignore-invisible. It is related to the broader issue described by that node, which is invisible text in general. > If a user ends up understanding something coherent and useful from this > text, s?he is lucky indeed. Unhelpful comment, I wish you'd stop making them. From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 10:45:57 2014 Received: (at 17511) by debbugs.gnu.org; 17 May 2014 14:45:58 +0000 Received: from localhost ([127.0.0.1]:51545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlfs4-0001vW-RC for submit@debbugs.gnu.org; Sat, 17 May 2014 10:45:57 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:30616) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlfs1-0001v5-PE for 17511@debbugs.gnu.org; Sat, 17 May 2014 10:45:54 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4HEjlkh016238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 May 2014 14:45:47 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 s4HEjklF019436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 17 May 2014 14:45:46 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4HEjjvq019420; Sat, 17 May 2014 14:45:46 GMT MIME-Version: 1.0 Message-ID: <8c772b14-20d1-4e3a-9936-f81936c3d31b@default> Date: Sat, 17 May 2014 07:45:44 -0700 (PDT) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#17511: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear References: <> <<83iop4eq5h.fsf@gnu.org>> In-Reply-To: <<83iop4eq5h.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.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-Debbugs-Envelope-To: 17511 Cc: 17511@debbugs.gnu.org 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 (---) Thanks for improving this. > > 1. The doc string says only that `next-line' and `previous-line' ignore > > invisible lines. What does it mean for these commands to "ignore > > invisible lines" - what does "ignore" mean here? What's the > > user-visible BEHAVIOR difference between a nil and a non-nil value? > > Why/when might a user change the value to nil? >=20 > I changed the doc string to this: >=20 > "Non-nil means commands that move by lines ignore invisible newlines. > > When this option is non-nil, \\[next-line], \\[previous-line], \\[move-en= d- > of-line], and \\[move-beginning-of-line] behave > as if newlines that are invisible didn't exist, and count > only visible newlines. Thus, moving across across 2 newlines > one of which is invisible will be counted as a one-line move. > Also, a non-nil value causes invisible text to be ignored when > counting columns for the purposes of keeping point in the same > column by \\[next-line] and \\[previous-line]. >=20 > Outline mode sets this." >=20 > I hope this answers all of your questions in #1. Very good; thanks. (I don't think there should be a blank line after the first line, but maybe that is just a mail artifact.) > > 2. The doc string speaks of invisible lines. But (elisp) `Invisible > > Text' speaks of "invisible newlines" (not lines), which is presumably > > something different (newline chars vs lines of any chars except newline= , > > possibly including the separating newlines). Are both true? Which? >=20 > I think the doc string now clarifies this as well. Yes, thanks. But the manual speaks only of invisible newlines, and to me this part is not clear. And whenever we speak of newlines (especially where we are also talking about doing something wrt lines in general), we should say "newline characters" or "newline chars". A "newline" as such doesn't really exist in our vocabulary (or at least it shouldn't), and some people might read it as meaning a "new line". > > 3 The manual speaks of "the user-level line motion commands", not just > > `next-line' and `previous-line'. Is there a difference? What other > > commands are involved here, besides those two? >=20 > Again, I believe the doc string now clarifies that. OK. > > 4. This Elisp manual node is not very clear in general. Again, what > > does it mean for these line commands to ignore invisible newlines? Or, > > for that matter, for them to "not care whether the text is invisible"? > > What user-visible BEHAVIOR difference is there? >=20 > I clarified in that paragraph that "ignoring" invisible text means > behaving as if it didn't exist in the buffer. This implies that an > invisible newline does not count as a newline, so when invisible text > is ignored, such a line is considered to be part of the next line. > IOW, commands that count lines will not count a line whose newline is > invisible, when this option is non-nil, so, e.g., "C-u 10 C-n" will > not decrement its counter when it moves across an invisible newline. Very good (modulo newline -> newline char). > > 5. After saying that we provide option `line-move-ignore-invisible' > > specifically to let you prevent line motion commands from ignoring > > invisible newlines (whatever that might mean!), this node says that if > > ANY command ends with point in a certain position relative to invisible > > text, then the cursor is automatically moved past that stretch of > > invisible text (one direction or the other). How is this related to th= e > > previous text about line motion commands and > > `line-move-ignore-invisible'? >=20 > It isn't related to line-move-ignore-invisible. It is related to the > broader issue described by that node, which is invisible text in > general. Yes, I sensed that. I found (find) the juxtaposition confusing. Maybe separate the two discussions better, and perhaps give an example of interaction (or lack thereof) between the two. From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 11:02:49 2014 Received: (at 17511) by debbugs.gnu.org; 17 May 2014 15:02:49 +0000 Received: from localhost ([127.0.0.1]:51555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlg8L-0002US-ER for submit@debbugs.gnu.org; Sat, 17 May 2014 11:02:49 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:49249) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlg8E-0002U3-Ly for 17511@debbugs.gnu.org; Sat, 17 May 2014 11:02:43 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N5Q001003WDAK00@a-mtaout22.012.net.il> for 17511@debbugs.gnu.org; Sat, 17 May 2014 18:02:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N5Q000EO4G6PP90@a-mtaout22.012.net.il>; Sat, 17 May 2014 18:02:31 +0300 (IDT) Date: Sat, 17 May 2014 18:02:30 +0300 From: Eli Zaretskii Subject: Re: bug#17511: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear In-reply-to: <8c772b14-20d1-4e3a-9936-f81936c3d31b@default> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83a9age9dl.fsf@gnu.org> References: <8c772b14-20d1-4e3a-9936-f81936c3d31b@default> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17511 Cc: 17511@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: Sat, 17 May 2014 07:45:44 -0700 (PDT) > From: Drew Adams > Cc: 17511@debbugs.gnu.org > > Thanks for improving this. Can this bug be closed, then? > > > 1. The doc string says only that `next-line' and `previous-line' ignore > > > invisible lines. What does it mean for these commands to "ignore > > > invisible lines" - what does "ignore" mean here? What's the > > > user-visible BEHAVIOR difference between a nil and a non-nil value? > > > Why/when might a user change the value to nil? > > > > I changed the doc string to this: > > > > "Non-nil means commands that move by lines ignore invisible newlines. > > > > When this option is non-nil, \\[next-line], \\[previous-line], \\[move-end- > > of-line], and \\[move-beginning-of-line] behave > > as if newlines that are invisible didn't exist, and count > > only visible newlines. Thus, moving across across 2 newlines > > one of which is invisible will be counted as a one-line move. > > Also, a non-nil value causes invisible text to be ignored when > > counting columns for the purposes of keeping point in the same > > column by \\[next-line] and \\[previous-line]. > > > > Outline mode sets this." > > > > I hope this answers all of your questions in #1. > > Very good; thanks. > (I don't think there should be a blank line after the first line, > but maybe that is just a mail artifact.) It's not; it's a standard formatting of a doc string, AFAIK. > > > 2. The doc string speaks of invisible lines. But (elisp) `Invisible > > > Text' speaks of "invisible newlines" (not lines), which is presumably > > > something different (newline chars vs lines of any chars except newline, > > > possibly including the separating newlines). Are both true? Which? > > > > I think the doc string now clarifies this as well. > > Yes, thanks. But the manual speaks only of invisible newlines, and to > me this part is not clear. The doc string now speaks about that as well. What's not clear about that? A newline is just a character, and as such can be invisible. > And whenever we speak of newlines (especially > where we are also talking about doing something wrt lines in general), > we should say "newline characters" or "newline chars". A "newline" as > such doesn't really exist in our vocabulary (or at least it shouldn't), > and some people might read it as meaning a "new line". I'd never suspect this could be a source of confusion in Emacs. The Glossary says: Newline Control-J characters in the buffer terminate lines of text and are therefore also called newlines. > > > 5. After saying that we provide option `line-move-ignore-invisible' > > > specifically to let you prevent line motion commands from ignoring > > > invisible newlines (whatever that might mean!), this node says that if > > > ANY command ends with point in a certain position relative to invisible > > > text, then the cursor is automatically moved past that stretch of > > > invisible text (one direction or the other). How is this related to the > > > previous text about line motion commands and > > > `line-move-ignore-invisible'? > > > > It isn't related to line-move-ignore-invisible. It is related to the > > broader issue described by that node, which is invisible text in > > general. > > Yes, I sensed that. I found (find) the juxtaposition confusing. > Maybe separate the two discussions better, and perhaps give an example > of interaction (or lack thereof) between the two. It's a separate paragraph already, and I removed the leading "However", which might hint on some too tight relation. From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 12:03:21 2014 Received: (at 17511) by debbugs.gnu.org; 17 May 2014 16:03:21 +0000 Received: from localhost ([127.0.0.1]:51572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlh4y-0004Jd-Fk for submit@debbugs.gnu.org; Sat, 17 May 2014 12:03:21 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:39367) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlh4v-0004JN-IC for 17511@debbugs.gnu.org; Sat, 17 May 2014 12:03:18 -0400 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 s4HG39vo028670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 May 2014 16:03:10 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 s4HG389e009555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 May 2014 16:03:09 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4HG38wA009774; Sat, 17 May 2014 16:03:08 GMT MIME-Version: 1.0 Message-ID: <547b37b1-f55b-45e9-8c89-eb9388580d36@default> Date: Sat, 17 May 2014 09:03:06 -0700 (PDT) From: Drew Adams To: Eli Zaretskii , Drew Adams Subject: RE: bug#17511: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear References: <<8c772b14-20d1-4e3a-9936-f81936c3d31b@default>> <<83a9age9dl.fsf@gnu.org>> In-Reply-To: <<83a9age9dl.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.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-Debbugs-Envelope-To: 17511 Cc: 17511@debbugs.gnu.org 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 (---) > > Thanks for improving this. >=20 > Can this bug be closed, then? It's up to you. I have some comments below, but you are of course free to ignore them or disagree with them. > > (I don't think there should be a blank line after the first line, > > but maybe that is just a mail artifact.) >=20 > It's not; it's a standard formatting of a doc string, AFAIK. I don't think so. Perhaps I've been operating under a misconception all these years. For Lisp code I've seen such a blank line only occasionally (rarely), and nearly always in 3rd-party code and typically from newbies. Take a look at the Emacs Lisp sources. You will see such a blank line only rarely. Look at simple.el, for example. There are only a few doc strings that have such a blank line. I count only these 17 out of the *hundreds* of doc strings in simple.el: `next-error-buffer-p', `next-error-find-buffer', `next-error', `previous-error', `shell-command-history', `async-shell-command', `process-file-side-effects', `start-file-process', `mark', `region-active-p', `shift-select-mode', `default-line-height', `window-screen-lines', `set-variable-value-history', `create-indirect-buffer', `normal-erase-is-backspace', `define-alternatives'. I thought that not adding a blank line after the first line was a doc-string convention/guideline/standard (the opposite of what you say), in addition to reflecting the overwhelming practice. But I do not see it mentioned at (elisp) `Documentation Tips', so I guess I was wrong about that (as are you?). (I do see mention of the first paragraph being used for disabled command help, but is not so important here.) So take my input on this as just one opinion. I don't see that adding a blank line after the first helps users - in *Help* output, for example. But clearly it is not proscribed, and there is not even a published guideline against it. > > > > 2. The doc string speaks of invisible lines. But (elisp) `Invisibl= e > > > > Text' speaks of "invisible newlines" (not lines), which is presumab= ly > > > > something different (newline chars vs lines of any chars except > > > > newline, possibly including the separating newlines). Are both tru= e? > > > > Which? > > > > > > I think the doc string now clarifies this as well. > > > > Yes, thanks. But the manual speaks only of invisible newlines, and to > > me this part is not clear. >=20 > The doc string now speaks about that as well. What's not clear about > that? A newline is just a character, and as such can be invisible. I told you it was not clear to me, as one reader. Previously, the doc string spoke only of invisible lines, and the manual spoke only of invisible newlines. The doc string now mentions invisible newline chars too - good. Does the manual mention invisible lines of text? If the fact that I found this confusing helps you improve it, fine. If not, fine. > > And whenever we speak of newlines (especially > > where we are also talking about doing something wrt lines in general), > > we should say "newline characters" or "newline chars". A "newline" as > > such doesn't really exist in our vocabulary (or at least it shouldn't), > > and some people might read it as meaning a "new line". >=20 > I'd never suspect this could be a source of confusion in Emacs. The > Glossary says: >=20 > Newline > Control-J characters in the buffer terminate lines of text and are > therefore also called newlines. OK. I disagree that that is the right approach, but it is the approach taken, so fine. If it were I, I would always say "newline char", to be clear. > > Yes, I sensed that. I found (find) the juxtaposition confusing. > > Maybe separate the two discussions better, and perhaps give an example > > of interaction (or lack thereof) between the two. >=20 > It's a separate paragraph already, and I removed the leading > "However", which might hint on some too tight relation. I'm sure it's better. If you find it clear enough in this respect now, that's good enough for me. Feel free to close. From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 12:11:56 2014 Received: (at 17511) by debbugs.gnu.org; 17 May 2014 16:11:56 +0000 Received: from localhost ([127.0.0.1]:51580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlhDE-0004Wy-7G for submit@debbugs.gnu.org; Sat, 17 May 2014 12:11:56 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:50497) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlhD7-0004Wb-Dd for 17511@debbugs.gnu.org; Sat, 17 May 2014 12:11:49 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N5Q00A006UGBR00@mtaout25.012.net.il> for 17511@debbugs.gnu.org; Sat, 17 May 2014 19:08:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N5Q008US7IFRJ40@mtaout25.012.net.il>; Sat, 17 May 2014 19:08:40 +0300 (IDT) Date: Sat, 17 May 2014 19:11:38 +0300 From: Eli Zaretskii Subject: Re: bug#17511: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear In-reply-to: <547b37b1-f55b-45e9-8c89-eb9388580d36@default> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <8361l4e66d.fsf@gnu.org> References: <8c772b14-20d1-4e3a-9936-f81936c3d31b@default> <83a9age9dl.fsf@gnu.org> <547b37b1-f55b-45e9-8c89-eb9388580d36@default> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17511 Cc: 17511@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: Sat, 17 May 2014 09:03:06 -0700 (PDT) > From: Drew Adams > Cc: 17511@debbugs.gnu.org > > > > (I don't think there should be a blank line after the first line, > > > but maybe that is just a mail artifact.) > > > > It's not; it's a standard formatting of a doc string, AFAIK. > > I don't think so. Perhaps I've been operating under a misconception > all these years. For Lisp code I've seen such a blank line only > occasionally (rarely), and nearly always in 3rd-party code and typically > from newbies. OK, I removed the empty line. > > > > > 2. The doc string speaks of invisible lines. But (elisp) `Invisible > > > > > Text' speaks of "invisible newlines" (not lines), which is presumably > > > > > something different (newline chars vs lines of any chars except > > > > > newline, possibly including the separating newlines). Are both true? > > > > > Which? > > > > > > > > I think the doc string now clarifies this as well. > > > > > > Yes, thanks. But the manual speaks only of invisible newlines, and to > > > me this part is not clear. > > > > The doc string now speaks about that as well. What's not clear about > > that? A newline is just a character, and as such can be invisible. > > I told you it was not clear to me, as one reader. Previously, the doc > string spoke only of invisible lines, and the manual spoke only of > invisible newlines. The doc string now mentions invisible newline > chars too - good. Does the manual mention invisible lines of text? I see no reason to mention invisible lines, because that might be confusing: what matters are not the lines, but the newlines. Therefore, the doc string now only talks about newlines, and the manual now says: Ordinarily, functions that operate on text or move point do not care whether the text is invisible, they process invisible characters and visible characters alike. The user-level line motion commands, such as @code{next-line}, @code{previous-line}, ignore invisible newlines if @code{line-move-ignore-invisible} is non-@code{nil} (the default), i.e., behave like these invisible newlines didn't exist in the buffer, but only because they are explicitly programmed to do so. > > > Yes, I sensed that. I found (find) the juxtaposition confusing. > > > Maybe separate the two discussions better, and perhaps give an example > > > of interaction (or lack thereof) between the two. > > > > It's a separate paragraph already, and I removed the leading > > "However", which might hint on some too tight relation. > > I'm sure it's better. If you find it clear enough in this respect now, > that's good enough for me. Feel free to file another bug report if you find the new text in the manual still confusing about the relation between line-move-ignore-invisible and point adjustments. From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 12:24:35 2014 Received: (at 17511) by debbugs.gnu.org; 17 May 2014 16:24:35 +0000 Received: from localhost ([127.0.0.1]:51589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlhPW-0004qz-Jp for submit@debbugs.gnu.org; Sat, 17 May 2014 12:24:34 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:51989) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlhPU-0004qj-Dm for 17511@debbugs.gnu.org; Sat, 17 May 2014 12:24:33 -0400 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 s4HGOPW3015709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 May 2014 16:24:26 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4HGOPmj004713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 May 2014 16:24:25 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4HGOOQt004708; Sat, 17 May 2014 16:24:25 GMT MIME-Version: 1.0 Message-ID: <01ef3dd7-c4a9-4e37-be97-ecd4b73d7436@default> Date: Sat, 17 May 2014 09:24:23 -0700 (PDT) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#17511: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear References: <<8c772b14-20d1-4e3a-9936-f81936c3d31b@default>> <<83a9age9dl.fsf@gnu.org>> <<547b37b1-f55b-45e9-8c89-eb9388580d36@default>> <<8361l4e66d.fsf@gnu.org>> In-Reply-To: <<8361l4e66d.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.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: -3.0 (---) X-Debbugs-Envelope-To: 17511 Cc: 17511@debbugs.gnu.org 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 (---) > OK, I removed the empty line. Thx. Maybe it would be good to decide on the convention to use and document it in the guidelines. Just a suggestion. > I see no reason to mention invisible lines, because that might be > confusing: what matters are not the lines, but the newlines. > Therefore, the doc string now only talks about newlines, and the > manual now says: >=20 > Ordinarily, functions that operate on text or move point do not care > whether the text is invisible, they process invisible characters and > visible characters alike. The user-level line motion commands, > such as @code{next-line}, @code{previous-line}, ignore invisible > newlines if @code{line-move-ignore-invisible} is non-@code{nil} (the > default), i.e., behave like these invisible newlines didn't exist in > the buffer, but only because they are explicitly programmed to do so. Looks good. I will close the bug. From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 12:25:44 2014 Received: (at control) by debbugs.gnu.org; 17 May 2014 16:25:44 +0000 Received: from localhost ([127.0.0.1]:51593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlhQd-0004t5-34 for submit@debbugs.gnu.org; Sat, 17 May 2014 12:25:43 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:41693) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlhQa-0004so-3u for control@debbugs.gnu.org; Sat, 17 May 2014 12:25:41 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4HGPX2e008875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 May 2014 16:25:34 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 s4HGPWxB006533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 17 May 2014 16:25:33 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4HGPW3a002415 for ; Sat, 17 May 2014 16:25:32 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 17 May 2014 09:25:30 -0700 (PDT) From: Drew Adams To: control@debbugs.gnu.org Subject: close 17511 X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.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: -3.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: -3.0 (---) close 17511 thanks From unknown Wed Jun 25 00:21:49 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 15 Jun 2014 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator