Important notice

[Tim]

The next release (planned for Wednesday) will break some of your persistent settings. We’ve repositioned some concepts, and wherever a setting has been moved it will revert to factory defaults. Here’s what will be affected:

1) Several settings have been moved out of File Formats and into Session Settings. File Formats still describe the syntax of a file, but Session Settings now control how they are compared (whether or not an element is important to a comparison, if line endings should be compared, etc).

- Importance, by element
- Whitespace importance
- "Orphan lines always important"
- Compare line endings
- Scope of merge conflicts
- Alignment settings (eg. skew tolerance, "never align mismatches")
- Replacements

2) Whether or not thumbnails scroll is now set once for all file session types, rather than for each one independently. The new setting is under Tools | Options | File Views.

3) The "Use Tabs" setting that was under Tools | Options | Text is now in File Formats next to the Tab Stop setting.

4) Comparison Priority is now a tweak (Ctrl+Shift+T).

[Marjolein Katsma]

Tim,

The next release (planned for Wednesday) will break some of your persistent settings. We’ve repositioned some concepts, and wherever a setting has been moved it will revert to factory defaults. Here’s what will be affected:

1) Several settings have been moved out of File Formats and into Session Settings. File Formats still describe the syntax of a file, but Session Settings now control how they are compared (whether or not an element is important to a comparison, if line endings should be compared, etc).

- Importance, by element
- Whitespace importance
- "Orphan lines always important"
- Compare line endings
- Scope of merge conflicts
- Alignment settings (eg. skew tolerance, "never align mismatches")
- Replacements

I'm getting a bit lost here - while most of this list seems sensible, I don't see why both Importance and Replacements would be moved out of File Formats: both are totally language-specific because they deal only with elements as defined for a specific language in a File Format. This even means (until now) you could define different formats for a language with different importance settings and/or replacements, and switch between them for different views. All that power would now be lost.

I cannot even imagine how these would work without having the language-specific entries for these, since sessions are not language-specific.

Please revert!

[Tim]

Thanks for your feedback but sorry, we don’t agree. We feel it’s the File Format’s job to define grammar elements and the Session’s job to say whether differences in those elements are important to the comparison.

Sessions are task-oriented. If I’m doing code review (across different file types), I may want to ignore differences in comments, whether they are Delphi source comments or XML comments. I may also have a special session for pushing code changes from an English project to a German translation. In that session I need to ignore changes in literal strings, again regardless of file type.

And Replacements are very task-oriented. The typical example is reviewing code where a common identifier has been changed. I may want to study all the changes other than where TBigWidget was changed to TLargeWidget, so I create a replacement that says TBigWidget = TLargeWidget. I don’t want that to affect my other stored sessions. (And creating custom File Formats for this one-time purpose would be awkward.)

[Michael Bulgrien]

We feel it’s the File Format’s job to define grammar elements and the Session’s job to say whether differences in those elements are important to the comparison.

I agree with the changes in Build 442

(until now) you could define different formats for a language with different importance settings and/or replacements, and switch between them for different views. All that power would now be lost.

But I also agree with Marjolein that we've lost some usefulness. Please consider allowing a user to save the current settings in a named "template", then allow the user to apply a setting template to a session (or switch between two different setting templates as described in Marjolein's post).

[Marjolein Katsma]

Extremely unhappy now

Thanks for your feedback but sorry, we don’t agree. We feel it’s the File Format’s job to define grammar elements and the Session’s job to say whether differences in those elements are important to the comparison.

The problem is that the "those elements" in there are language-dependent: elements in one File Format do not even occur in another. For each language I have different settings for importance, and they relate to only those elements that are actually used in that language.

Do I have to define comparison rules now for each new session? And for each plow through the whole combined list of elements (and is it still unordered?), including elements that are not even used in comparison and thus do not even have a relative importantce? How do I now handle the fact that whitespace in HTML is never important while it is always important in PHP because we have coding guidelines that must be followed? Those things have absolutely nothing to do with sessions. Having to create new comparison rules for each new session sounds like it will be a whole lot of needless extra work - or can I at least copy all comparison rules en bloc from an existing one?

