Feature requests & bug report

[Alexo]

Hello,

I am a long time user of EDPro. I am generally satisfied with the program but there are some missing features that make some common operations more difficult than they should be. The fact that some of those features are implemented in the GPL WinMerge program, makes EDPro a tough sell to most employers and coworkers I happen to work with at the time.

Let me elaborate:

* A file difference pane (see image here)
EDPro allows me to toggle between the vertical and horizontal splitter orientations but sometimes, a combination is better, as it shows more lines while at the same time allows viewing longer lines without the need of scrolling.
Beyond compare 3 also has this option (see bottom of this image)

* Incidentally, I use the mouse wheel for next/prev difference navigation and horizontal scrolling (as well as clicking on diff bars) takes the focus away from the diff combo box, causing the need for additional navigation. I'd prefer the focus to stay in the combo-box unless I click *inside* a file pane.

* Visual indication of moved blocks positions.
WinMerge shows it on the location pane. EDPro could show it on an expanded splitter bar.

* BUG: Some Unicode files are not recognized as such by EDPro.
For example, the attached file opens correctly in Notepad but EDPro treats it as binary.

Example.zip

Zipped Unicode text file

(484 Bytes) Downloaded 965 times

Best regards,
Alex.

[psguru]

Hello Alex,

* A file difference pane (see image here)
EDPro allows me to toggle between the vertical and horizontal splitter orientations but sometimes, a combination is better, as it shows more lines while at the same time allows viewing longer lines without the need of scrolling.
Beyond compare 3 also has this option (see bottom of this image)

We are actually working on implementing a line inspector like this in our next ExamDiff Pro release.

* Incidentally, I use the mouse wheel for next/prev difference navigation and horizontal scrolling (as well as clicking on diff bars) takes the focus away from the diff combo box, causing the need for additional navigation. I'd prefer the focus to stay in the combo-box unless I click *inside* a file pane.

I'm afraid I can't help you here. The scroll bars and diff bars are part of the comparison panes and thus bring focus to the comparison panes. To do otherwise would be somewhat illogical and would confuse all of our other users.

* Visual indication of moved blocks positions.
WinMerge shows it on the location pane. EDPro could show it on an expanded splitter bar.

We considered this while we were implementing moved block recognition, but ultimately we decided that it would clutter up the splitter bar. We feel that our current method is the cleanest way to show moved blocks.

* BUG: Some Unicode files are not recognized as such by EDPro.
For example, the attached file opens correctly in Notepad but EDPro treats it as binary.

To open this file in EDPro, click on the Browse button in the Compare dialog and select "Unicode" under Encoding. (Note: This feature is only available in ExamDiff Pro 4.0 and higher). The reason ExamDiff Pro couldn't automatically recognize the file is that EDPro uses the byte-order marks (BOMs) at the start of files to automatically recognize them, and your file has no byte-order mark.

[Alexo]

Hello psguru,

We are actually working on implementing a line inspector like this in our next ExamDiff Pro release.

Good to hear!

The scroll bars and diff bars are part of the comparison panes and thus bring focus to the comparison panes. To do otherwise would be somewhat illogical and would confuse all of our other users.

Fair enough, it wasn't a major issue for me.

* Visual indication of moved blocks positions.
WinMerge shows it on the location pane. EDPro could show it on an expanded splitter bar.

We considered this while we were implementing moved block recognition, but ultimately we decided that it would clutter up the splitter bar. We feel that our current method is the cleanest way to show moved blocks.

Allow me to argue against this decision.
Currently, there is no indication where the block moved. While it is workable if the distance is short and there is but a single moved block, it becomes unusable when you are trying to do, say, a code review of a large, freshly refactored source file. In such cases, a visual representation of the structure changes is indispensable. For example, consider a piece of code consisting of several somewhat similar blocks. If these blocks are reordered, it is very helpful to see at a glance what went where. This functionality is supported by WinMerge, Compare It!, Araxis Merge and many others. Also, you can make it optional, as you already have an "extended" splitter for manual synchronization.

Which reminds me, are you planning to integrate fuzzy search with moved block detection? It will be hard to get it exactly right but if you do it, it will truly be a killer feature!

To open this file in EDPro, click on the Browse button in the Compare dialog and select "Unicode" under Encoding. (Note: This feature is only available in ExamDiff Pro 4.0 and higher). The reason ExamDiff Pro couldn't automatically recognize the file is that EDPro uses the byte-order marks (BOMs) at the start of files to automatically recognize them, and your file has no byte-order mark.

I usually compare the files from the shell interface.
My point that many programs are able to recognized Unicode files without BOMs, even the lowly notepad does it. Adding a heuristic that will look for zeros in every other byte in a block should not be difficult and will catch some of the files. At the least, we need a way to switch to Unicode from the UI, same as we can switch between between text and binary.

Best regards,
Alex.

[psguru]

Allow me to argue against this decision.
Currently, there is no indication where the block moved. While it is workable if the distance is short and there is but a single moved block, it becomes unusable when you are trying to do, say, a code review of a large, freshly refactored source file. In such cases, a visual representation of the structure changes is indispensable. For example, consider a piece of code consisting of several somewhat similar blocks. If these blocks are reordered, it is very helpful to see at a glance what went where. This functionality is supported by WinMerge, Compare It!, Araxis Merge and many others. Also, you can make it optional, as you already have an "extended" splitter for manual synchronization.

We already have several indications of where the block moved:

1. The diff combobar shows where the block moved.
2. You can right-click on the diff bar and select Locate Matching Moved Block from the context menu, and the matching block in the other file will be displayed.

It's not simply the matter of the splitter - our two file overview panes are located at the right of each file pane, which makes it impossible for lines to be drawn between them unless the right overview pane were to be moved next to the center splitter. (We are reluctant to rearrange elements of the window, as that could make things harder for our current users.) Furthermore, this could greatly clutter the center splitter, especially if, as you said, you are comparing complex files with many moved blocks, and would impede the splitter's main role, manual synchronization.

Which reminds me, are you planning to integrate fuzzy search with moved block detection? It will be hard to get it exactly right but if you do it, it will truly be a killer feature!

At the moment, we aren't planning to do this.

My point that many programs are able to recognized Unicode files without BOMs, even the lowly notepad does it. Adding a heuristic that will look for zeros in every other byte in a block should not be difficult and will catch some of the files. At the least, we need a way to switch to Unicode from the UI, same as we can switch between between text and binary.

That's a good idea - we can try adding a heuristic algorithm like that. A switch, on the other hand, would be difficult to implement, because, unlike text/binary, there are four different options in this case (ANSI, Unicode, Unicode big endian, and UTF-8).

[Alexo]

Which reminds me, are you planning to integrate fuzzy search with moved block detection? It will be hard to get it exactly right but if you do it, it will truly be a killer feature!

At the moment, we aren't planning to do this.

"At the moment" was over 6 year ago.

I would like to voice my support for this feature. Very often a trivial change in a moved block throws the comparison out of whack.

[David.P]

Hi @all,

I've also been looking for a robust and visually ergonomic moved blocks recognition for years, and have yet to find one

The moved blocks visualization of Semanticmerge looks quite good to me:


Maybe one of you guys can give me a hint which comparison tool at the moment is best in this regard?

Thanks
David