From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: regression: filling comments in C++ code (today's CVS) Date: Mon, 10 Feb 2003 10:36:55 -0500 Sender: cc-mode-help-admin@lists.sourceforge.net Message-ID: <200302101536.h1AFauN22496@rum.cs.yale.edu> 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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1044891520 4146 80.91.224.249 (10 Feb 2003 15:38:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 10 Feb 2003 15:38:40 +0000 (UTC) Cc: "Stefan Monnier" , "Robert Anderson" , emacs-devel@gnu.org, bug-cc-mode@gnu.org Return-path: Original-Received: from lists.sourceforge.net ([66.35.250.206] helo=sc8-sf-list2.sourceforge.net) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18iG10-00014U-00 for ; Mon, 10 Feb 2003 16:38:38 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 18iG2W-0004Fi-00; Mon, 10 Feb 2003 07:40:12 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by sc8-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 18iG2G-0003fC-00 for ; Mon, 10 Feb 2003 07:39:57 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.10) id 18iG2E-0001ke-00 for bug-cc-mode@gnu.org; Mon, 10 Feb 2003 10:39:54 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18iG1Q-0003iw-00 for bug-cc-mode@gnu.org; Mon, 10 Feb 2003 10:39:06 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18iFzQ-0002YW-00; Mon, 10 Feb 2003 10:37:00 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id h1AFauN22496; Mon, 10 Feb 2003 10:36:56 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Martin Stjernholm Errors-To: cc-mode-help-admin@lists.sourceforge.net X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports, feature requests, and general talk about CC Mode. List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 10 Feb 2003 10:36:55 -0500 Xref: main.gmane.org gmane.emacs.cc-mode.general:392 gmane.emacs.devel:11546 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11546 > > > Well, it's not that Kyle E Jones just was being stupid when he wrote > > > filladapt. He can't do it any better way since there's no hook to > > > replace fill-context-prefix which implements adaptive-fill-mode. > > > > I don't understand. Why can't filladapt check (and call) > > fill-paragraph-function before doing anything else ? > > I.e. filladapt still overrides fill-paragraph but it checks > fill-paragraph-function earlier itself. You're right, it could do > that. > > CC Mode would still have to use fill-paragraph-function in a fairly > convoluted way, though: > > 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 ...)) and as a matter of fact, the let binding is already done by fill-paragraph for you (don't know if filladapt does it as well or not, tho), so there's really nothing special to do other than "return a non-nil value". That let-binding is also already done by c-fill-paragraph, by the way. > That'd be workable, but it's not a very pretty solution. It's the way it's meant to work. In practice (barring compatibility issues with filladapt, XEmacs, and Emacs < 20.7, i.e. things I don't know about) it simply looks like the following: (set (make-local-variable 'fill-paragraph-function) 'foo-fill-para) and (defun foo-fill-para (...) ... (fill-paragraph ...) ...) where the inner call is typically wrapped in a `let' that rebinds a few vars such as adaptive-fill-regexp, paragraph-start, ... or it might directly call fill-region-as-paragraph or do the filling itself. > A potential > problem is if fill-paragraph has some recursion detection (it often > has, but in the versions I've checked that wouldn't affect this case). It indeed does and that detection is "set fill-paragraph-function to nil while calling it" which is exactly what you suggested in steps 2 and 4. > A cleaner approach would be to make fill-paragraph a function that > only calls fill-paragraph-function and move the current functionality > in it to a function that is installed on fill-paragraph-function by > default. CC Mode could then install a function on > fill-paragraph-function that chains on to the previous one. (Other > packages like filladapt would do the same and some effort would be > necessary in CC Mode to ensure it is installed last, but it's usually > not very difficult for a major mode to do that.) I don't see why the current system can't do the exact same thing: the only difference is that the value corresponding to the default is nil instead of being fill-paragraph and that instead of (funcall next-fun ...) you have to do (let ((fill-paragraph-function next-fun)) (fill-paragraph ...)) > Anyway, there are compatibility problems with this suggestion, so it's > probably easier just to live with it. Indeed. > > > 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. > It's also line oriented if I remember correctly, so it can affect > parts of the lines that are outside the two positions. A fairly > peculiar case but still something that CC Mode has to do some trickery > for so that code close by a comment doesn't get filled too. I think I've tried to improve this, but I can't remember how far I've gotten. I definitely consider it as a bug when f-r-a-p modifies the buffer outside of the specified region. > 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". > > That would help in the "normal" case, so the question is not "would it > > work with filladapt" but "would it hurt with filladapt". > > AFAIK it can't hurt, but I don't know enough about filladapt (or about > > cc-mode's filling) to be sure. > > No, it probably wouldn't. I'll make that change. Great, thanks, Stefan ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com