Multiline Comments broken after last update

[tgrelka]

After update 3.3.30, multiline comment highlights are broken for me.

Before:

After update to 3.3.30:

Some background: For improved text reading flow, I have configured multiline comments to trigger with a keyword, while I use single character symbols if I want to just highlight a single line. However, since the last update (due to changes related to issue #32), multi-line highlighting is no longer working the way I exptected it to work - highlighting connected lines until a line break. I use this a lot across a few code bases and the last update broke almost all comment highlights for me as a consequence.

[edwinhuish]

You can add indentation to the second line, and it will work properly

[tgrelka]

You can add indentation to the second line, and it will work properly

Yes, I figured that out. But that will require reformatting many comments, which I would like to avoid, and also change the layout of the text.

I don’t fully agree with #32 in regards to not highlighting text on the same indentation level, as I would expect multi-line highlights to work (at least when on the same indentation level). Of course, I can respect the decision to introduce that feature and break the old way.

As an alternative to restoring the previous behaviour, I would propose an option for the highlighter, e.g.

"tag": ["Note", "Info"],
"color": "#3498DB",
"multiline": true,
"indentation": "same" // three options: ignore, same, indented

ignore would be the old behaviour, completely ignoring indentation. same would only highlight following lines indented to the same level (and up to the next line break), and indented would only highlight the next lines if those are indented further than the starting line with the tag (up to the next line no indented more than the starting line, as an additional behavioural improval maybe?)

I’m open to contributing this improvement! And of course, it is just a proposal! I think it would add value to the multiline feature.

[edwinhuish]

Thanks for your suggestion. But I'm not sure if this is necessary.

Multiple lines with the same indentation do not seem to have many usage cases. On the contrary, break at the blank line seems little rude.

Example, when there have many todo points, and each has many words. I think the people would like to separe the points with empty line like below:

PS: I was thinking about remove break at the empty line. The code has not been changed just because I have been too busy recently.

/**
 * TODO: Some todo points:
 * 
 *   1. Add a new function to get the user's role and permissions.
 *     - This function should return a list of roles and permissions that the user has.
 *     - The role and permission list should be returned in the format of a list of strings.
 * 
 *   2. Add a new function to get the user's menu. 
 *     - The menu should be a list of menus that the user has access to.
 *     - The menu should be returned in the format of a list of strings.
 * 
 *   3. Add a new function to get the user's avatar. 
 *      The avatar should be a URL to the user's avatar image.
 * 
 *   4. Add a new function to get the user's name. 
 *      The name should be a string that represents the user's name.
 */

[edwinhuish]

By the way, if there is necessary for multiline indentation option. I would like to be something as below:

{
  "tag": ["Note", "Info"],
  "color": "#3498DB",
  "multiline": true  // four options: ( true | 'break-line' | 'indented' | 'both' ) 
}

[tgrelka]

Thank you for the input! My use-case for multiline with same indentation was explained above, I sometimes want to highlight a paragraph inside an explanation of a complex piece of code, or have multiple lines highlighted together.

Here is an example of a common use case of mine:

I like combining the options into one! It’s common in many Code options, so it should work well here. I‘m curious, both would mean it only highlights indented lines, AND stops after the first line break, even if the following lines are indented?

So in a code snippet like this:

/* TODO: Something I should do
 *     1. First point
 *         - More details
 *
 *     2. Second point
 */

only the first point would be highlighted, but no the second one?

Thank you for the response! If you greenlight the option, I will start implementing it that way.

[edwinhuish]

For your code example, I don't understand why don't you insert one space at the front of the second line... It's a normal way to write a snippet. ( You should tell me the public use case, not personal feeling... )

Here is an example of a common use case of mine:

For the both option, you are right, it is useless.

Also this is why I don't like break until empty line. There are many restrictions on writing.

[tgrelka]

I would disagree that it’s a common use case to indent everything after the first line of a comment, at least most comments I have seen in source code don’t do that.

// Here I have some comment text that is too long for a single line
// so I continue in the second line - without indenting it by a single space.

vs.

// Here I have another long comment
//  and indented the second line of it - I haven’t seen that very often.

[edwinhuish]

Your example is plain text.

Normally, better-comments-next is used for

• Alerts (single line)
• Queries/Jobs (multiline)
• TODOS (multiline)
• etc...

Also for better-comments-next needs to put the tag at the beginning of the first line. like:

// # Here I have some comment text that is too long for a single line
//   so I continue in the second line.
//   and here will be the third line

I understand what you mean, but what I need to consider is, is this usage method common? Is it really necessary to modify ?

[edwinhuish]

After consideration, I think is ok to provide an option for users:

{
  "tag": ["Note", "Info"],
  "color": "#3498DB",
  "multiline": true  // two options: ( true | 'break-line' | 'indented' )  true means 'indented', keep using true for compatibility
}

But it may be a while later, because I have no time recently.

If someone can provide PR, I will be grateful