From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#17511: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear Date: Sat, 17 May 2014 07:45:44 -0700 (PDT) Message-ID: <8c772b14-20d1-4e3a-9936-f81936c3d31b@default> References: <> <<83iop4eq5h.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1400337993 20082 80.91.229.3 (17 May 2014 14:46:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 May 2014 14:46:33 +0000 (UTC) Cc: 17511@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 17 16:46:25 2014 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 1WlfsV-00027n-AF for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 May 2014 16:46:23 +0200 Original-Received: from localhost ([::1]:40397 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlfsV-0002dw-0A for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 May 2014 10:46:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52719) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlfsJ-0002dk-Di for bug-gnu-emacs@gnu.org; Sat, 17 May 2014 10:46:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlfsA-0004wV-LV for bug-gnu-emacs@gnu.org; Sat, 17 May 2014 10:46:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlfsA-0004wP-He for bug-gnu-emacs@gnu.org; Sat, 17 May 2014 10:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WlfsA-0001vs-1v for bug-gnu-emacs@gnu.org; Sat, 17 May 2014 10:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 May 2014 14:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17511 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17511-submit@debbugs.gnu.org id=B17511.14003379587415 (code B ref 17511); Sat, 17 May 2014 14:46:01 +0000 Original-Received: (at 17511) by debbugs.gnu.org; 17 May 2014 14:45:58 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 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)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:89191 Archived-At: 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.