From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Clean-up of forward-paragraph [Re: Beginingless paragraphs: second stab at a patch.] Date: Thu, 20 Oct 2005 13:53:18 +0000 (GMT) Message-ID: References: Reply-To: Alan Mackenzie NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1129818336 26738 80.91.229.2 (20 Oct 2005 14:25:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Oct 2005 14:25:36 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 20 16:25:35 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ESbHf-0006oD-7n for ged-emacs-devel@m.gmane.org; Thu, 20 Oct 2005 16:20:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ESbHe-00008g-HJ for ged-emacs-devel@m.gmane.org; Thu, 20 Oct 2005 10:20:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ESamV-0002T4-2a for emacs-devel@gnu.org; Thu, 20 Oct 2005 09:48:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ESamU-0002Sb-5q for emacs-devel@gnu.org; Thu, 20 Oct 2005 09:48:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ESamU-0002SX-1L for emacs-devel@gnu.org; Thu, 20 Oct 2005 09:48:30 -0400 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ESamS-0006dI-V8 for emacs-devel@gnu.org; Thu, 20 Oct 2005 09:48:30 -0400 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id NAA00535 for ; Thu, 20 Oct 2005 13:53:19 GMT X-Sender: root@acm.acm Original-To: emacs-devel@gnu.org In-Reply-To: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:44420 Archived-At: On Thu, 20 Oct 2005, Richard M. Stallman wrote: [ .... ] > (ii) When `use-hard-newlines' is non-nil (i.e. Longlines Mode is > enabled), forward-paragraph can spuriously recognise a line "in the > middle of a paragraph" as a separator line when it "looks like" one. > (This only shows itself with a non-blank separator line.) >Sorry, I do not understand. With the following text line: First line of paragraph ;sep; second line of par third line , turn on Longlines Mode. The line acquires two "soft" newlines, and now looks like this: First line of paragraph ;sep; second line of par third line. The middle line, beginning with ";sep;", is spuriously recognised as a separator line by paragraph-separate. There is buggy code in forward-paragraph which tries to detect this situation. I will fix it. [ .... ] > (iii) When there is a non-nil fill-prefix, f-p uses it in place of > paragraph-start when searching backwards, but not when searching > forwards. Half of these cases is a bug. >I am not sure either one of them is right. What is right is to >implement the proper criterion--see the next issue. > Incidentally: The Elisp manual is a bit unclear on the page > "Paragraphs", where it says: > When there is a fill prefix, then paragraphs are delimited by all > lines which don't start with the fill prefix. > This doesn't make clear (? clear enough) whether this scheme of > terminating paragraphs is in addition to or in place of > paragraph-s\(tart\|eparate\). I think one of the words "also" and > "instead" should be inserted before "delimited". Which one? >It should be "in addition". OK. >If the fill-prefix is followed by text that would normally separate or start >paragraphs, that does separate or start paragraphs. Not quite: in the current implementation, paragraph-start is ignored when there's a fill-prefix. Non-separator lines without the fill-prefix always start paragraphs. What I've called "divider" lines below, are normal separator lines or lines with the prefix which are otherwise whitespace. The current implementation doesn't test for paragraph-s\(tart\|eparate\) on the same line as the fill-prefix. Should it? I'm trying to think of situations where somebody might want this. Perhaps they'd want an indentation to start a paragraph. Something like this: **********last line of paragraph. ********** First line of new paragraph. I've put together a tentative formulation of paragraph boundaries, (which doesn't as yet deal with this last situation). Please give me some feedback on it. ######################################################################### Definitions: (i) A @dfn{hard BOL} is the beginning of a line following a hard newline. (ii) A @dfn{separator (line)} is a line which paragraph-separate matches after any margin. (iii) A @dfn{starter (line)} is a line which paragraph-start matches after any margin, but which isn't a separator; (iv) A @dfn{divider (line)} is a line which is either a separator or has the fill-prefix (after any left margin) and is otherwise only whitespace. [This definition only applies when the fill-prefix is non-null.] (iv) The beginning and end of (the accessible portion of) the buffer always count as paragraph boundaries. [From this point on, "ALL paragraph boundaries" disregards BOB and EOB.] (v) All other paragraph boundaries are always at BOL, even when there is a left margin. (This is so that M-h C-w will always grab complete paragraphs.) (vi) When `use-hard-newlines' is non-nil, all paragraph boundaries are at hard BOLs. A paragraph starts at a non-separator line, and ends at the next hard BOL. Here, fill-prefix and paragraph-start are ignored. (vii) Otherwise, if fill-prefix is non-null: A paragraph starts at any non-divider line which either lacks the fill-prefix or follows a divider line. A paragraph ends at the start of the next paragraph or a divider line. Here, paragraph-start is ignored. (viii) Otherwise (fill-prefix is null), a paragraph starts at a non-separator line which is either a starter line or follows a separator line. It ends just before the next separator or starter line. (ix) If there happens to be a blank line before a paragraph start, this line is NOT regarded as being part of the paragraph. [This is the problem which was at the heart of this thread.] ######################################################################### -- Alan Mackenzie (Munich, Germany)