bug#3900: fill-comment-paragraph fails (e.g.) in perl-mode POD

bug#3900: fill-comment-paragraph fails (e.g.) in perl-mode POD

[Bob Rogers]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1619 bytes --]

   To reproduce (in trunk or 23.0.96):

   1.  Stuff the following six lines of "code" (two of them blank) into
the "foo.pl" file:

=head1 Testing

This is a test case line with lots of stupid text.
This is a test case line with a C<#> and lots of stupid text.

=cut

   2.  "emacs -Q foo.pl"

   3.  Move the cursor to any point in the fourth line (the one with
"C<#>") and type "M-q".  This will produce the following user-unfriendly
error:

	Search failed: "\\(^\\|\\s-\\);?#+ *"

   This directed my attention to the following code near the end of
fill-comment-paragraph:

	    (save-excursion
	      (goto-char beg)
	      (if (looking-at fill-prefix)
		  nil
		(re-search-forward comment-start-skip)))

which seems to make two bad assumptions:  That comment-start-skip is
never nil (though its documentation asserts otherwise), and that it
matches before the end of the buffer (which is trivially false at EOB).
The attached patch removes these assumptions, and makes the "Search
failed" error go away.

   Unfortunately, this isn't enought to fix perl-mode:  Instead of
signalling an error, it does nothing, which is not right, either.  The
deeper problem there is that M-q in perl-mode doesn't distinguish
between POD syntax and Perl code proper, and tries to treat the "#" as
the start of a single-line comment, even though that is not possible in
POD.  But fixing that would require a more intrusive patch, and the
fill-comment-paragraph code is wrong in any case, so I submit this fix
separately on the chance that it might be considered suitable for 23.1.

					-- Bob Rogers
					   http://www.rgrjr.com/


[-- Attachment #2: fill-comment-para-fix.patch --]
[-- Type: text/plain, Size: 1067 bytes --]

Index: lisp/textmodes/fill.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/textmodes/fill.el,v
retrieving revision 1.223
diff -c -r1.223 fill.el
*** lisp/textmodes/fill.el	8 Apr 2009 04:02:35 -0000	1.223
--- lisp/textmodes/fill.el	22 Jul 2009 03:44:20 -0000
***************
*** 976,986 ****
  	    (max comstart beg) end justify nil
  	    ;; Don't canonicalize spaces within the code just before
  	    ;; the comment.
! 	    (save-excursion
! 	      (goto-char beg)
! 	      (if (looking-at fill-prefix)
! 		  nil
! 		(re-search-forward comment-start-skip))))
  	   ;; Make sure we don't return nil.
  	   t))))))
  
--- 976,987 ----
  	    (max comstart beg) end justify nil
  	    ;; Don't canonicalize spaces within the code just before
  	    ;; the comment.
! 	    (and comment-start-skip
! 		 (save-excursion
! 		   (goto-char beg)
! 		   (if (looking-at fill-prefix)
! 		       nil
! 		       (re-search-forward comment-start-skip nil t)))))
  	   ;; Make sure we don't return nil.
  	   t))))))
  

bug#3900: fill-comment-paragraph fails (e.g.) in perl-mode POD

[Alan J Third]

Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:

>    To reproduce (in trunk or 23.0.96):
>
>    1.  Stuff the following six lines of "code" (two of them blank) into
> the "foo.pl" file:
>
> =head1 Testing
>
> This is a test case line with lots of stupid text.
> This is a test case line with a C<#> and lots of stupid text.
>
> =cut
>
>    2.  "emacs -Q foo.pl"
>
>    3.  Move the cursor to any point in the fourth line (the one with
> "C<#>") and type "M-q".  This will produce the following user-unfriendly
> error:
>
> 	Search failed: "\\(^\\|\\s-\\);?#+ *"

Hi, Sorry it's taken so long to respond to your bug report.

I can't reproduce this in either Emacs 24.5 or Emacs 25. Can you confirm
whether you're still seeing this behaviour in a recent version of Emacs?
-- 
Alan Third

bug#3900: fill-comment-paragraph fails (e.g.) in perl-mode POD

[Bob Rogers]

   From: Alan J Third <alan@idiocy.org>
   Date: Thu, 14 Jan 2016 20:22:29 +0000

   Hi, Sorry it's taken so long to respond to your bug report.

No problem.

   I can't reproduce this in either Emacs 24.5 or Emacs 25. Can you confirm
   whether you're still seeing this behaviour in a recent version of Emacs?
   -- 
   Alan Third

Nope; works for me, too.

					-- Bob