(Those are questions because I'm actually now postponing installing the new build so I can at least go on using 441 as long as possible!)

Sessions are task-oriented. If I’m doing code review (across different file types), I may want to ignore differences in comments, whether they are Delphi source comments or XML comments. I may also have a special session for pushing code changes from an English project to a German translation. In that session I need to ignore changes in literal strings, again regardless of file type.

You may. But I do not. Comments in one language may have different importance than comments in another. Whitespace in one language has different importance than in another (and if I need a special version, I just create a variant File Format which I can use without affecting my normal comparisons across sessions).

My sessions are not task-oriented but location-oriented; for a whole collection of sessions I still do the same things for the same languages and have the same need to switch between grammars to get different views (with their own elements, comparison rules and replacements) while working on a file.

It seems you're looking too much at your own use cases and forget to consider others.

The type of comparisons and edits I do for different languages stay constant for each of those languages and are totally independent of sessions. If I need special comparisons, or different views, I create different grammars or variants, so I can switch between them for a different view (for instance switching between HTML and PHP to get code highlighting for one language and not the other in the same file while working on it).

Besides, I can switch between File Formats while I'm working on a single file to get different views - I can't switch between sessions while doing that!

And Replacements are very task-oriented.

Not for me they aren't - absolutely not! I actually have different grammars for the same language, with different replacement rules (or rather, replacements in one, and not the other) just so I can switch between those grammars to get different views of the same comparison, and having different things highlighted. That was in fact my only use of replacements (so far), and was totally independent of sessions - and that has now become impossible: with replacements tied to a session I simply can no longer do this "view switching" at all. I was really happy with the Replacements functionality when I first figured what I could do with it in Cirrus - now they have become totally useless to me.

The typical example is reviewing code where a common identifier has been changed. I may want to study all the changes other than where TBigWidget was changed to TLargeWidget, so I create a replacement that says TBigWidget = TLargeWidget. I don’t want that to affect my other stored sessions. (And creating custom File Formats for this one-time purpose would be awkward.)

That's one use case, and it may help you. It is in no way my typical example.

And while in general, creating custom File Formats is painful (I haven't looked yet if there is any improvement now), creating a special one just for a set of replacements is of course a doddle compared to creating a whole new FF: just copy your existing File Format and add the replacements: you can then switch between the two to see/not see those changes highlighted (which also helps in locating where changes have not taken place yet).

A special File Format like that does not affect any sessions at all, because you only choose that special File Format when it's needed - in different sessions, at different moments, for different files. That's what I was doing - but my use cases are no longer covered, so the once-powerful replacements have now become totally useless, making part of my work harder again, just when I had found something to make it easier.

Maybe next time when you're planning such a major functionality change you could ask us first how we are using that feature?

Can you please tell me how I can continue to use build 441 after this week so I can still use my comparison and replacement rules? Yes, bugs and all, I'm serious. I really, really need the functionality for importance and replacements the way it was: language-dependent. I want to continue to use that.

I'm not just unhappy, I'm actually very upset while I'm typing this.

[Zoë]

Marjolein,

Please at least try 442 when you have a chance. If you install them in different directories and run one in single-directory mode they won't interfere with each other. Plus, I fixed up some issues with the SFTP support and I'd hate to see them go to waste.

To start with, we're well aware that we've lost some flexibility with the changes we've made. That's intentional. Designing rules and file formats has been a constant struggle between easy of use and power, and we're trying to stay somewhere in the middle. In your case you've been pushing the formats as far as they'll go and still asking for more, so it's quite possible that we're not going to come up with a solution that's perfect for you. We have to weigh the expertise of all of our other customers as well and the vast majority of them can't even make custom rules in BC2's interface.

Do I have to define comparison rules now for each new session?

There are two levels of "rules" in session settings right now: (1) the "Session Defaults", configurable from the Home view and by checking the "Update session defaults" checkbox in the Session settings dialog, and (2) the settings for the file you're currently comparing. Any time you launch a new file comparison it uses the settings from (1) and you can override it for a particular file comparison using (2). We are working on adding at least one more level of indirection for all of the file comparisons launched from a particular folder comparison.

Do I have to define comparison rules now for each new session...including elements that are not even used in comparison and thus do not even have a relative importantce?

The session defaults (and eventually the directory comparison defaults) show a combination of all of defined elements. A particular file comparison only shows elements defined in the format(s) involved in the comparison.

How do I now handle the fact that whitespace in HTML is never important while it is always important in PHP because we have coding guidelines that must be followed?

Whitespace included in an element is the same importance as the rest of the element, so if you need it to be important add it as an explicit element type and make it important. That's what we're planning on doing for the Python format for leading whitespace.

Comments in one language may have different importance than comments in another.

Why would comments in different languages have different importance?

for a whole collection of sessions I still do the same things for the same languages and have the same need to switch between grammars to get different views

We may be able to handle this some other way. As I said above, there are multiple layers being added to the session/rules objects separate from the file formats. Michael's template idea is one possibility we may explore; at least using an existing session's settings without it's paths as a template is something we're considering.

One thing to keep in mind is that our goal with HTML is to eventually have a parser that understands HTML, PHP, CSS, etc and can compare them without significant user configuration. Once that's done it's going to consider comments in any of the sublanguages as comments, with similar behavior for the other parts. It's probably going to conflict with what you're trying to do.

The type of comparisons and edits I do for different languages stay constant for each of those languages and are totally independent of sessions.

Our simplification simply makes formats and languages synonymous. Download 442 and give it a try. Consider what you're doing in context and imagine how it would work once we add file compare settings on a per-folder-compare basis, possibly also the ability to pick a named session and apply its settings to your current comparison. With those changes what doesn't work for you?

[Michael Bulgrien]

Template-aware formats

Michael's template idea is one possibility we may explore

Another idea that might alleviate Marjolein's pain:

Allow a user to associate a default settings template with a file format. This would preserve the new simplified functionality for the less technical masses. Advanced users like Marjolein could associate a set of session settings with her file formats so that they load together when a new session of a given file type is launched. I may be mistaken, but I am guessing that this would give her almost almost as much flexibility as she had before without the Scooter team needing to deviate from the chosen direction for the product.

[Tim]

Let's post further suggestions and comments under File Formats vs Rules.

Thanks

[Michael Bulgrien]

Continued under File Formats vs Rules.