End-of-file hash marks

[Michael Bulgrien]

While I was one of the ones that thought the end-of-file cross-hash looked odd, I don't think the current implementation is quite right either. The absence of a regular hash at the end of the shorter file makes this section inconsistent with null lines elsewhere in the file.

Instead of this:


I would prefer this:

[Michael Bulgrien]

It would also be consistent with BC2:

[Zoë]

Did you manipulate the no-hash screenshot? The current release has x crosshatches after the last lines of a file, which on my system is the * line on the left and the three empty lines on the right (image attached).

[Michael Bulgrien]

Did you manipulate the no-hash screenshot?
The current release has x crosshatches after the last lines of a file

Actually, in build 440 the "x" crosshatching became a Tweak. The no-hash image is an unmanipulated screenshot of build 443 ("Use crosshatching for lines beyond end of file" is disabled in the Tweaks dialog.)

When the "Use crosshatching" tweak is enabled, the "x" crosshatches are on all lines. That is a problem, too, in my opinion. Only the last line should be an "x" crosshatch. Whether or not crosshatches are visible, null lines in a change section should be represented consistantly throughout the file with normal "////" hash marks as they were in BC2. That is what I was trying to point out with the above screenshots.

[Chris]

Michael,

The text beyond end of line coloring will be changed in our next release, build 445.

[Michael Bulgrien]

Thanks Chris. I'm not sure what you mean...this thread wasn't about color at all. It was requesting consistency in the use of hash marks in difference sections (to use the "////" hash marks instead of the "XXXX" crosshatches in difference sections at the end of the file as it is in BC2).

For example, create a text file that consists of several empty lines (just carriage returns). Create another file that just consists of a single carriage return. Compare them in BC2. Compare them in Cirrus.

Crosshatches are fine after the end-of-file markers...but as illustrated in the screenshots above, the end-of-file markers are not visible in the difference section. Cirrus should treat the null lines in a diff section as if they were inserted before the actual end-of-file marker.

When the crossthatch tweak, line numbers, and visible whitespace are all turned off, the diff section at the end of a file looks like a bunch of blank lines instead of the non-existent (null) lines that they are. This is not the case in BC2, and should not be the case in BC3.

[Michael Bulgrien]

Chris,

I've checked out the new functionality in build 445. I don't like it. The variety of situations that you can hit at the end of a file makes it feel weird and inconsistent. Why can't you just keep it the way it was in BC2?







Of all of these, the last seems least weird. The end-of-file markers match up (as they logically should). Whether the actual lines of text are displayed at the top or the bottom of the shorter file, I would prefer end-of-file markers that are paired and the empty space between filled with "////" hash marks. As I've mentioned before, this would also be consistant with BC2.

[Tim]

The current release is a test of using a solid color by default for comparison lines beyond the end of a file, rather than the crosshatch pattern (and the tweak to make it solid white).

BC2's design is deficient, since it doesn't distinguish between gaps in a file and space beyond the end of a file. This is important in some cases.

For the gaps, BC2 lets you set a solid color of your choice or use the diagonal hash pattern. I don't want to over-design this, but I was considering restoring that choice in Cirrus and adding a similar one for beyond end of file (using a different pattern).

Internally, we don't agree that "ButtonFace" is the best choice, so I'll undoubtedly be tinkering with this again. I've been meaning to try a different pattern that is less jarring than the crosshatch but still distinguishable from the gap pattern. Perhaps I'll have something different in the next release.

[Michael Bulgrien]

BC2's design is deficient, since it doesn't distinguish between gaps in a file and space beyond the end of a file. This is important in some cases.

Interesting... I never found BC2 deficient in this area. I don't understand the need to differentiate between gaps in a file and a gap at the end of a file. Both are the absence of data when paired against the opposite file.

Technically, if the end-of-file markers are always aligned on both sides of the compare, all gaps are gaps within the file and there is no need to differentiated them from space beyond the end of the file... (there will never be space beyond the end of a file if the end-of-file markers are kept aligned on both sides.)

If there is a convincing reason why keeping the end-of-file markers aligned would not be a sound design, I would love to hear it. Otherwise, I would prefer to be able to configure BC3 to keep the end-of-file markers aligned so that I only have one kind of gap, and only one kind of hash to represent it.