Important notice

[Michael Bulgrien]

We’ve repositioned some concepts, and wherever a setting has been moved it will revert to factory defaults.

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).

Continuation of discussion from General Discussion:

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.

[Marjolein Katsma]

(continuing the thread in General Discussion)

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.

I don't know what you mean by "single directory mode" but I now have each in its own directory, and a separate data directory for each, with a batch file to copy the data into the "common" directory, start the app, and afterwards copy the data back to its own data directory. The only thing that doesn't cover is the Explorer shell extension (I did not manage to make a separate one for 441) so I extended the batch file a little to make sure the "common" data directory always contains 442 (or later) data files unless I'm running 441. Now I "just" have to take care to not use the shell extension when I'm already running 441. This "works". As to SFTP support I'll have to see what was changed - maybe I can use 442+ just to copy or synchronize files and use 441 for actual file comparison and editing.

Yes, I have tried 442, and for (text) file comparison it's no longer usable for me, in fact, even worse than I feared.

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.

More than "some" flexibility is lost. I also don't see how it's "easier" or "simpler" to have language-dependent rules now distributed in three different types of places - it just makes things incredibly hard to keep track of, because in considering how the program "behaves" when comparing files of a particular language you have to juggle three different locations in your head.

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.

It seems to me one would need far less expertise if all settings for a language were defined in a single location - as is the case now in 441 - regardless of how one makes use of those settings (which is where the expertise comes in, not with the location of the settings).

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.

It means that as of 442 you have to [b]override settings for every single file comparison[b] and do it over, and over and over again when switching between two grammars: the elements selectable in the defaults are the pre-defined elements only, plus whitespace settings which are useless at this level when they need to be different for different languages (which is always the case for me); but none of the user-defined elements are available in the default session settings. When you then open a file with a defined grammar that has user-defined elements, all of those are suddenly considered "important" - there is no way to define a default for them. When I then switch between PHP and (X)HTML, the elements for each are those as defined for each of those grammars (but always all "important" after each switch) - there is no way I can make a setting that combines those elements so it is remembered. Also, for HTML whitespace is not important, while for PHP (because of our coding guidelines) it always is, but this setting is remembered when switching between the two file formats, so I keep having to toggle them on and off.

That already makes it unworkable for even a single file. Add to that the fact that these settings are not saved anywhere unless I save the single file comparison as a session; but I'd need the same settings for hundreds of files across dozens of saved (folder compare) sessions, and there is no way to even copy the settings from one (file compare) session to another. Clearly, that is just not usable at all: merely saving hundreds of single-file comparisons as sessions and manually configuring the comparison rules for each would take an enormous amount of time - even assuming I could have a combined set of rules for HTML and PHP. The irony is that in 442 now the comparison rules still are language-dependent (you can get at only the elements for that language) but this makes using these rules even harder than if they would not be and you'd get the complete list of elements instead. With 441 that problem doesn't exist, because they are language dependent and automatically used for each language even when switching. Surely that is simpler?

(continued in next message)

[Marjolein Katsma]

(continued)

The session defaults (and eventually the directory comparison defaults) show a combination of all of defined elements.

Alas, they don't. Session defaults show only the predefined elements, but none of the user-defined elements. Which, again, makes it even worse than I imagined because I did imagine getting the whole list of elements. I don't see how directory comparison defaults would even help (there are still hundreds of directories to compare, most with files of various types) - unless you mean defaults for folder comparison sessions, which might help a little, provided the settings can be copied from one session to another.

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.

You lost me there. Then what is the "embedded whitespace" pseudo-element in session default and individual file comparison rules?

Why would comments in different languages have different importance?

Depends on your usage.

In HTML, comments (specially formated or not) may indicate which sections are editable or not: those comments are of course important because changing them (to something else) or removing/adding them makes an enormous difference to how a web application behaves. In other applications, comments may control templating functions. There are even (in the Internet Explorer's world) "conditional" comments which look like normal comments to the rest of the world but make enclosed code conditional for IE. All such types of comments would usually be marked as important (provided they are defined in a grammar). All other comments would then be unimportant - at least in relation to those special comments, but importance is always relative.

In PHP (and a whole number of other languages, to begin with Java), there are specially-formatted comments that are used to generate documentation and even tutorials. (For an example, see the phpDocumentor manual which is generated with phpDocumentor from phpDocumentor source comments!) A PHP-aware grammar would thus make a difference between such phpDocumentor (or PHPdoc, a variant) comments and "other" comments, where the first would be important, while the rest would be (again, relatively) unimportant.

If you have fairly primitive grammars though, these "collapse" so that comments in HTML are (usually) unimportant, while comments in PHP are (usually) highly important.

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.

I already see the current (442) set up as essentially more complicated than 441; adding extra layers (yet more places to define rules) would complicate things even more. But a "template" already exists: the comparison importance rules (and replacements) as defined in the file formats - with the added advantage of keeping things in one place (with different whitespace rules for different languages) instead of spreading it out over many so you no longer can tell what comes from where or decide what to define where.

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.

I now have (X)HTML, CSS and PHP nicely separated so I can switch between them and have different parts of the same file highlighted. They can use more refinements, but the separation is entirely intentional. I would not use a grammar that combines all three (or even two).

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.

Exactly. They are not "sub languages" either, even though they may occur in a single file. And would you add JavaScript, VBscript and PerlScript as well? Where do you stop?

I do not even see how you can combine just the three you mention, unless you use a simplified grammar - which would be usable only for a cursory look, but not for actually working with each of the three languages (four, if you make a necessary distinction between HTML and XHTML). I just hope your plans won't make my carefully separated grammars impossible!

Our simplification simply makes formats and languages synonymous.

Apart from the fact that it's not a simplification, it doesn't do that either.

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.

Because I need to work with hundreds of folders, per folder compare would still be unworkable, even if I could copy settings from one folder to another. If it were per folder-compare session it might be somewhat workable if and only if I can copy settings en bloc from one session to another, instead of having to define all the same rules all over again for each session.

With those changes what doesn't work for you?

With all rules spread out over different places and "levels", even totally language-specific ones, it would be a lot more complicated than 441, with all importance rules and replacements in one place; it would also be more work to set up and maintain (define just one new language element - and you have to change it in how many places?). And all for less power and flexibility.