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