Continue comments when opening a new line

[antoyo]

Fix #1730.

We probably want to be able to configure whether we want this or not. If so, what option name do you propose?

This does not support continuing block comment, i.e. adding a * when a comment starts with /*. I propose we do this in a future PR since this would require some more thought regarding the block comment token (i.e. do we want to add it to languages.toml?).

[antoyo]

I converted to a draft because that doesn't support doc-comment. Any idea on how we want to do this? Do we want to add the doc-comment syntax in languages.toml?

That would require a list as there can be /// and //! for Rust, for instance. Do we need some support for /* vs /*!?

[archseer]

I converted to a draft because that doesn't support doc-comment. Any idea on how we want to do this? Do we want to add the doc-comment syntax in languages.toml?

We could extend comment-token to be a list: comment-token: ["///", "//"].

Actually, an easier way would be: find a comment (//), then scan forward until you reach whitespace. Then scan to the end of whitespace:

//*  test

would produce //* which would retain any symbols at the start of the line (this would also cover the extra slash from the doc comment) plus indentation from the previous level.

Block comments

It's okay to solve block comments later since none of the functions have support for this yet.

Some bits and ideas:

VSCode's config seems to have two separate blocks for line & block comments:

"comments": {
    "lineComment": "//",
    "blockComment": ["/*", "*/"]
},

and here's the algorithms in codemirror: https://github.com/codemirror/comment/blob/269b9af21d68b1a71fa40bbf6c1e41c665e6e7d0/src/comment.ts#L48-L161=

The initial implementation for line comments in helix was based on the functions in ^

[antoyo]

Actually, an easier way would be: find a comment (//), then scan forward until you reach whitespace. Then scan to the end of whitespace:

I thought about this, but that wouldn't work: you could have a shebang in bash and you don't want to have #!/bin/bash repeated on the next line. Also some users could not put a space after //. I believe I had another reason, but I forgot.

Edit: for the shebang, vim does not continue the comment. Any way we could do the same?

If I go with comment-token: ["///", "//"], do I have to add it manually for all languages or is there any automated tool that is used to generate this file?

[archseer]

Actually, an easier way would be: find a comment (//), then scan forward until you reach whitespace. Then scan to the end of whitespace:

I thought about this, but that wouldn't work: you could have a shebang in bash and you don't want to have #!/bin/bash repeated on the next line. Also some users could not put a space after //. I believe I had another reason, but I forgot.

Edit: for the shebang, vim does not continue the comment. Any way we could do the same?

If I go with comment-token: ["///", "//"], do I have to add it manually for all languages or is there any automated tool that is used to generate this file?

Yeah let's go with the simple approach for now and only resume exact matches?

If I go with comment-token: ["///", "//"], do I have to add it manually for all languages or is there any automated tool that is used to generate this file?

You'll need to manually update the file, it's user-maintained. I'd also order the // first so we can use the first item in the list as the comment token when commenting lines.

[antoyo]

Since I have to edit the languages.toml file, I thought I should be adding block comment as well at the same time.

The problem I have is I don't know if there's a way to distinguish between a block-comment vs a line-comment. Do we have a way to know whether a cursor is within a block-comment?

[archseer]

The problem I have is I don't know if there's a way to distinguish between a block-comment vs a line-comment. Do we have a way to know whether a cursor is within a block-comment?

You could match this via tree-sitter queries, usually line comments vs block comments use different node types. For a more generic system we'd need to immitate https://github.com/codemirror/comment/blob/269b9af21d68b1a71fa40bbf6c1e41c665e6e7d0/src/comment.ts#L88-L120= then fallback to line comments

[antoyo]

You could match this via tree-sitter queries, usually line comments vs block comments use different node types.

I'm not familiar with tree-sitter. It seems to use strings to identify node: is this correct? If so, where can I find the documentation for the different node types?

My attempt at using block_comment instead of comment didn't work.

[the-mikedavis]

Using tree-sitter node names might actually not work out very well since different grammars use different names for the comment nodes (line_comment/block_comment/comment/etc). Instead using a capture like @comment could be more general but there are also captures like @comment.line/@comment.block/@comment.docs where you'd want to chop off the suffix.

[antoyo]

Instead using a capture like @comment could be more general but there are also captures like @comment.line/@comment.block/@comment.docs where you'd want to chop off the suffix.

By that, do you mean that I should add a line like:

(block_comment) @comment.block.around

in runtime/queries/rust/textobjects.scm and all other languages?

Or should those captures already exist?

[the-mikedavis]

I think something like that should work. It would be on a per-language basis though and I'm not sure how many languages have comment captures. I think it's ok if there's fallback behavior (even it the fallback behavior is just to not continue comments) for languages that don't have textobjects queries.

[antoyo]

So, I started adding the missing tree-sitter objects and config for some languages and I wanted to have some feedback before I continue doing it for all the other languages.

Also, I have an issue: it seems like tree-sitter doesn't consider the start of a comment to be a non-terminating comment, which means I cannot continue them completely. My attempt here only continues the first line, but it won't work on the following lines. Any idea what I could do for this?

Thanks for your help!

[antoyo]

So, for the case of continuing start of comment, I had the following idea: we could add a setting to auto-close block comments, so we should always be in block comments and never in start of comments. What do you think?

[the-mikedavis]

I think it would be good to have an auto-pairs functionality for the block comment tokens, like HTML <!-- would auto-pair a -->. It wouldn't be reliable for detecting a block comment via tree-sitter though because you could disable auto-pair.

[antoyo]

It wouldn't be reliable for detecting a block comment via tree-sitter though because you could disable auto-pair.

Do you suggest that it's OK that it's not reliable or would you prefer a workaround? If you would want a workaround, do you have any idea that would be as fast as tree-sitter?

[the-mikedavis]

It would probably be ok in most cases but it would be prone to edge-cases. I would prefer a workaround since I don't use auto-pairs myself but I don't have any good ideas for doing it efficiently.

In any case, I think block comments should be handled in a separate PR as you say in the initial description. There are other block comment features like surrounding a selection with a block comment that might inform the design of continuing block comments. Line comment continuation would be a great increment on its own (although I'm biased because I mostly use languages that only have line comments).

[antoyo]

In any case, I think block comments should be handled in a separate PR as you say in the initial description.

Are you suggesting we keep the block comment as is in this PR and I'll fix them in a later PR? Or do you want that I split that in another PR right away?

There are other block comment features like surrounding a selection with a block comment that might inform the design of continuing block comments.

I disagree because we probably don't want a surrounding feature to add a * (or other character) at the beginning of every line because removing them could actually break code. So these two features should be separate in my opinion.

[the-mikedavis]

I would prefer splitting the block comments entirely to another PR if possible since that implementation needs some design.

[LeoniePhiline]

Is this PR abandoned?

[antoyo]

No, I just haven't got the time to clean it up.

I'll probably have time to do that in a couple months.

[antoyo]

I switched back to neovim, so I won't be updating this PR anymore. Feel free to take the changes and make another PR.