Re-Compare current Compare

[Yaron10]

Hello Pavel,

Continued from #29 (comment).

That sounds reasonable. Anyway, I'll prompt (with default to 'yes' - re-compare) if the re-compare was deliberate just in case you triggered it by mistake (some files may need much time to compare).

Allow me to suggest a different view:
Personally and based on previous experience I'd rather not have any prompt in this case.
I often make some changes in the files while Compare is active and then I want to re-compare them.
I believe that this would be more common (than accidentally pressing Compare again) for other users as well.

What do you think?

Thank you.

BR

[pnedev]

Hello Yaron,

OK, sounds reasonable, I agree.

BR

[Yaron10]

Hello Pavel,

Thank you very much. I appreciate it.

BR

[pnedev]

Hello Yaron,

Implemented in master branch.
Original compared file save is also restored (code is optimized).

BR

[xylographe]

Thank you, Pavel. (CP 1d3e95a)

Great! My typical work flow is compare -> modify -> compare -> modify -> etc. This works a lot better without having to clear-compare before re-comparing.

To err is human, apparently I'm the most humane creature on earth. :) It's not uncommon that I unintentionally modify the base file, but fortunately NPP offers "Reload". I was wondering if it might be possible to re-compare automatically if one of the files involved in the compare is reloaded? It would seem to be reasonable and user friendly behaviour?

[pnedev]

Hello @xylographe ,

It's good that @Yaron10 brought the reload issue forward.
You both seem to be long time users of Compare plugin, it's great I can get suggestions/opinion from user perspective. Thank you both.

To err is human, apparently I'm the most humane creature on earth. :)

Long live humanity! :)
I thought about handling the reload case (in slightly different manner though - to close the current compare :)) but I haven't reached there yet. Automatic re-compare in that case seems reasonable, I'll consider it.
@Yaron10 , what's your opinion about that?

BR

[Yaron10]

Hello Pavel and xylographe,

Pavel,

Thank you very much. I do appreciate it.

It's good that @Yaron10 brought the reload issue forward.

Thanks for that too. But unless I'm missing something, xylographe deserves the credit for raising the "Reload from disk" issue.
I was referring to "Reload last closed file" (or "Restore recent closed file").

Actually I do deserve some credit for "Reload from disk". I thought about it. :)
And then I thought about "File has been modified by another program. Reload?". (Related).
And what if the user deletes/replaces the entire content of a compared file? And what about a minor change?

Anyway - if addressing "Reload from disk" is important to xylographe, that's a good reason to implement it. :) We appreciate your work.

@xylographe,

Thanks for bringing that up.

Best regards.

[pnedev]

Hello @Yaron10 ,

It's good that @Yaron10 brought the reload issue forward.

I didn't mean the reload but the "re-compare current compare", sorry for the confusion.
I must have been partly sleeping already when I wrote this ;)

@xylographe,
Thanks for bringing that up.
Can you open a new issue regarding the reload just to have this on record?
This issue was regarding re-compare and is closed. Thanks.

BR

[pnedev]

Hello guys,

Unfortunately N++ currently doesn't provide file reload notification. I'll see if I can do something anyway but it's going to take a while.

BR

[xylographe]

And then I thought about "File has been modified by another program. Reload?"

Well, in my case that would only happen if I decided to change the base file to an older/newer version by invoking "git checkout" (or "svn co"). My intention would still be the same: re-compare with the reloaded file to continue the work flow outlined above.

However, I understand other users might want to "Clear Compare" on a reload due to external modification. Combined with,

Unfortunately N++ currently doesn't provide file reload notification.

my conclusion has to be: do nothing, let the user decide if they want to continue with clear-compare or re-compare. Both of them are only one shortcut away…

@pnedev
Yes, I intended to open a new issue, just wanted to know if it was technically possible.
However, having read your and Yaron's comments, the planned issue has been closed before it has been created. :) Whichever automated action you would choose, there would always be a substantial number of disgruntled users. This would be a good candidate for "Options", but I'm aware (and understand) you'd rather not go that way.

Thanks to both of you for your input—it's always good to see matters from a different perspective.

[pnedev]

OK @xylographe , we'll leave that for the future then. Thanks.

BR

[Yaron10]

Hello gentlemen,

And then I thought about "File has been modified by another program. Reload?". (Related).
And what if the user deletes/replaces the entire content of a compared file? And what about a minor change?

I didn't mean that in those cases the Compare should be cleared.
I was just wondering about dynamically re-comparing. Where do we draw the line?
Pavel may well be capable of implementing dynamically re-comparing ( :) ), but then Compare would have to compete with MS Visual Studio (in terms of dynamically detecting and responding to modifications).

Thank you.
BR

[pnedev]

Let's leave the reload and dynamic re-compare for the time all other issues are closed and we are all happy with the current state. Those are pretty tough tasks and will require more thought and concentration.

Thank you both for sharing your thought on the subject.

BR