Hi Guys,
DIFF v2... Observations...
Please forgive me, this is "Feedback PART 1" and much is behavioural or superficial stuff. I'm still testing the execution aspects but Life keeps getting in the way.
Operands Design Logic
Ignore Spaces, Ignore Tabs, Ignore Comments
Testing shows each of these settings only makes sense if it is applied to both files or neither file.
So we should treat each of them as either ON or OFF for both files together.
An example using 'Ignore Spaces'
(dots represent spaces):
With many languages 'blind' to multiple blanks these days, the intention was to allow data like
...ABC....DEF....XYZ to match a line like
..ABC........DEF..XYZ With 'Ignore Spaces', both lines 'reduce' to
.ABC.DEF.XYZ and hence would match.
But unless we 'reduce' both files' data in the same way, the comparison will fail to match 99.999% of the time.
Restricted comparison settings
Brief Interlude...
I'd favour 'BOUNDS' over 'Margin' because they are column limits and SPFLite already uses the term BOUNDS for that concept (FIND, CHANGE, etc).
(Semantically, 'Margins' commonly define an area outside the main data body, rather than delimiting a subset within the data body)
The Options Panel uses the word Margin, but BOUNDs is used in the DIFF output report. Thus I vote for BOUNDS throughout for consistency across the product.
Assuming you agree, please also change the Options Panel from two fields with defaults 1 and 0 to one field of 1,MAX for consistency with BOUNDS elsewhere.
Back to Design Logic...
The BOUNDS could be treated the same as the above keywords, but DIFF might be more flexible if the 'area to be compared' can be in different positions in each file.
(OK, hands up. Even I'm not sure if this flexibility is going to be THAT useful. If you think not, let's just ensure that BOUNDS is set the same for both FileA and FileB)
However, it doesn't make much sense to compare areas of different lengths.
So I suggest that
- there is one BOUNDS field for each file on the Options Panel.
- the format is a,b where a and b are numeric, but b is allowed to be MAX.
- the default value for both files is 1,MAX
- data validation ensures that the length defined by the two entries is the same,
example: FileA set to 1,10 and FileB set to 33,42 is OK, but FileB set to anything other than 10-bytes in length is NOT accepted
Perhaps, if the user specifies numerics for FileA and leaves FileB at the default 1,MAX then we assume an automatic FileB bounds = FileA bounds?
Case sensitivity? (*NEW* Sorry - it didn't occur to me before)
If included, we should consider this another ON/OFF option for both files simultaneously.
The easiest implementation may be to assume CASE=T unless the 'Perform case-sensitive comparison' box (see below) is ticked to switch to CASE=C.
Feel free to reword the tick option accordingly if you'd prefer to swap the default around.
DIFF LIST Report file name/type
The DIFF Report Tab is very(!) wide when FileA and FileB have longish names.
I noticed this because I was testing by comparing CFGMaint Export files open in Tab 2 & 3.
This causes the whole Tab line to scroll and it quickly becomes unwieldy.
We might need some way to shorten the name in the tab label even if the filename(s) remain long. (I have no good ideas at this time)
Output Panel
Location (another brief interlude - I know that you can't test this because you don't have 2 screens. No problem.)
The pop-up window always opens in the centre of Display-1 even when the SPFLite main window is on Display-2.
The same appears true of many (possibly all) other pop-ups from SPFLite, eg File Manager delete confirmation, etc.
Given that SPFLite is aware of its screen position/coordinates, is it possible to target all pop-up windows relative to the centre of the SPFLite main screen?
That way, they appear right in the user's field of vision and she/he won't be left wondering why SPFLite appears to be unresponsive.
Appearance (back on topic now)
- Several field descriptions/labels are truncated by one or more characters, see the ones that begin "Ignore..."
- The labels for the Tick/Untick boxes don't really need to end with a '?'. In Windows, a tick generally means 'Do this'
- A longer input box would help distinguish long file names. Achievable by moving the <Open Other> button one line down
- There's no need for a selection box for 1/2-Col view. Just pick a default and make the other the tick option.
- Considering these and the earlier comments above, I had a go at reformatting the Options Panel:
<ICON> Please select the two files to be compared and the relevant options:
FileA [enlarged input area/drop-down box ]
Limit comparison to BOUNDS [ 1,MAX ] <Open Other>
FileB [enlarged input area/drop-down box ]
Limit comparison to BOUNDS [ 1,MAX ] <Open Other>
------------------------------------------------------------------------------------
Options: [ ] Ignore multiple spaces [ ] Perform case-sensitive comparison
[ ] Ignore embedded Tab chars [nn] Minimum number of matching lines
[ ] Ignore comments required to re-establish Sync
------------------------------------------------------------------------------------
View: [ ] Single column view [ ] Do not display matching lines
<CANCEL> <DONE>
Re-establishing Sync
We have the count of lines that must match to re-establish Sync.
But in some practical trials, large sections of code are considered deleted followed directly by a similar size section of considered inserted.
So my question is, how far ahead does DIFF search in attempt to find the magic number of re-sync lines?
Should that 'forward horizon' value also be a configurable item?
That's it for Part 1. Hope there's some useful stuff here.
I'm sure you'll let me know if you disagree with anything. No problem.
Meanwhile, I'll carry on testing actual functionality as quickly as I can.
