Whitespace at start/end of line in comments flags file as different

[biosmonkey]

About 2 years ago I posted a question regarding whitespace inside comments causing files to be shown as different. This is still tripping me up in my workflow. Every single day.

The issue: when there is leading or trailing whitespace inside comment blocks (or // to end-of-line), BC treats that as a difference (if comments are set to be important, which I do want them to be).

So, for example

File1:
// this is a test

and

File2:
//this is a test<space>

will flag the file as different, despite leading/trailing whitespace being unchecked.

The same thing happens with multi-line comment blocks
File1:
/* this is
a test */

File2:
/* this is
<space>a test */


The reason this is happening is that the Comment grammar is taking precedence over the Default text settings, so the leading/trailing is considered part of the character "stream" from beginning to end.

This is really annoying and cumbersome when trying to sync code from other developers who fail to strip out these characters.

Basically, I want comments to be important, but leading/trailing whitespace on individual lines should not be.

Can we treat leading/trailing space characters separate from grammar definitions?

[Aaron]

Thanks for the feedback. Unfortunately, defining whitespace importance within a grammar element is still on the wishlist. In the meantime, the best solution might be to delete the current grammar elements for Comments. This would revert the comments to Default text and allow the whitespace to be ignored, but you would lose Comment coloring.

[bsevers]

This is also an issue I've been running into. I'd like for comment differences to be considered important, but not if whitespace characters (leading, trailing, or embedded) are the only difference. Hopefully support for this is added soon! Keep up the great work.

[RufusVS]

+1 on trailing whitespace ignore

I have this issue as well.