GNU bug report logs - #78003
31.0.50; comment-indent misbehaves in multiline comments

Previous Next

To reply to this bug, email your comments to 78003 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; comment-indent misbehaves in multiline comments
Date: Wed, 23 Apr 2025 11:17:59 +0800

X-debbugs-cc: monnier <at> iro.umontreal.ca

1. emacs -q
2. C-x b foo RET
3. M-x lisp-mode RET
4. Enter this content:
--8<---------------cut here---------------start------------->8---
#|
foo
#|
--8<---------------cut here---------------end--------------->8---
5. Put point after "foo".
6. M-;

The result is an insertion of trailing single-semicolon comment.
As we are already within a comment, this makes no sense.  M-; should
either do nothing, or possibly perform some form of indentation.

We could fix this within comment-dwim.  However, I propose instead to
change comment-indent (or possibly comment-search-forward).
This is because I first encountered this problem not via comment-dwim,
but via how indent-sexp calls comment-indent.

The above recipe with M-; is just the simplest reproducer I found.
Making comment-indent behave better within multiline comments would make
it a more useful function in general and also fix these various
misbehaviours at once.

Other background:

- Possibly indent-sexp needs some adjustment too, but any change to
  comment-indent should come first.

- A similar problem shows up with syntax-propertize-function values
  which set comment-fence syntax-table text properties, which are
  another kind of multiline comment.
  (Came up for me in consfigurator.el's syntax-propertize-function.)

- A similar problem shows up with the literate-scratch library
  Stefan M. and I were discussing over the past few days, where the
  problem is that the library adds a whitespace syntax-table property to
  some trailing newlines such that it is only the second of the two
  newlines following a paragraph which ends the comment.  With point
  between the two newlines, we're still in a comment, but comment-indent
  doesn't think so.

-- 
Sean Whitton

Message #8 received at 78003 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: 78003 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#78003: Acknowledgement (31.0.50; comment-indent misbehaves
 in multiline comments)
Date: Thu, 24 Apr 2025 15:40:00 +0800

[Message part 1 (text/plain, inline)]

Hello,

Proposed fix for the comment-indent part of this attached.

-- 
Sean Whitton

[0001-comment-indent-Handle-BOL-already-within-a-multiline.patch (text/x-diff, attachment)]

Message #11 received at 78003 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 78003 <at> debbugs.gnu.org
Subject: Re: bug#78003: Acknowledgement (31.0.50; comment-indent misbehaves
 in multiline comments)
Date: Thu, 24 Apr 2025 14:58:14 -0400

[Message part 1 (text/plain, inline)]

> We could fix this within comment-dwim.

I don't think we could because `comment-indent` is also a command.
Maybe we could make `comment-dwim` do something more useful than calling
`comment-indent` in that case, but that's "another problem".

> However, I propose instead to change comment-indent (or possibly
> comment-search-forward).

+1

> -    (let* ((eolpos (line-end-position))
> -	   (begpos (comment-search-forward eolpos t))
> +    (let* ((startpos (comment-search-forward (line-end-position) t))
> +           (begpos (or startpos
> +                       ;; If we couldn't find a comment *starting* on
> +                       ;; this line, see if we are already within a
> +                       ;; multiline comment at BOL (bug#78003).
> +                       (and (not continue)
> +                            comment-use-syntax comment-use-global-state
> +                            (let ((st (syntax-ppss (line-beginning-position))))
> +                              (and (nth 4 st) (< (nth 8 st) (point))
> +                                   (point))))))
> +           (multilinep (and (not startpos) begpos))

AFAICT we don't need to check (< (nth 8 st) (point)).
Am I missing something?

Also, I think the bug will still bite when
`comment-insert-comment-function` is set.

BTW, the patch looks simple in terms of the diff, but it makes the
control flow (which is already not great) even more complicated.

How 'bout the one below?


        Stefan

[comment-indent.patch (text/x-diff, inline)]

diff --git a/lisp/newcomment.el b/lisp/newcomment.el
index 23fcbc05372..d04090c0a75 100644
--- a/lisp/newcomment.el
+++ b/lisp/newcomment.el
@@ -713,18 +713,28 @@
 If CONTINUE is non-nil, use the `comment-continue' markers if any."
   (interactive "*")
   (comment-normalize-vars)
-  (let ((starter (or (and continue comment-continue)
-                     comment-start))
-	(ender (or (and continue comment-continue "")
-                   comment-end)))
-    (unless starter (error "No comment syntax defined"))
     (beginning-of-line)
-    (let* ((eolpos (line-end-position))
+  (let* ((starter (or (and continue comment-continue)
+                      comment-start
+                      (error "No comment syntax defined")))
+	 (ender (or (and continue comment-continue "")
+                    comment-end))
+         (eolpos (line-end-position))
 	   (begpos (comment-search-forward eolpos t))
 	   cpos indent)
-      (if (and comment-insert-comment-function (not begpos))
+    (cond
+     ;; If we couldn't find a comment *starting* on this line, see
+     ;; if we are already within a multiline comment at BOL (bug#78003).
+     ((and (not begpos) (not continue)
+           comment-use-syntax comment-use-global-state
+           (nth 4 (syntax-ppss (line-beginning-position))))
+      ;; We don't know anything about the nature of the multiline
+      ;; construct, so immediately delegate to the mode.
+      (indent-according-to-mode))
+     ((and comment-insert-comment-function (not begpos))
 	  ;; If no comment and c-i-c-f is set, let it do everything.
-	  (funcall comment-insert-comment-function)
+      (funcall comment-insert-comment-function))
+     (t
 	;; An existing comment?
 	(if begpos
 	    (progn

Message #16 received at 78003-done <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78003-done <at> debbugs.gnu.org
Subject: Re: bug#78003: 31.0.50; comment-indent misbehaves in multiline
 comments
Date: Fri, 25 Apr 2025 09:15:23 +0800

Version: 31.1

Hello,

On Thu 24 Apr 2025 at 02:58pm -04, Stefan Monnier wrote:

>> We could fix this within comment-dwim.
>
> I don't think we could because `comment-indent` is also a command.
> Maybe we could make `comment-dwim` do something more useful than calling
> `comment-indent` in that case, but that's "another problem".

Right.

> AFAICT we don't need to check (< (nth 8 st) (point)).
> Am I missing something?

I think you are correct that it does not need to be checked because this
call to `<' could only return nil in the case that
comment-search-forward returned non-nil, in which case we would not be
calling syntax-ppss at all.

> Also, I think the bug will still bite when
> `comment-insert-comment-function` is set.

Yes, I was thinking that handling it in that case is going to have to be
the responsibility of whatever function is set.  But it ought to know
what's going on better than comment-indent does.

> BTW, the patch looks simple in terms of the diff, but it makes the
> control flow (which is already not great) even more complicated.
>
> How 'bout the one below?

Thanks for reviewing, and for reworking it.  Installed the change.

There are other bugs nearby that I hope to fix soon but nothing
actionable remaining here, so closing the bug.

-- 
Sean Whitton

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.