From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: adaptive-fill-mode and auto-fill-mode Date: Sun, 08 Oct 2006 21:37:45 -0400 Message-ID: References: <4527F569.2030007@gmx.at> <4528D303.3080903@gmx.at> <45294B77.5030202@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1160357892 20470 80.91.229.2 (9 Oct 2006 01:38:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 9 Oct 2006 01:38:12 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 09 03:38:09 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 1GWk5k-00071h-9I for ged-emacs-devel@m.gmane.org; Mon, 09 Oct 2006 03:38:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GWk5j-0002Qa-OL for ged-emacs-devel@m.gmane.org; Sun, 08 Oct 2006 21:38:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GWk5U-0002Mv-A2 for emacs-devel@gnu.org; Sun, 08 Oct 2006 21:37:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GWk5T-0002Lu-HR for emacs-devel@gnu.org; Sun, 08 Oct 2006 21:37:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GWk5T-0002LY-DH for emacs-devel@gnu.org; Sun, 08 Oct 2006 21:37:47 -0400 Original-Received: from [209.226.175.93] (helo=tomts36-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GWkCv-0007Sd-4o for emacs-devel@gnu.org; Sun, 08 Oct 2006 21:45:29 -0400 Original-Received: from pastel.home ([70.53.194.105]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20061009013746.STCP13653.tomts36-srv.bellnexxia.net@pastel.home> for ; Sun, 8 Oct 2006 21:37:46 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C16A58098; Sun, 8 Oct 2006 21:37:45 -0400 (EDT) Original-To: martin rudalics In-Reply-To: <45294B77.5030202@gmx.at> (martin rudalics's message of "Sun\, 08 Oct 2006 21\:03\:19 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:60537 Archived-At: > Why? compos is at the beginning of the current comment provided `point' > is within a comment. Oh right, I'm not making sense. Then how 'bout the 100% guaranteed untested patch below. > 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. >>=20 >>=20 >> 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? But the code *already* does the comment-forward check. As I pointed out your code does the same thing as mine, just slightly differently. This part of the different seems to be just "worse". The other part OTOH seems to be "partly better". Please merge them. >>>> ;; foo wrote: >>>> ;; > where the fill-prefix will include 3 spaces after ";;" >>>> ;; > even though the first line doesn't match it. >>=20 >>=20 >>> Do you think my patch would be responsible for not handling these >>=20 >>=20 >> The prefix would be ";; >" which doesn't match the string at compos, so = your >> code would reject it. > ... but the string at compos is ";; >" ... Not necessarily. I may compute this in adaptive-fill-function straight from the first line, (when using auto-fill on the first line). >>> (at line-beginning)? >> These can happen at any indentation. > ... if compos is not at line beginning the prefix is rejected. Where? Why? > 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 > ";; >". But your code will be used even if "-Q" is not passed. >>> 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. >>=20 >> 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? Why not? >>> 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. But maybe it's the right place to introduce such a feature. Basically extend this var so you can say "fill in FOO" where FOO is the list of possible contexts, such as `comment', `string', `doc', `code'? Stefan --- newcomment.el 24 ao=FB 2006 14:41:55 -0400 1.96 +++ newcomment.el 08 oct 2006 21:33:15 -0400=09 @@ -1124,12 +1124,44 @@ :group 'comment) =20 (defun comment-valid-prefix-p (prefix compos) + "Check that the adaptive-fill-prefix is consistent with the context. +PREFIX is the prefix (presumably guessed by `adaptive-fill-mode'). +COMPOS is the position of the beginning of the comment we're in, +or nil if we're not inside a comment." + ;; This consistency checking is mostly needed to workaround the limitati= on + ;; of auto-fill-mode whose paragraph-determination doesn't pay attention + ;; to comment boundaries. + (if (null compos) + ;; We're not inside a comment: the prefix shouldn't match + ;; a comment-starter. + (not (and comment-start comment-start-skip + (string-match comment-start-skip prefix))) (or ;; Accept any prefix if the current comment is not EOL-terminated. (save-excursion (goto-char compos) (comment-forward) (not (bolp))) - ;; Accept any prefix that starts with a comment-start marker. - (string-match (concat "\\`[ \t]*\\(?:" comment-start-skip "\\)") - prefix))) + ;; Accept any prefix that starts with the same comment-start marker + ;; as the current one. + (when (string-match (concat "\\`[ \t]*\\(?:" comment-start-skip "\\)") + prefix) + (let ((prefix-com (comment-string-strip (match-string 0) nil t))) + (string-match "\\`[ \t]*" prefix-com) + (let* ((prefix-space (match-string 0)) + (prefix-indent (string-width prefix-space)) + (prefix-comstart (substring prefix-com (match-end 0)))) + (save-excursion + (goto-char compos) + ;; The comstart marker is the same. + (and (looking-at (regexp-quote prefix-comstart)) + ;; The indentation as well. + (or (=3D prefix-indent + (- (current-column) (current-left-margin))) + ;; Check the indentation in two different ways, just + ;; to try and avoid most of the potential funny case= s. + (equal prefix-space + (buffer-substring (point) + (progn (move-to-left-margin) + (point))))))))))))) +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20 ;;;###autoload (defun comment-indent-new-line (&optional soft) @@ -1182,8 +1214,7 @@ ;; If there's an adaptive prefix, use it unless we're inside ;; a comment and the prefix is not a comment starter. ((and fill-prefix - (or (not compos) - (comment-valid-prefix-p fill-prefix compos))) + (comment-valid-prefix-p fill-prefix compos)) (indent-to-left-margin) (insert-and-inherit fill-prefix)) ;; If we're not inside a comment, just try to indent.