#96 view -> inline compare (recursive) requires a reload to highlight changes

[rob m]

enabling inline recursive diffs requires a reload (ctrl-R) to take effect.

1. disable: Menu: View -> Show Inline Comparison (recursive)
2. enable: Menu: View -> Show Inline Comparison (recursive)
3. no change observed
4. reload: ctrl-R
5. change observed

going from enabled -> disabled behaves as expected (no reload required).

tkdiff 4.2 did not require reload to enable the recursive inline diffs.

[rob m]

tkdiff 5.6 with patch 189 on Ubuntu 22.04.3 LTS x64

[michael-m]

Well, a LOT has happened between V4.2 and V5.6; so the fact they might behave marginally different between then (over a decade ago) and now is not terribly descriptive of a "problem". Back then, the recursive approach reported EVERYTHING different in any given pair of lines.
Over the past several years (and intervening releases) the recursive approach has become considerably more detailed and configurable. Nowadays you can specify exactly WHICH (if any) of the various suppression idioms (Blanks, capitalizations, etc) should be considered as meaningful (these can be specified as "Engine" Preferences) - which controls what Diff even bothers to REPORT as lines having differences (and thus would require a followup reload to be performed).

But the SPECIFIC details of your observation does seem to have identified a small shortcoming in the Preferences -> Display setting of (a secondary set of) these same suppression choices. It is THESE settings that are being turned "on/off" when the Menu -> View toggle is being adjusted, and while turning them OFF likely works, turning them back ON is not responding immediately (as it should).

However - it does not require a Diff 'reload' to recover - a simple window scroll; even as little as one line, should cause the display to re-highlight correctly.

This happens because the computation of the highlights (given all the flexibility allowed) is computationally intense, and we only ever compute the ones that can be SEEN in the current text windows. Alas there seems to be a missing "trigger" event to NOTICE that while the window has not MOVED, it may yet require the highlight computation to be performed, simply because of the OFF-to-ON transition! We will look into adding this trigger, while YOU can simply SCROLL the window manually to recover the missing highlights! Thanks for the report!

[rob m]

thanks! i just upgraded from 4.2 -> 5.6 so it is just the data point i have even if it is not all that useful. my tkdiffrc defaults to inline recursive to off but i like to toggle it on / off when looking at diffs to point out non-obvious things for whatever line i happen to be looking at.

thanks again.

[michael-m]

Well, a LOT has happened between V4.2 and V5.6; so the fact they might behave marginally different between then (over a decade ago) and now is not terribly descriptive of a "problem".
Back then, the recursive approach reported EVERYTHING different in any given pair of lines.
Over the past several years (and intervening releases) the recursive approach has become considerably more detailed and configurable. Nowadays you can specify exactly WHICH (if any) of the various suppression idioms (Blanks, capitalizations, etc) should be considered as meaningful (these can be specified as "Engine" Preferences) - which controls what Diff even bothers to REPORT as lines having differences (and thus would require a followup reload to be performed).
But the SPECIFIC details of your observation does seem to have identified a small shortcoming in the Preferences -> Display setting of a duplicate set of these same suppression choices. It is THESE settings that are being turned "on/off" when the Menu -> View toggle is being adjusted, and while turning them OFF likely works, turning them back ON is not responding immediately (as it should).

However - it does not require a reload to recover - a simple window scroll; even as little as one line, should cause the display to re-highlight correctly.

This happens because the computation of the highlights (given all the flexibility allowed) is computationally intense, and we only ever compute the ones that can be SEEN in the current text windows. Alas there seems to be a missing "trigger" event to NOTICE that while the window has not MOVED, it may yet require the highlight computation to be performed, simply because of the OFF-to-ON transition! We will look into adding this trigger, while YOU can simply SCROLL the window manually to recover the missing highlights! Thanks for the report!