From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: Clean-up of forward-paragraph [Re: Beginingless paragraphs: second stab at a patch.] Date: Fri, 21 Oct 2005 00:50:12 -0400 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1129870334 2010 80.91.229.2 (21 Oct 2005 04:52:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 21 Oct 2005 04:52:14 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 21 06:52:11 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ESorl-0000fV-ES for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2005 06:50:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ESork-0004lL-Q4 for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2005 00:50:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ESor8-0004XX-Ny for emacs-devel@gnu.org; Fri, 21 Oct 2005 00:50:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ESor7-0004Wi-QN for emacs-devel@gnu.org; Fri, 21 Oct 2005 00:50:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ESor7-0004WX-Lv for emacs-devel@gnu.org; Fri, 21 Oct 2005 00:50:13 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ESor7-0005Tc-Tl for emacs-devel@gnu.org; Fri, 21 Oct 2005 00:50:14 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1ESor6-0002tE-Lm; Fri, 21 Oct 2005 00:50:12 -0400 Original-To: Alan Mackenzie In-reply-to: (message from Alan Mackenzie on Thu, 20 Oct 2005 13:53:18 +0000 (GMT)) 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:44476 Archived-At: The current implementation doesn't test for paragraph-s\(tart\|eparate\) on the same line as the fill-prefix. Should it? I think it is important to see what past versions of Emacs did--for instance, Emacs 19, before the support for a left margin was added. If it was always done this way, then I think we should document it clearly and not change it. There are no users asking for changes in this, and changing it would be risky. However, if the past behavior was confused or conflicting, we need to figure out which past behavior to be compatible with. Regarding your proposed definition of paragraphs, I am concerned about possible incompatibilities. In the "new" cases, those of use-hard-newlines and nonempty left margin, we are not particularly bound by compatibility. However, in the other cases we are. (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.] I think that together with (vii) are very hard to understand. (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. Does this make some unstated assumption about how separator lines and hard newlines relate to each other? Perhaps it is just that the text is confusing. (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.] I am not quite sure what that means in concrete terms. As I said before, that blank line MUST be part of the following paragraph. That is essential for compatibility. I think that at present we should probably stick to fixing anything which is most obviously a bug. For instance, all paragraph beginnings and ends should be at BOL; when it fails to do that, that is worth fixing. Bigger changes should wait for after the release.