Moving from BC2 to BC3 - having a few problems

[biosmonkey]

I am a long time BC2 user who has recently been trying to use BC3 and I am running into a few problems.

1) Synchronized files not refreshing in list

In general, I almost always use rule based comparisons with Show Differences and Ignore Unimportant Differences selected. I have noted sometimes that when I do a file compare and manually merge all changes from one file to another, then hit ESC to go back to the folder view, the file does not disappear but instead will show the curvy equal sign (sometimes it will show the binary equal too). If I press F5 for a quick refresh, it will go away, but it does not do this automatically. It seems that if there is some unimportant difference left behind, the file remains in the list despite the toggle setting for Ignore Unimportant Differences?

2) Whitespace in comments marked as differences

I added a file format for Actionscript, and added a multiline comment /* */. I do not want to ignore comments as I need to keep my asdoc/function headers synchronized.

However, when using a multi-line comment, it appears that BC3 is *not* ignoring the end-of-line whitespace, which is unnecessarily flagging an extraneous EOL whitespace as a difference.

I have noticed also that the same problem exists with single line // comments. If comments are important, any EOL whitespace is flagged as a difference.

Leading space behaves a little differently. For single-line comments (//) leading space is properly ignored. However, for multiline, it is not...leading space is flagged as well.

So, if I make comments unimportant, I lose the syntax highlighting and it looks horrible, especially with the multiline. If I make comments important, I get a lot of false differences.

Since leading and trailing whitespace are line-based entities (whereas embedded whitespace is an inclusive text entity), should these not be stripped/ignored before BC attempts to determine if the text itself is a multiline delimited grammar element?

3) (Minor quibble) When selecting "Align to" or "Compare to" the text changes to a hard-to-read green. I could not find where to change this?

[Aaron]

Hello,

1) This is intentional behavior designed to keep files from just 'disappearing' when going between views. You don't need to Full Refresh or Quick Refresh to hide them; if you click the Display filter again it should re-apply and instantaneously remove them from view.

2) Whitespace defined within a grammar item is part of that grammar item. Are you referring to trailing whitespace (such as spaces or tabs) or End of Line characters (the very last character marking the end of line)? You can enable Show Whitespace to see them on the screen; a fullscreen screenshot of the comparison may help. If the grammar includes the trailing whitespace, it is technically part of the grammar and will follow that importance. You can click the blinking cursor into your text, and the current detected grammar is shown in that pane's bottom status bar, next to the line and column position information.

We do have a Tweaks dialog (Ctrl+Shift+T) that has an option in the Text Views tab "Show syntax highlighting on difference lines", which will still show the syntax highlighting on text that is not actually different. Does this help?

3) Align With and Compare To commands in the Folder Compare do make the text a bright green color while waiting for the following input. We don't have a method for customizing that color. One workaround I can suggest right away is Right-Clicking on the second file; this will show the first file name as part of the context command. How does this work for you?

[biosmonkey]

Hello,

1) This is intentional behavior designed to keep files from just 'disappearing' when going between views. You don't need to Full Refresh or Quick Refresh to hide them; if you click the Display filter again it should re-apply and instantaneously remove them from view.

2) Whitespace defined within a grammar item is part of that grammar item. Are you referring to trailing whitespace (such as spaces or tabs) or End of Line characters (the very last character marking the end of line)? You can enable Show Whitespace to see them on the screen; a fullscreen screenshot of the comparison may help. If the grammar includes the trailing whitespace, it is technically part of the grammar and will follow that importance. You can click the blinking cursor into your text, and the current detected grammar is shown in that pane's bottom status bar, next to the line and column position information.

We do have a Tweaks dialog (Ctrl+Shift+T) that has an option in the Text Views tab "Show syntax highlighting on difference lines", which will still show the syntax highlighting on text that is not actually different. Does this help?

3) Align With and Compare To commands in the Folder Compare do make the text a bright green color while waiting for the following input. We don't have a method for customizing that color. One workaround I can suggest right away is Right-Clicking on the second file; this will show the first file name as part of the context command. How does this work for you?

Hey Aaron, thanks for the response.

1) But removing the file from view is exactly what should happen (and this is how BC2 behaves) because I explicitly set the view to "differences only". Therefore, if I manually merge differences in file view such that the file is now the same, it *should* be removed from the list. I do not want to have to click an extra button to reapply the view that I have already chosen.

