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: Sat, 22 Oct 2005 11:51:18 -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 1129996399 10476 80.91.229.2 (22 Oct 2005 15:53:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 22 Oct 2005 15:53:19 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 22 17:53:10 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ETLf0-0006Wz-LB for ged-emacs-devel@m.gmane.org; Sat, 22 Oct 2005 17:51:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETLez-0006c7-1i for ged-emacs-devel@m.gmane.org; Sat, 22 Oct 2005 11:51:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ETLeT-0006R9-Eo for emacs-devel@gnu.org; Sat, 22 Oct 2005 11:51:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ETLeS-0006Qc-I8 for emacs-devel@gnu.org; Sat, 22 Oct 2005 11:51:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETLeS-0006QY-DU for emacs-devel@gnu.org; Sat, 22 Oct 2005 11:51:20 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ETLeS-0002Jf-JU for emacs-devel@gnu.org; Sat, 22 Oct 2005 11:51:20 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1ETLeQ-0006Ym-V5; Sat, 22 Oct 2005 11:51:19 -0400 Original-To: Alan Mackenzie In-reply-to: (message from Alan Mackenzie on Fri, 21 Oct 2005 20:09:52 +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:44574 Archived-At: The problem which started me off on all this was that of a blank line belonging to two paragraphs, as in the following file: The bug there is that the blank line is treated as part of the _preceding_ paragraph. It should be part of the following paragraph, and _not_ part of the preceding paragraph. Can you fix that bug in forward-paragraph? This has been implemented as (forward-paragraph -1) moving to the blank line. This is a misfeature, IMAO, no matter how long it may have been so. I don't think so. I normally want M-{ and M-} to stop in the blank line between paragraphs. Normally that blank line is a separator, so it will happen anyway. But as long as that special feature for blank lines remains, it should apply to M-} and M-{, just as to M-h. [Suggestions for Emacs 23: "blank line" in the above should be generalised here to "separator line". I don't understand what that would mean. We should make the definition of paragraph-separate explicitly state that it matches AT MOST a single line, so that separators can be found reliably whilst searching backwards. It can't hurt to add this to the documentation, since that assumption is already made. We could do it now. forward/backward-paragraph should be supplemented by (or even superseded by) beginning/end-of-paragraph, which would work like b/e-of-defun. I have nothing against it, but I don't see much use for it, and there are no keys to put them on. OK. There are several bugs in forward-paragraph. I will fix them. The easiest way to fix them is with a thoroughgoing refactoring of the function (which I have already done). I suspect, though, you will prefer the basic structure of the code to be left unchanged. Please confirm or deny this! For now, I'd rather stick with the basic structure of the code. After the release, we could refactor it.