From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Martin Stjernholm Newsgroups: gmane.emacs.devel Subject: Re: regression: filling comments in C++ code (today's CVS) Date: 24 Feb 2003 02:52:01 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5by94630ou.fsf@lister.roxen.com> References: <200301171719.h0HHJOP18943@rum.cs.yale.edu> <5b65sl53l3.fsf@lister.roxen.com> <200301201654.h0KGsDJ10072@rum.cs.yale.edu> <5by95b1d0m.fsf@lister.roxen.com> <200301260148.h0Q1mGX18192@rum.cs.yale.edu> <5bel6iqlxw.fsf@lister.roxen.com> <200302101536.h1AFauN22496@rum.cs.yale.edu> Reply-To: bug-cc-mode@gnu.org NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046051592 21248 80.91.224.249 (24 Feb 2003 01:53:12 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 24 Feb 2003 01:53:12 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18n7nq-0005Wa-00 for ; Mon, 24 Feb 2003 02:53:10 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18n835-0006o9-00 for ; Mon, 24 Feb 2003 03:08:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18n7ne-0003zp-05 for emacs-devel@quimby.gnus.org; Sun, 23 Feb 2003 20:52:58 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18n7my-0003s2-00 for emacs-devel@gnu.org; Sun, 23 Feb 2003 20:52:16 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18n7mu-0003qL-00 for emacs-devel@gnu.org; Sun, 23 Feb 2003 20:52:14 -0500 Original-Received: from godzilla.roxen.com ([194.52.182.190] helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18n7mo-0003kk-00; Sun, 23 Feb 2003 20:52:07 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id 407D899C0; Mon, 24 Feb 2003 02:52:05 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id 45AE599BD; Mon, 24 Feb 2003 02:52:01 +0100 (MET) Original-To: "Stefan Monnier" In-Reply-To: <200302101536.h1AFauN22496@rum.cs.yale.edu> Original-Lines: 61 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Original-cc: Robert Anderson Original-cc: bug-cc-mode@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11891 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11891 "Stefan Monnier" wrote: > > 1. fill-paragraph is called. > > 2. c-fill-paragraph is called by fill-paragraph-function. It does its > > comment masking etc. Then it dynamically binds > > fill-paragraph-function to nil and calls fill-paragraph again. > > 3. fill-paragraph now runs a second time and performs its default > > action. > > 4. c-fill-paragraph cleans up the masking, restores > > fill-paragraph-function and returns. > > 5. fill-paragraph returns. > > The step 4 together with the second half of step 2 amount to > > (let (fill-paragraph-function) > (fill-paragraph ...)) /.../ Sorry, I failed to make my point clear. It's not the dynamic binding of the hook, it's that fill-paragraph doubles as both the wrapper that calls fill-paragraph-function and as the provider of the default implementation for it. I argued that it'd be cleaner if it only called fill-paragraph-function which instead had the default implementation installed as its default value. (Anyway, as said earlier, the issue is moot for the compatibility reasons.) > > > > It'd be nice if fill.el provided a function that only did the pure > > > > text filling between two positions, preferably also with the option to > > > > > > Isn't that what fill-region-as-paragraph does ? > > > > It has adaptive-fill-mode stuff hardcoded. Although easy to shut down > > by covering the adaptive-fill-mode variable, it'd be cleaner to have > > a basic filling function that doesn't have any such "surprises". > > I don't necessarily disagree but I think it's a rather minor issue. Yes, that particular one is minor since it's been around a long time, but things like it can be a problem when they are introduced in new versions. The difference between the user level task and the lower level utility function (which I'm advocating here) is that the former is allowed to accumulate more such customizable settings while the latter should have completely well defined behavior (if it gets more features they'll be controlled through more arguments instead). > > And for some reason it skips empty lines at the beginning of the > > region, something that should be up to the caller to do. It might > > contain other similar oddities too. > > I'm not sure what you mean by "skips empty lines". I mean the following near the start of fill-region-as-paragraph: ;; Ignore blank lines at beginning of region. (skip-chars-forward " \t\n") To me it seems more natural if this function compacted all whitespace the same way, even that at the start. Btw, if it skips \n then it should perhaps skip \r too so that it works with selective-display.