And, not only that, but the behavior is NOT consistent. After merging in file view, some *will* be removed from view. But others will not - even when BC3 determines they are a binary match.

This behavior is confusing and does not make sense to me. If this is actually intended, would you please consider an option for those that find it undesirable, perhaps in your tweaks dialog e.g.[*] Reapply session view filter when exiting file view


2) What I mean is that leading and trailing whitespace on lines is not being ignored when inside a delimited grammar item, even though I have these items unchecked as important. So, if I have defined a block comment as /* to */, BC won't flag a file as different if one has a trailing space at the end of a line in between the delimiters.

I understand the logic that a delimited grammar item is essentially treated as a text stream from point A to point B, and anything within that stream, including EOL whitespace, is considered important.

However, to me, leading whitespace and trailing whitespace are characteristics of the file structure, not the contents. In other words, their importance should be honored regardless of how grammer items are defined.

What I would like to suggest, then, are two additional options in the Delimited grammar item creation dialog for [x] Ignored leading whitespace and [x] Ignored trailing whitespace. This would still allow the creation of, say, syntax-highlighted comment blocks, but ignore the leading/trailing whitespace within the comment.


3) Not a big deal, just wondered if it could be changed.

[Aaron]

Hello,

1) It is intended behavior for the files to stick around rather than disappear from view, but they should show up with the proper status ("equal"), and they should always show up unless a refresh is triggered, either by manually triggering the refresh or performing an action that requires it (such as a manual alignment.) Could you go into more detail on the cases when the files do disappear? Are you performing an action or clicking a button when it occurs?
I'll ask around about bringing the BC2 behavior back as an option. If there are other users in the forum that feel similarly, please feel free to post here and let us know.

2) Dealing with whitespace within a grammar definition is on our Customer Wishlist. I'll add your example notes to the entry. When one of our developers does decide to take a stab at this, I would expect this to be a large change, and would not be soon coming. The workaround would be to remove the grammar element from the file format, reverting the text as Everything Else, allowing it to be important while whitespace can be marked as unimportant.

3) Sorry, that color is not configurable in the current version of BC3. Have there been any other colors you hoped to configure but found you could not?

[biosmonkey]

1) I do not know exactly under what conditions or files that it occurs, but as I said, some files disappear and some stay - even when performing the same operation (ie compare in file view, manually merge lines/blocks, then escape out).

I respect that this is your application and you can implement whatever intended behavior you wish. Unfortunately, I am sorry to say that I find it undesirable, and bad UX. If you are going to give the user the different view options ( Show differences, show no orphans etc), AND the user chooses to set the view to "Show (only) differences", then the instant you leave a file in the list that is actually the same, the view becomes meaningless. Choosing "Show differences" means -> "I do not want to see files that are different".

As I said, I suppose persistent files may be useful to some, but I really, really hope you add this as a check-able tweak option in a future build.


2) Thanks. I tried removing the comment-block grammar element, however, this results in text inside the comment being color coded by the other syntax elements. It then becomes a little tough to visually separate the comments from the code. For now I am just dealing with the problem and merging the whitespace differences when encountered...the syntax highlighting is very useful to help see important changes. However, it does make the merging process a little difficult when dealing with source files that are edited by multiple users - even if I "clean up" the file someone else may add that one additional trailing space inside a comment block that flags the entire file as different. Then my only choice is to merge back into source control just for a single space, which is not always desirable.

So being able to ignore trailing space inside a delimited grammar element would be a great enhancement.


3) Not really, it's mainly just that bright green color being hard to read.

[bryand7]

It has been almost ten years since this issue was raised and STILL you don't have an option to ignore leading and trailing whitespace INSIDE a multi-line comment.
This is a serious problem.
If I modify my code just to change the indentation level, then BC shows ALL multi-line comments (except the first line) as changed lines.

PLEASE FIX THIS BY ADDING A NEW OPTION

[Aaron]

It has been a long standing wishlist item to add multi-level definitions or whitespace within existing elements. As it is currently, defining a Grammar includes everything as defined by that grammar, so a Comment from /* to */ includes every character within it, including the whitespace. The entire grammar is then defined as Important or Unimportant in the Session Settings.

The Trailing and Leading and Embedded whitespace options only apply to "Everything Else" elements, and aren't available as options for other defined Grammar Elements.