From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: adaptive-fill-mode and auto-fill-mode Date: Sun, 08 Oct 2006 21:03:19 +0200 Message-ID: <45294B77.5030202@gmx.at> References: <4527F569.2030007@gmx.at> <4528D303.3080903@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1160334281 28522 80.91.229.2 (8 Oct 2006 19:04:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 8 Oct 2006 19:04:41 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 08 21:04:39 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GWdwx-000497-0W for ged-emacs-devel@m.gmane.org; Sun, 08 Oct 2006 21:04:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GWdww-0005mS-Ky for ged-emacs-devel@m.gmane.org; Sun, 08 Oct 2006 15:04:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GWdwk-0005kT-U5 for emacs-devel@gnu.org; Sun, 08 Oct 2006 15:04:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GWdwk-0005jb-DA for emacs-devel@gnu.org; Sun, 08 Oct 2006 15:04:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GWdwk-0005jS-9X for emacs-devel@gnu.org; Sun, 08 Oct 2006 15:04:22 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1GWe47-0005ax-BM for emacs-devel@gnu.org; Sun, 08 Oct 2006 15:12:00 -0400 Original-Received: (qmail invoked by alias); 08 Oct 2006 19:04:19 -0000 Original-Received: from N773P015.adsl.highway.telekom.at (EHLO [62.47.40.143]) [62.47.40.143] by mail.gmx.net (mp044) with SMTP; 08 Oct 2006 21:04:19 +0200 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: Stefan Monnier In-Reply-To: X-Y-GMX-Trusted: 0 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:60530 Archived-At: > I guess what I don't understand is in what way this is a fix for > the problem. Yes, it may work for your specific case, but what about in > cases such as: > > (defun foo () > "docstring" > > ;; The empty line above is important. > ;; This second line as well. > (let ((toto titi)) > ;; some comment klsdhfkshgkslfkhgsjkhgskhgjfdhgd yy > > the same problem will happen, although not at BOL. I don't accept the prefix when _compos_ is not at BOL (in your example compos is before ";; some comment ..."). `comment-indent-new-line' has no idea where the fill-prefix comes from (otherwise solving all this would be trivial). I'm afraid my code is unreadable. > Maybe a better fix would > be (when compos is set and `prefix' matches > (concat "\\`[ \t]*" comment-start-skip)) to go to compos, and call > comment-forward until we reach point. If we bump into non-comment before > reaching point, then the prefix was set based on some other unrelated > comment and should be ignored. Why? compos is at the beginning of the current comment provided `point' is within a comment. The problem that `comment-indent-new-line' used the fill-prefix in the "not compos" case is trivially handled in the "else" part of `comment-valid-prefix-p'. The problem you refer to is with the "then" part. >>Indeed. The reason is that I don't want to affect multiline comment >>environments when the comment starting at compos is a single line >>comment. > > > But in what is checking comment-end better than using "comment-forward + not > bolp"? Well, checking comment-end style is cheaper than doing comment-forward. Combine these before doing the string-match? >>>;; foo wrote: >>>;; > where the fill-prefix will include 3 spaces after ";;" >>>;; > even though the first line doesn't match it. > > >>Do you think my patch would be responsible for not handling these > > > The prefix would be ";; >" which doesn't match the string at compos, so your > code would reject it. ... but the string at compos is ";; >" ... >>(at line-beginning)? > > > These can happen at any indentation. ... if compos is not at line beginning the prefix is rejected. >>If the prefix passed to `comment-valid-prefix-p' >>matches the string at compos there shouldn't be any problems. > > > Of course, but what I'm saying is that it may not match, even in cases where > it's perfectly correct. The only cases rejected are when the string is not at line beginning or does not match the prefix. In your second example the prefix is ";; ", at least with emacs -Q, because that's the common prefix of ";; " and ";; >". >>I think the second example doesn't work because >>`fill-common-string-prefix' determines the common prefix of ";; " and >>";; > " as ";; " long before I lay my hands at this. > > > That depends on adaptive-fill-function. I fail to understand you here. If the comment at compos doesn't match the prefix why should I want to insert the prefix on the next line? >>Where do you want to strip whitespace, >>before the comment marker, between comment marker and body? Would it be >>reliable to do that? > > > Why not? Because, as I suppose, the number of spaces is significant for the fill-prefix. >>Personally, I don't care at all. My auto-fill-function uses syntax-ppss >>and doesn't fill normal strings. But, as stated above, I don't think >>that auto-fill should be allowed to break non-doc-strings in Elisp. > > > I completely understand your point of view, but it's still far from > a bug-fix and it's not the only way to go about it. It fixes that better than I expected. Note also that you never had a chance to handle this _before_ the introduction of the doc-string face. But I admit that emacs was always breaking lisp strings this way, hence let's drop it (which means I don't need to change fill.el either). > Have you tried > comment-auto-fill-only-comments? It doesn't fill doc-strings.