Syntax highlighter for nested block comments to be added

[immadisairaj]

The highlighter should accept nested block comments.

/*
------something------
/*
------something------
*/
------something------
*/

The present situation is: For the above code only the first 5 lines are highlighted.
Expected: All the lines should be highlighted as comments.

[parthsarthiprasad]

The current C++ version of highlighting semantics also work in the similar manner, The tmbundle searches for the first instance of */ , and closes the nested loop , Do you want something where the bundler searches for the last occourance of */ to close the nested loop.

Nested loop in C working in similar fashion

/*
------something------
/*
------something------
*/
------something------
*/
Where the last one is highlighted being a Stray `*/`

This can be worked about , but , might break a lot of code considering something like

/*
------something------
/*
------something------
*/
------something------
*/

var a: real;
//some other working code .


/*
------something------
/*
------something------
*/
------something------
*/

Here the compiler will search for last closing statement and comment out everything in between?

[immadisairaj]

Here the compiler will search for last closing statement and comment out everything in between?

Yes, you are right if you want to go with that approach.

The other approach might be similar to checking for curly braces in a code. Which is nested

/* (1 open)
------something------
/* (2 open)
------something------
*/ (2 close)
------something------
*/ (1 close)

[lydia-duncan]

Do you want something where the bundler searches for the last occourance of */ to close the nested loop

You definitely want to track the last matching */. @immadisairaj's nested strategy should be what you follow

[parthsarthiprasad]

Do you want something where the bundler searches for the last occourance of */ to close the nested loop

You definitely want to track the last matching */. @immadisairaj's nested strategy should be what you follow

I had a difference of opinion in this, Like all the nested comments are anyways going to be commented out , what will this change if we have nested multiline comment, If we have nesting or not, If we want to have a sense of sepration between blocks then maybe individually can use curly braces ,

Even though this can be done with the way we work with curly braces,
Will try to do the necessary changes then , with something like this.

chapel-tmbundle/Syntaxes/Chapel.tmLanguage

Lines 9 to 15 in 822363c

	<key>foldingStartMarker</key>
	<string>(?x)
	/\*\*(?!\*)
	|^(?![^{]*?//|[^{]*?/\*(?!.*?\*/.*?\{)).*?\{\s*($|//|/\*(?!.*?\*/.*\S))
	</string>
	<key>foldingStopMarker</key>
	<string>(?&lt;!\*)\*\*/|^\s*\}</string>

[lydia-duncan]

Like all the nested comments are anyways going to be commented out , what will this change if we have nested multiline comment

It depends on how you look for the last nested comment. As you said, a program can easily have multiple multiline comments in it. It would absolutely not be appropriate for the following to be treated as a single comment:

/* blah blah */
proc someFunc() { ... }
/* blah blah 2 */

Going for the first closing comment after an opening comment is preferable to treating a whole file as commented. But as this issue points out, the best strategy is to track matching opening and closing comments, ensuring that we only treat comments as comments and appropriately indicating when an opening comment is not matched by a closing one

[parthsarthiprasad]

Like all the nested comments are anyways going to be commented out , what will this change if we have nested multiline comment

It depends on how you look for the last nested comment. As you said, a program can easily have multiple multiline comments in it. It would absolutely not be appropriate for the following to be treated as a single comment:

/* blah blah */
proc someFunc() { ... }
/* blah blah 2 */

Going for the first closing comment after an opening comment is preferable to treating a whole file as commented. But as this issue points out, the best strategy is to track matching opening and closing comments, ensuring that we only treat comments as comments and appropriately indicating when an opening comment is not matched by a closing one

Yeah I checked few files and observed the requirement and this nested multiline comments might be a major requirement, will try to work for this as well then.