Despite all colors & effects switches, I find it hard to see which side empty lines are on. If the "Show line numbers for text files" option is on, it's pretty clear. But if you turn that off in search of display real estate, I'm stuck. If the difference between the two panels is just an empty line (or multiple empty lines), nothing shorter than turning the numbering back on seems to reveal which side the block is on. Or am I overlooking something?
Actually, while writing this, I found a simpler way: right-click the block on either panel, and if the Delete menu item is enabled, that's where the empty lines are.
But I would like it still easier. For instance, let View Whitespace turn up symbols for CR and LF characters.
Hard to identify empty lines
I though you meant that you couldn't see which blank lines were ignored when "Ignore Blank Lines" option was used.
OK, so you basically need a feature to show linebreaks but only for real (non-padding) lines -- when View Whitespace is used. But you still will need to make some change in your viewing options (use View Whitespace) to see real blank lines. Will it be much different from using Show Line Numbers in the current version?
OK, so you basically need a feature to show linebreaks but only for real (non-padding) lines -- when View Whitespace is used. But you still will need to make some change in your viewing options (use View Whitespace) to see real blank lines. Will it be much different from using Show Line Numbers in the current version?
psguru
PrestoSoft
PrestoSoft
Okay, now I think I may have confused the entire public of this forum 
. I was confused myself about the many Color options. The difference is glaringly obvious. Left-only empty blocks are marked with the "Deleted items" background and hatch, while right-only empty lines appear as "Added items". I thought these options had to do with adding and deleting blocks within ExamDiff... I could have seen that spelled out turning the "Diff Combo Box Bar" back on.
As to viewing linebreaks, I think it would be still quite useful for another reason. If there is a difference in linebreaks only, either you'd want ExamDiff to ignore it (which is absolutely supported by the new Ignore option), or you want to know what the difference exactly is: what is the general linebreak style of both files, and what is the linebreak style on the line that's different. You'd see it all if Show Whitespace would reveal all linebreaks in detail, just like it does for tabs and spaces.
. I was confused myself about the many Color options. The difference is glaringly obvious. Left-only empty blocks are marked with the "Deleted items" background and hatch, while right-only empty lines appear as "Added items". I thought these options had to do with adding and deleting blocks within ExamDiff... I could have seen that spelled out turning the "Diff Combo Box Bar" back on.As to viewing linebreaks, I think it would be still quite useful for another reason. If there is a difference in linebreaks only, either you'd want ExamDiff to ignore it (which is absolutely supported by the new Ignore option), or you want to know what the difference exactly is: what is the general linebreak style of both files, and what is the linebreak style on the line that's different. You'd see it all if Show Whitespace would reveal all linebreaks in detail, just like it does for tabs and spaces.
Yes, because View Whitespace has a keyboard and toolbar shortcut, whereas the other is (for the better) burried deep down among many others in the options tree.Will [View Whitespace] be much different from using Show Line Numbers
I'll add the following item to the wish list:As to viewing linebreaks, I think it would be still quite useful for another reason. If there is a difference in linebreaks only, either you'd want ExamDiff to ignore it (which is absolutely supported by the new Ignore option), or you want to know what the difference exactly is: what is the general linebreak style of both files, and what is the linebreak style on the line that's different. You'd see it all if Show Whitespace would reveal all linebreaks in detail, just like it does for tabs and spaces.
Show linebreaks when View Whitespace option is used
I knew you'd say that. Yes, you are right, it's an extra click: Ctrl+J, then click on Show Line Numbers (note that EDP remembers the last Options page you used).Yes, because View Whitespace has a keyboard and toolbar shortcut, whereas the other is (for the better) burried deep down among many others in the options tree.
psguru
PrestoSoft
PrestoSoft
A useful complement to the other new options concerning linebreaks, IMO. But having thought it over, there is a way to make it easier to interpret text file differences in general.Show linebreaks when View Whitespace option is used
Currently the background color/hatch options for the "Added Items" and "Deleted Items" work both on the side where the text actually is, and on the empty filler block inserted in the opposite pane. So the filler appears as a highlighted part of the file in the opposite pane. That's wrong. The filler doesn't represent any part of the file, it's just an artifact of the window aligning its panes. So I put forward that the filler blocks should look like the window border - or at least a separate, more neutral color than the actual block on the opposite side.
Now if you think this is just adding even more background colors to a sometimes overwhelming palette, I can counter that. A normal compare would just give you two special colors on each pane just as now. When the colors tend to overwhelm, i.e. when you start merging files, you can do with less.
Currently, if you copy let's say a "Added" item from right to left, it is shown as "Newly inserted text". If you "copy" it in the opposite direction (so delete it on the right), it appears as a "Deleted item". The former confuses with manually edited items, the latter with "Deleted items" already present after comparison (so things that weren't there in the first place - are you still there?) With the aforementioned scheme, you could simply copy the background of the item copied along with the text.
So do you want to have a new color setting in Options | Display | Colors, or to use some hard-coded color for filler lines? Either way, having same background colors in both panes seems more symmetrical. Having yet two different background colors in the same horizontal slice may really overwhelm the user (although you argue that it won't).Currently the background color/hatch options for the "Added Items" and "Deleted Items" work both on the side where the text actually is, and on the empty filler block inserted in the opposite pane. So the filler appears as a highlighted part of the file in the opposite pane. That's wrong. The filler doesn't represent any part of the file, it's just an artifact of the window aligning its panes. So I put forward that the filler blocks should look like the window border - or at least a separate, more neutral color than the actual block on the opposite side.
This is not completly accurate. Copying "Added" lines from right to left is indeed treated as inserting new text in the left file (which it is). Copying in the opposite direction also shows as newly inserted text but without text (background color only). It is probably arguable whether the latter is in fact inserting new text but that's how the application has worked so far.Currently, if you copy let's say a "Added" item from right to left, it is shown as "Newly inserted text". If you "copy" it in the opposite direction (so delete it on the right), it appears as a "Deleted item".
psguru
PrestoSoft
PrestoSoft
Either would suit me, but hard-coded sounds worse than it should. A suitable Windows color would be fine (Application Background or Active Window Border or so).a new color setting in Options | Display | Colors, or to use some hard-coded color for filler lines
Incidentaly, while EDP does use the Windows "Window" color for the completely empty space below the end of both files, if you select a non-solid hash, only the lines of the hatch are drawn in the selected background color. The dominant background color is, it seems, a hard-coded white, and not the "Window" color. It's a lot nicer to the eyes to make the "Window" color a little darker than fully saturated white (as you can see on the backgrounds of this forum, for instance). But then in EDP any hatch ends up looking ugly.
Since we disagree on color schemes, how about hatches? I don't think a hatch behind text is very helpful even for the color-blind. If the hatch would appear only on the side where there is no text, and with hatch lines drawn in text color and the background as selected, one stone would kill two birds!
I do, but only if you limit the total number of colors to 2 as I would. Suppose there were 4 background colors to set up (added items left side; added items right side, deleted items left side, deleted items right side). I would set the same pair of colors for Added and Deleted but reversed for left and right of course. Currently each slice has a single color throughout (initially), from which you can see the slice is added or deleted (to refer to the original topic of this thread, sometimes it's the only easy way). But the color isn't very informative as I'll illustrate in another thread. In my dream world, each added/deleted slice would show the same 2 colors and you see what the change is about by the side each color is on.Having yet two different background colors in the same horizontal slice may really overwhelm the user (although you argue that it won't).
Oops, I was misguided by the first 3.4 beta. The latest beta works as you described, which is very reasonable to me.Currently, if you copy let's say a "Added" item from right to left, it is shown as "Newly inserted text". If you "copy" it in the opposite direction (so delete it on the right), it appears as a "Deleted item".
If by "dominant" you mean the color of "Identical" elements, it's customizable in 3.4.The dominant background color is, it seems, a hard-coded white, and not the "Window" color.
Could you elaborate?But then in EDP any hatch ends up looking ugly.
The problem will be if, say, "Added" elements are already defined to use hatches in Options | Display | Colors.Since we disagree on color schemes, how about hatches?
psguru
PrestoSoft
PrestoSoft
I don't. I mean the color dominating the background of any item you set a hatch on. If, say for "Identical items", you change the hatch from the default solid to a non-solid hatch, the background of those items becomes almost entirely white, with thin hatch lines drawn on top. You can only control the color of these thin lines and that doesn't make much difference. From what I'm seeing, either:If by "dominant" you mean the color of "Identical" elements
- the hatches should be reversed (to become almost solid)
- and/or the color shining through the hatch openings should be the Windows Window background or a customizable color
This is a bug (or rather an omission). You are right, the background of the hatched items should be the Window background as defined in the Control Panel. This will be fixed in a later 3.4 Beat build.I don't. I mean the color dominating the background of any item you set a hatch on. If, say for "Identical items", you change the hatch from the default solid to a non-solid hatch, the background of those items becomes almost entirely white, with thin hatch lines drawn on top. You can only control the color of these thin lines and that doesn't make much difference. From what I'm seeing, either:
- the hatches should be reversed (to become almost solid)
- or the color shining through the hatch openings should be the Windows Window background or a customizable color
[/list:u]
psguru
PrestoSoft
PrestoSoft
Based on this, I developed a new point of view (pun intended). Such a slice suggests the contents unique on one side flow into the other. So, let's color code both files entirely. Instead of left & right, added & deleted, let's talk blue and red.psguru wrote:Having yet two different background colors in the same horizontal slice may really overwhelm the user
This is the default EDP view:
This is with Changed items colored differently:
All items with the color touch:
Still not really convincing to me. Maybe hatches instead of color variations would help, but only if the selected background dominates the hatches - not if it's mostly white or Windows background.
To be continued...
Last edited by zweistein on Sun Sep 18, 2005 11:45 pm, edited 1 time in total.
