Extension does not find comments right after regions

[msparica]

Greetings, love the extension since the No Comments extension died, but one issue i found is that if the comment is right after a #region, it won't register it as a comment

with region

without region

probably something to do with the parsing logic. i'll try to look into your codebase later, and it's not a huge deal honestly, but for now, just letting you know

[msparica]

it also seems to have trouble with extra lines before a comment

however in this case, the top [-] collapses it properly, it just treats it as a regular collapsible comment inside the extension's "unobtrusive" comment (look at the collapsing buttons on the left)

i'm guessing you just wrap the whole comment in a collapsible block, where you include leading lines, but then it doesn't line up with the comment's collapsible block that Visual Studio uses by default, and it probably doesn't autocollapse since the cursor is technically inside the outer block, i.e. it's actively being edited

this whole "collapsible block inside a collapsible block" is probably the cause of having to click twice (first to expand the outer block the extension adds, then expanding the comment itself) that was discussed in #6

[msparica]

It seems to be that the region issue is the leading trivia failing the check at

UnobtrusiveCode/Spans/Parsers/CommentParser.cs:35 if (leading.All(x => x.IsCommentOrWhiteSpace())) since the region is neither comment nor whitespace, but is a part of the leading trivia of the token

The second issue with the newlines steams from the if statement on line 39, i reckon, where you skip one and only one newline. this seems intentional, looking at the tests, so i would move this to an option, since multiple newlines is a common pattern.

What i would do (and will if i find enough time this weekend - i'll make a pull request) is work backwards from the end of the list of leading trivia and stop at the second whitespace after the first comment trivia found - that way you capture the indentation of the comment, but not anything beyond that. I still need to check if i need to skip the first whitespace/endofline from the end, since i'm still going off of just the code.

in the syntax tree, those would be these three (or possibly just the first two of the highlighted ones)

this means that if you chain comments, only the last one will be treated as obtrusive code

the alternative is to find the last comment before the first non-whitespace non-comment trivia while working backwards and set the whitespace immediately preceding it as the start

in that case, you would be capturing these trivia:

however, this fails to capture any comments before a preprocessor directive. in this case, it would capture only this range

that can also be handled, albeit needing a manual walk through the entire LeadingTrivia list, looking for all subsets that are [whitespace][comment][n times comment, whitespace or end of line][whitespace], then yielding them all individually. in the above example, those would be these two subsets:

[niklaskallander]

Hi @msparica,

Looks like you’re onto something. If you end up making a PR, please add some unit tests to verify the fixes. 😊

I’m not actively working on this extension right now. I will improve on it eventually (lots that can be done) but I don’t have the time/energy for it at the moment.

Thanks!