bug#81533: c-ts-mode: Improved block comment indentation

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <[email protected]> Sun, 02 Aug 2026 14:02:10 -0400
Newsgroups gmane.emacs.bugs
Message-ID <[email protected]>
>> The way `indent-line-function` is designed to handle this is that the
>> function should return `noindent` when the language's syntax is of no
>> help, such as when "indenting" the inside of a string or of a comment.
> But then c-ts-mode already violates the "don't indent without language
> syntax"-policy because it indents block comments.  My PR only changes
> (improves) the rules.

My comment was just meant to state the direction in which I think we
should move to better integrate with the rest of the infrastructure.

>> The rule (1) sounds right, but rules (2) and (3) should simply refrain
>> from modifying the line and return `noindent`.
> Why indent lines prefixed with "*" be indented but not other lines?

Yeah, it's not great, it's a heuristic that will sometimes fail, but
I found it's common to use part of the comment marker as a leading
per-line marker in multiline comments, which is also why we have
`comment-continue`.

It's also OK to just always return `noindent`.

>> These issues are basically language-independent so I'm not
>> happy with the current code: these issues should be handled
>> once for all tree-sitter modes.
>
> You could make the function public so that other modes could add it to
> their default rules:
>
> ((parent-is "comment") parent c-ts-mode-common-block-comment-offset)

Indeed.  But then its name shouldn't start with "c-ts-", it shouldn't
hard code "*", and it should live in another file.
That's a way to "handle [it] once for all tree-sitter modes".

Side note about your patch: `line-number-at-pos` takes time proportional
to the size of the buffer (well, proportional to (point), actually, but
you get the ... point =F0=9F=99=82), so calling it twice just to check if t=
wo
buffer positions are on consecutive lines is very inefficient.
Better use things like

    (> other-pos (line-end-position))

[ That will also fix the bug you have when the buffer is narrowed because
  one of the calls to `line-number-at-pos` passes the ABSOLUTE flag, while
  the other doesn't, so the two counts can't be meaningfully compared.  ]


=3D=3D=3D Stefan