General Discussion thread about compareplus HOT 120 CLOSED

Hello Yaron,

It's Friday and you are really active ;)
Thanks for all the testing and suggestions, I'll go through all your posts as soon as I find some free time.

BR

from compareplus.

Hello Pavel,

I hope that not too active. :) Your last update is virtually a new plugin.

Sure, whenever you have some free time (and the right mood; that's important too).

Thank you very much.

BR

from compareplus.

Hello guys,

I need a user perspective opinion on something.

@Yaron10 ,

This is something you suggested in #29

3. If the user is trying to compare an already compared file with a third non-compared file - how about ...Would you like to clear the current Compare?

Here is the case:

1. You have 4 files in single view: A,B,C,D
2. You compare two of them, let's say C and D. View1: A,B,C; View2: D
3. You switch to B
4. You directly trigger "Compare" command.

At this point I'm wondering what is the best approach to take:

1. Give error message (you want to compare to D again) and ignore this compare.
2. Give warning and ask (yes/no) if you would like to proceed with compare.
   If yes, clear C-D compare and compare B and D (this is what @Yaron10 suggests above).
3. Directly clear C-D compare and compare B and D (without prompting)
4. Treat D as locked in another compare and go to single view compare behavior -> compare B and A.

Thank you for the feedback.

BR

from compareplus.

FYI the currently implemented solution is 1)

from compareplus.

Most likely the user didn't trigger "Compare" just for fun. :) They must have had something in mind. Hence (1) is not very helpful. If it were me, I would have pressed Alt+D to start a new compare between B and D (implicitly clearing the C-D compare). Therefore I have to go with (3). I don't think a (disruptive) confirmation message box is necessary, because the actions "Clear Compare" and "Compare" are non-destructive.

If you would insist on a (disruptive IMO) message box, you might as well bring up several choices:

1. Compare B-D (option 2)
2. Compare B-A (option 4)
3. Re-compare C-D
4. Cancel

In this case I would prefer defaulting to 1, although 2 would be acceptable too (but not 3 or 4).

from compareplus.

Thanks for the feedback @xylographe .
3) looks a reasonable choice indeed.

BR

from compareplus.

Hello Pavel,

Later. :)

Thank you.

BR

from compareplus.

Hello Pavel and xylographe,

I think there should be a balance between avoiding disruptive message-boxes and alerting the user if needed.

In this four-files case, the user is probably aware that D is already compared.
But if you have some 30 files open in both views (and D's diff marks are at the end and not currently visible), it might be good to alert the user.

What do you think?

Thank you.

Best regards.

from compareplus.

As I wrote above: if some sort of dialogue is deemed necessary make it multiple choice. It's more user-friendly then a single choice (confirmation) mbox.

from compareplus.

OK. :)

from compareplus.

Great, so I'll need to implement all of them :)

I'm thinking of leaving this 'as-is' now.
I don' think it's a common use-case and for the rare occasions the user needs to do something like this he won't get over-burdened by clearing the current compare and explicitly doing what he wants.

Thank you both for the feedback.

BR

from compareplus.

Hello,

Continued from #49 (comment).

xylographe wrote:

It seems natural to me that the origin (old/base) is on the left side and the current (new) on the right side when comparing two files.

This is a good argument.
But - as I've mentioned before - in a normal workflow it's not always the case, and IMO "current == primary" should override it.

One could look at it as an implicit "Set first" on the left neighbour of the active file. After "Clear Compare" I would like the original situation restored: (X, A, ^B, Y).

This is very good!
But actually I'd rather have "Set as second to Compare" (if not "Compare to last active" :) ) so that the current file when pressing Compare would be in the left/top view. :)

I think it's all related to #29 (comment).

BR

from compareplus.

Hello guys,

As I said it seems that a user option about that is needed - to set the desired view for the compared file - MAIN or SUB. Some clarifications:

1. "Set first" selects the compared file in single view.
2. If directly "Compare" is started in single view, the compared file is the currently active one.
3. In two views mode no adjustments are made - both files remain in their current view and the '+'/'-' marks are put according to the user preference mentioned above.

Are we all happy with such approach?

BR

from compareplus.

The current two views behaviour is perfect. This is basically the same as "diff -u" but easier on the eyes :) and much better for the purpose of editing.

"Set first" currently works the way I like it (I'm using it almost all the time in single view mode). But Yaron (and certainly other users as well) would seem to prefer "Set second" instead. Perhaps, this could become a CP option: display "Set first" or "Set second" in CP sub-menu.

Single view without using "Set first" (or potentially "Set second") is always going to be a point of discussion. Therefore, I suggest, you, Pavel, make it work the way you like it. Other users will either get used to it or use one of the other options (two views, "Set first", "Set second").

from compareplus.

Thanks for the feedback @xylographe .

BR

from compareplus.

Hello Pavel and xylographe,

Continued in #29 (comment).

BR

from compareplus.

Hello guys,

I added a user preference option about that (first file's compare view). It is currently only accessible if you directly edit the Compare.ini file. Please use another editor for that - N++ will overwrite Compare.ini on exit. The default value is right/bottom (what you both agreed to be better).

BR

from compareplus.

Thank you, Pavel. Great option!

I worked with both alternatives (hence, the delay in my response), and although setting this option to zero is interesting and not without merits, I will, obviously, keep it at one, because that fits perfectly in my usual work flow.

This option definitely increases convenience of use. Thanks again for all your efforts.

from compareplus.

Hello Pavel,

Thank you for adding that setting.

I assume the implementation of "current vs. next" when Place First Compared File in the Right/Bottom View=0 is intentional. Very nice.

When using horizontal split (top/bottom) the immediate expectation is to place current file in the top view.
I changed my mind when I tested vertical split which gave me a slightly different perspective.

I can think of 4 possible interpretations to "First" in our context:

1. Base File (old).
2. Primary File (new).
3. Visually First (left/top).
4. First selected (Set as first).

I find that a bit confusing.

We compare old vs. new and the sooner the user is aware of it the better. :)
How about explicitly using those terms?

"Place "New File" in the Right/Bottom panel" instead of "Place First Compared File in the Right/Bottom View" (we place it in Right/Bottom view because it's second /new).

And "Set as "New File" to Compare" instead of "Set as first to Compare".

Wouldn't "Set as "Old File" to Compare" be more consistent with the other way to compare?
The current file when pressing Compare is new and the other (prev or next) is old.

What do you think?

Best regards.

from compareplus.

I think, old versus new is merely a concept in the mind of the user. AFAIK CP does not (yet? ;) ) read my mind. I agree, the term "First" is not unambiguous, but once you start using CP you will soon get the hang of it. "Set as old" or "Set as new" will be more convenient to some users, but others will feel these terms are confusing in a different way.

As long as the implemented behaviour is consistent I don't really care about the choice of terminology, but, of course, "Set First" matches well with the Alt-F keyboard shortcut. :)

from compareplus.

I think, old versus new is merely a concept in the mind of the user. AFAIK CP does not (yet? ;) ) read my mind.

As I've mentioned before the user himself may not know which is old and which is new.
But CP certainly considers one old (the file with the Minus sign) and one new (Plus sign).

"Set First" matches well with the Alt-F keyboard shortcut.

You made me think about the shortcuts again.
It's no wonder Alt+(letter) is available. No one else uses it.
They will be a major problem for keyboard-oriented English (and many other locals) users.
Yes, Alt+F would select a file to Compare but they're used to opening the File menu with it.
It should be changed.

from compareplus.

Beta DLL's built from Pavel's master branch are available in this folder

from compareplus.

@Yaron10
I have not changed opinion since I wrote my thoughts on the shortcuts here.

from compareplus.

Thank you for the DLLs. I appreciate it.
Why 2 files?

I have not changed opinion since I wrote my thoughts on the shortcuts here.

That's fine. But I think it would be better to use a less convenient shortcut (like Ctrl+Alt+letter) than providing one which will certainly present a problem for many users.

from compareplus.

Why 2 files?

Different revisions. The four digit sequence number indicates which one is most recent.
The commit hash at the end can be used to examine the last commit(s).

But I think it would be better to use a less convenient shortcut

Really? A less convenient shortcut? I think, the goal is to increase convenience of use?

from compareplus.

Hello guys,

@Yaron10 ,

I assume the implementation of "current vs. next" when Place First Compared File in the Right/Bottom View=0 is intentional. Very nice.

Yes, that's intentional.

I think, old versus new is merely a concept in the mind of the user. AFAIK CP does not

I agree with @xylographe here.

But CP certainly considers one old (the file with the Minus sign) and one new (Plus sign).

That is definitely not true. CP cares only what file to compare against what other file - hence "Set as First". This is true for other commercial compare programs as well.

For example open 2 files for comparison (A and B) and first set A as first and compare, then repeat the compare, setting B as first. You will get a different compare perspective.

Let's clarify further:

1. Let's put aside comparing against last save/SVN/Git when CP will be aware of "old/new" terminology. That will be implemented accordingly but then you don't have "Set as First" step at all - no confusion.

2. The user wants to compare two files. Let's say one is his version and the other is modified by someone else. Which one is new and which is old?
   The user then would like to see how HIS version differs from the OTHER version -> sets HIS as first and compares. HIS is the focus/bias for compare.
   Other times the user would like to see how the OTHER version differs from HIS version -> he sets OTHER as first and compares. OTHER is the focus/bias for compare.

That's fine. But I think it would be better to use a less convenient shortcut (like Ctrl+Alt+letter) than providing one which will certainly present a problem for many users.

Alt-F is not much different from Alt-D. If the latter is not a problem, why would the first be?
'D' and 'F' keys are even adjacent which makes it even more convenient for the user.

@xylographe ,

Beta DLL's from Pavel's master branch are available in this folder

That's a very good idea, thank you. This way we'll be on the same track 👍

BR

from compareplus.

Hello Pavel,

Thank you for explaining your point of view.
I'll try to clarify mine on Wednesday or Thursday.

And thanks for all the recent improvements and fixes.

Best regards.

from compareplus.

Hello Pavel,

A few lines up this page I wrote:

As I've mentioned before the user himself may not know which is old and which is new.

If the user may not know, Compare surly can't know that.
And that has been my argument all the way (explained in Compare to last Save: always place original file at bottom in detail.

This doesn't contradict what I wrote next:

But CP certainly considers one old (the file with the Minus sign) and one new (Plus sign).

In the current implementation CP does not "care only what file to compare against what other file".
(That would be true if the "Two Equal Files" concept was implemented).
CP "stamps" one file "Minus-Red" and another "Plus-Green".
You can refer to that as original/changed, base/focal, secondary/primary or old/new.
Of course, those definitions may be relevant in some cases and not in others.
But the division "Minus-Red" vs. "Plus-Green" is always true.

So I suggested to use the terms "Old File" and "New File" (in quotes) as "code names" to "Minus-Red" and "Plus-Green" respectively.

It can be debated whether this is a good idea or not.

If you use the old Compare method (i.e. current vs. prev/mext), the current file is "Plus-Green" and the other is "Minus-Red".
When you use "Set first" it's the other way around: the current file when pressing Compare is "Minus-Red" and the other is "Plus-Green".

I think this is confusing.

You can argue that in both cases "First Selected" is "Plus-Green".
That's true but IMO the user's expectation would be consistency in current == "Plus-Green".

And then you can use "Place Current File in the Right/Bottom Panel".

In principal there's no difference between Alt+F and Alt+D; both would collide with Windows standard use of Alt+Letter.
Alt+F (and Alt+S) would be a problem to English users and therefore I consider them more serious.

Anyone with a bit of common sense would understand that Ctrl+Alt+Letter (less convenient) is a better option than Alt+Letter (a major problem to many users).

Could you please upload the updated DLL?
I'd like to refer to other issues/fixes and I'm not sure that currently my build would be a reliable indication.

Thank you.

Best regards.

from compareplus.

Hello Yaron,

Welcome back and thanks for the clarification.
It seems we are talking about the same thing but using different terminology.

In the current implementation CP does not "care only what file to compare against what other file".

In your perspective CP cares about old / new because it knows where to use '-' / '+' marks.
In my perspective CP do care only which file is compared against which other and based on that it uses '+' and '-' marks respectively.

But the division "Minus-Red" vs. "Plus-Green" is always true.

I totally agree but it is not based on the old / new concept but on which file was selected first - the focal file.
Thus, as I explained above the old / new terminology is not quite accurate.

You can argue that in both cases "First Selected" is "Plus-Green".
That's true but IMO the user's expectation would be consistency in current == "Plus-Green".
And then you can use "Place Current File in the Right/Bottom Panel".

This means that "Set second" needs to be implemented instead of "Set first" which is something I'm not going to do at the moment.

Anyone with a bit of common sense would understand that Ctrl+Alt+Letter (less convenient) is a better option than Alt+Letter (a major problem to many users).

Well, I assume you are not implying that @xylographe and I are common-senseless :)

I personally don't care about the shortcuts. I would remove them altogether as this would be the safest approach (in terms of possible conflicts), besides the user can select whatever shortcuts desired from N++ settings.
I want to keep things as consistent as possible. This means that if we use Ctrl+Alt+Letter for "Set first" then I'd like to use Ctrl+Alt+Letter for "Compare" command too.

Could you please upload the updated DLL?

Sure, no problem.

Thanks.
BR

from compareplus.

In mode "1" Alt-F sets the focal file, which I consider to be the second file, mainly, because it comes in second place when invoking diff(1) (e.g., diff foo1.c foo2.c). But the terminology is really not that important, as long as the behaviour remains consistent.

from compareplus.

Hello Pavel,

Thank you. I appreciate it.

Well, I assume you are not implying that @xylographe and I are common-senseless :)

I did not have the slightest intention to insinuate you lacked a common sense. You, Pavel, have plenty of it. :)

I want to keep things as consistent as possible. This means that if we use Ctrl+Alt+Letter for "Set first" then I'd like to use Ctrl+Alt+Letter for "Compare" command too.

Sure. I'll check different combinations soon.

This means that "Set second" needs to be implemented instead of "Set first" which is something I'm not going to do at the moment.

If and when you return to this, allow me to bring up one more point:
When you want to compare old vs. new using the old method, you need to make sure the current file is new.
Using "Set first" you need to make sure the current file is old.

Thanks also for uploading the DLL.

Best regards.

from compareplus.

When you use "Set first" it's the other way around: the current file when pressing Compare is "Minus-Red" and the other is "Plus-Green".

Would it help if "Set first" were to be named "Set focal"? Or, am I missing something?

from compareplus.

No, it wouldn't help.
In the other method to compare, focal == current.

Think about the following case:
You have 5 versions of a file open in ascended order (oldest on the left, version 2 next and newest on the right).

If you want to compare newest to version 4, you activate the last file and press Compare.
If you want to compare newest to version 2 using "Set first", you'd have to remember and "calculate" another factor: activate the last file, "Set first" (this is focal), activate version 2 and Compare when current is NOT focal.

from compareplus.

I see what you mean. In fact this did feel as the most “natural” behaviour to me.

However, it turns out that Pavel's new approach is more convenient in practice. After clearing the first compare (newest to version 4), you press Alt+F, Ctl+PgUp (3 times), and finally Alt-D. No need to go to version 2 first (Alt+F) , and then go back to newest (Alt+D).

Of course, it took a bit of time to get used to initially, but once I did get the hang of it, it worked like a charm. A fully deserved “game, set & match”  to Pavel. :)

from compareplus.

You assume you do the second Compare immediately after the first. That's not necessarily the case.

IMO "Set first" should be equivalent to prev/next in the other method.
It should give you more flexibility in choosing the other file without changing "current == focal".

from compareplus.

(*A1, A2, A3, A4, B1, B2, B3, B4, B5) (A1 is active)
You compare B5 (newest, activate, Alt+D) to B4 (version 4).
(A1, A2, A3, A4, B1, B2, B3, ^B4 | *B5) (B4 on the left is visible, B5 on the right is active)
Now you compare A4 (activate, Alt+F) to A1 (activate, Alt+D)
(^A1, A2, A3, A4, B1, B2, B3, B4 | B5, *A4) (A1 on the left is visible, A4 on the right is active)
Next you compare B5 (activate, Alt+F) to B2 (activate, Alt+D)
(A1, A2, A3, A4, B1, ^B2, B3, B4 | *B5, A4) (B2 on the left is visible, B5 on the right is active)

Does it really matter if you activate "B5, then B2", or "B2, then B5"? (although "B5, then B2" is actually one shortcut less :) )

from compareplus.

You're right. It doesn't really matter.

But the point is the concept and the workflow:
In the old Compare method the other file is selected automatically.
In "Set first" the other file is selected manually. No other difference which might add some confusion.

from compareplus.

In the old Compare method the other file is selected automatically.

Sorry, I don't understand that.
When comparing A4 to (its neighbour) A3, A3 is still selected automatically, isn't it?
Activating A4 and Alt-D is equivalent to "activate A4, Alt-F, activate A3, Alt-D".
In this particular case (neighbours) the file to compare to (A3) is implied?

from compareplus.

I was not referring to this particular case.

The point I was trying to make is this: the user should know that the only difference between the two methods is whether the match (made in heaven) to current is selected automatically or manually.

Adding another difference to the implementation is slightly confusing IMO.
But I might be wrong.

EDIT:
If you and Pavel don't consider it confusing, it certainly can be my personal problem; "perfect consistency" or else it's confusing.

from compareplus.

Hello guys,

Play a bit with the latest commit in set_old branch and tell me what you think (how it is compared to the latest master, any comments, etc.).
It has some minor issues but is generally usable and you should be able to get how it feels.
If that's what you prefer over the current implementation I'll stabilize it and make it the original version.

The new shortcuts are just a proposal and are a subject to discussion.

I'll read all your recent comments in the morning, thanks.

@Yaron10 ,

Here is a dll for you:
ComparePlugin.zip

BR

from compareplus.

Hello Pavel and xylographe,

Pavel,

Thank you very much! I highly appreciate it.
And I apologize for adding this extra work to your already full hands.
But actually it's xylographe's "fault" too (xylographe, thanks for that).

After a quick test it looks brilliant. I'm not confused anymore. :)
I'll also continue tomorrow.

Special thanks for the DLL.

Best regards.

from compareplus.

Set-old is exactly what I had in mind a few days ago. But compared to master it is inferior, because it is less consistent, and also less efficient.

When you forget those silly old/new and first/second concepts in your mind (after all they are open for interpretation), and look at it from the perspective of comparing the focal file to some other file, then the master implementation makes a lot more sense, as it is unambiguous. There can be no discussion about the meaning of focal file.

In practice master is more consistent, you always start by activating the focal file, then you either trigger "Compare" if you want to compare to its left neighbour, or you trigger "Set Focal" ("Set First" to some, "Set Second" to others :) ), then activate the other file and trigger "Compare".

With set-old you first have to choose which file you want the focal file to compare to (the 'other' file), then decide whether you need to activate it (if its not the left neighbour of focal) or not (if it is the left neighbour of focal). Unless, of course, you're prepared to always activate the 'other' file and trigger "Set First", then activate the focal file and trigger "Compare". But in practice that would be incredibly inefficient.

In conclusion I would suggest to keep the superior master behaviour, and just change the descriptions:

1. "Set Focal" instead of "Set First"
2. "Place Focal File in the Right/Bottom View" i/o "Place First Compared File in the Right/Bottom View"

BTW the new shortcuts are terrible, but I don't care, already fixed in NPP's shortcut manager. :)

from compareplus.

In practice master is more consistent, you always start by activating the focal file, then you either trigger "Compare" if you want to compare to its left neighbour,

That's not true.
In many cases you'd start by dragging the old file and place it next to focal.
But anyway the new implementation is clearer and more consistent:
Current == focal in both methods, and the only difference is how the other is selected - automatically (or rather semi automatically - in many cases you have to rearrange the tabs) or manually.
Think also of the files' position: the user would expect the current file when pressing Compare to be placed in the same panel in both methods.

In two days time you'll get the hang of it and realize it's "a matter of getting used to".

As for the shortcuts: I'm sorry you find them terrible, but I think we don't have a choice.

Hello Pavel,

Thanks again for the new implementation. 👍
I find it much more coherent, consistent and "streaming".

I've search Google Images for "Compare Tool" and found some interesting screenshots.
(I should have done that earlier).

Base vs. --.
Newer vs. Older.
Old vs. --.
-- vs. Latest.
New vs. --.
Original vs. Modified

Some questions:

1. Why Compare / Compare to Old?
2. Do you prefer Alt+Shift over Ctrl+Alt? - In "Next" and "Prev" we can't use Alt+Shift; wouldn't it be better to use Ctrl+Alt for all?
3. Why "B" for "Compare to last Save"?

Best regards.

from compareplus.

With set-old you first have to choose which file you want the focal file to compare to (the 'other' file), then decide whether you need to activate it (if its not the left neighbour of focal) or not (if it is the left neighbour of focal). Unless, of course, you're prepared to always activate the 'other' file and trigger "Set First", then activate the focal file and trigger "Compare". But in practice that would be incredibly inefficient.

Sorry, I don't understand that at all.

from compareplus.

(A, B, C1, C2, C3)

master => activate C3 and trigger "Compare" to compare focal C3 to C2
master => activate C3, trigger "Set Focal", activate C1, trigger "Compare" to compare focal C3 to C1
You always start with the focal file. [consistent]

set-old ==> activate C3 and trigger "Compare" to compare focal C3 to C2
set-old ==> activate C1, trigger "Set First", activate C3, trigger "Compare" to compare focal C3 to C1
In the first case you start with focal C3. In the second case you start with 'other' C1. [inconsistent]

I'm aware set-old is exactly what I described several days ago. But Pavel's approach is simply better in terms of consistency and efficiency. I don't see the point of sticking to my own ideas if there is an alternative that is clearly superior.

from compareplus.

I'm aware set-old is exactly what I described several days ago. But Pavel's approach is simply better in terms of consistency and efficiency. I don't see the point of sticking to my own ideas if there is an alternative that is clearly superior.

I agree and respect you for that.

master => activate C3 and trigger "Compare" to compare focal C3 to C2
master => activate C3, trigger "Set Focal", activate C1, trigger "Compare" to compare focal C3 to C1
You always start with the focal file. [consistent]

set-old ==> activate C3 and trigger "Compare" to compare focal C3 to C2
set-old ==> activate C1, trigger "Set First", activate C3, trigger "Compare" to compare focal C3 to C1
In the first case you start with focal C3. In the second case you start with 'other' C1. [inconsistent]

So we're discussing consistency and not efficiency, correct?

I agree with you here, and I actually mentioned it in this page:

You can argue that in both cases "First Selected" is "Plus-Green".
That's true but IMO the user's expectation would be consistency in current == "Plus-Green".

And you must agree with me about the inconsistency regarding current == focal. Do you?

We have two stages: Prepare to Compare (arranging the tabs or "Set file") and then Compare.
We have used the word "focal" a lot. I'll use it again: which stage is focal (or more important)? Is it the arrangements/preparations or the actual Compare?

IMO the Compare stage and the following outcome are more important.

Another point:

master => activate C3 and trigger "Compare" to compare focal C3 to C2

This would not always be the case in real life.
In many cases you'd start with activating old and dragging it next to focal.

But most important is the concept:
In both methods you have Current -> Compare. Do you agree?
The only difference is how the other is selected.

from compareplus.

A few more words about the concept:

Why did Pavel add the "Set file" option? What was missing in the old method?
Did we have a problem with Current -> Compare? No. The problem was that the other file was not always next to current.

So let's leave current as it is in the old method and fix the other file.

from compareplus.

Hello Pavel,

Regarding the wrong results I got with my VS 2013:
Well, Claudia has done it again. Problem solved.
You were right: it was indeed a compiler issue.

Thank you for your great work.

I'll be off again for a couple of days.
Best regards.

from compareplus.

Hello Yaron,

So we're discussing consistency and not efficiency, correct?

Both. Although, in most scenario's, the difference in efficiency is either small or insignificant.

And you must agree with me about the inconsistency regarding current == focal. Do you?

The term 'current' is ambiguous. In the scenario with two or more revisions from the same branch it is obvious which one is current, and that will obviously be the one you will focus on. Hence, in this scenario 'current file' == 'focal file'.

In another scenario (mentioned earlier by Pavel) one file comes from your development branch, while the other file is from a branch that you fetched from somebody else's repository. Both files are current in their respective branches. You will decide which of the two you are going to focus on, and that one will be the 'focal file'. Note that your focus can shift over time: you might start updating 'yours' with some of 'their' improvements (focus is on your file), when finished, you reverse the rôles of the files, updating 'theirs' with some of your changes to prepare a pull request (focus is on their file).

In both methods you have Current -> Compare. Do you agree?

True, with set-old you always end on the file that you are focussing on. It's more convenient, though, to always start on this focal file. Example:
(A1, A2, A3) A3 is current revision, A2 and A1 are older revisions.
You activate A3, then trigger "Compare" to compare A3 to A2. Next you want to compare A3 to A1.

• With set-old, you trigger "Clear Compare" first, then move (Ctl-PgUp) to A1, trigger "Set file", then move back (Ctl-PgDown) to A3, then trigger "Compare".
• With master, you trigger "Clear Compare" first, then you trigger "Set file", then move to A1, and trigger "Compare".

Experience over the past three days taught me the latter is more convenient.

Why did Pavel add the "Set file" option?

To avoid the continuous rearrangement of NPP tabs. :)

So let's leave current as it is in the old method

Let's use the new method, because it is better. :)

from compareplus.

Hello @Yaron10 and @xylographe ,

That's a serious debate :) Thank you both for your views on the subject.

Here is mine:

First, the reasoning behind "Set first".

When I first started using CP it was very vague to me which files were going to be compared. I actually didn't know then that in single view the compare automatically selected adjacent file. So I always moved one of the files to the other view and compared. This seemed tedious to me.
Later, when I found the "compare to adjacent" functionality, it required rearrangement of tabs (as @xylographe mentioned), which also seemed tedious.
This, plus my preference to be explicit about things, plus my previous experience with external compare programs lead to the implementation of "Set first" as alternative.

Next, let's compare both implementations.

In terms of CODE efficiency both are the same.
In terms of USE efficiency, the master is slightly more efficient in the latest use-case described by @xylographe . @Yaron10 , can you think of a use-case where set-old is more efficient?

In terms of consistency, well, it depends on the point of view.

set-old is consistent in that you always trigger "Compare" from the focal/new file (as pointed by @Yaron10 and which is actually the reason we are discussing this).
master is consistent in that you always start the compare process from the focal/new file.
I'll elaborate more on that because for me it is the main reason to keep master.

I consider compare to be more than the "Compare" command itself. Why?
In my mind the compare process (not just "Compare") goes like this:

"Hm, I need to compare file A_new - let me activate it."
"Well, I have to compare it to A_old, where is it?"

1. "Ah, it just next to A_new, great, let's trigger directly "Compare"."
2. "I can't find it, it is not open! Let me select A_new ("Set First") and open A_old. OK, trigger "Compare"."
3. "Aha, it is here, several files from A_new. Let me select A_new ("Set First") and activate A_old. OK, trigger "Compare"."

So the whole compare process in my head starts from the focal/new file - the file that I want to compare, the file which differences I'm interested in. I'm focused on this file and that is actually the only thing I care about when comparing. My thought is kind of "Well, I want to know how that file is different, I NEED ComparePlugin!".
By the way this is why I wanted "Set First" to be the first item in CP menu - it is where everything starts from (as thought as well - "What file I want to compare?").

In set-old approach the focus kind of changes:

"Hm, I need to compare file A_new. But wait! Against what other file I need it compared?"
"Aha, against A_old. Where is it?"

1. "Ah, it just next to A_new, let's focus again on A_new - let me activate it. OK, trigger "Compare"."
2. "I can't find it, it is not open! Let me open A_old. Let me select A_old ("Set Old"). OK, let's focus again on A_new - let me activate it. OK, trigger "Compare"."
3. "Aha, it is here, several files from A_new. Let me activate and select A_old ("Set Old"). OK, let's focus again on A_new - let me activate it. OK, trigger "Compare"."

Well, I would call master more THOUGHT efficient than set-old :)
At least from my perspective.

@Yaron10 ,

Regarding the wrong results I got with my VS 2013:
Well, Claudia has done it again. Problem solved.

That's good, thanks.

BR

from compareplus.

Hello Pavel and xylographe,

I leave you guys alone for five minuets and when I come back the whole place is a mess! :)

The issue seems to be settled. I'll add the following lines for the intellectual discussion.

The entire compare process.

Even from that point of view "Set first" is not consistent.
Why did we decide to move the focal file to right/bottom?
We assumed the user would open the old file first and then the new one.
So our default layout is this: old == first == left; new == second == right.

It means that the compare process actually starts with the old file.

And what I wrote above

You can argue that in both cases "First Selected" is "Plus-Green".

might be true in the implementation, but from the user's point of view the "First Selected" is the old file.

"Set first" in other applications would depend on their layout:
In this online Compare tool, this and this - old is surely first and new is second.

Regarding the items order:
A good developer once wrote to me that he always had the motive "What would my mum say?" in mind.
Meaning: would the average user understand this? Would he find it easy to use?

If you had to explain to "mum" how to use CP, you would surly start with the basic and simplest way: open two files and press Compare.
"Set first" is the more advanced option and therefore should be placed after "Compare".

Think also of writing "Compare Help":
You start by explaining the various actions of "Set first".
And then: actually you can compare in a simpler and faster way. ???

If indeed you always had to use "Move to Other View" and only then Compare, it would have made sense to place "Set first" as the first item.
But as it is (and as the convention in all applications is) you should start with the basic option.

Thank you.

Best regards.

from compareplus.

Hello again,

The term 'current' is ambiguous.
...
In another scenario (mentioned earlier by Pavel) one file comes from your development branch, while the other file is from a branch that you fetched from somebody else's repository. Both files are current in their respective branches.

"Current" is sharp and clear.
It's the active/focused file when you press Compare.

True, with set-old you always end on the file that you are focussing on. It's more convenient, though, to always start on this focal file. Example:
...
Let's use the new method, because it is better.

It may be better and more convenient for you personally in a specific case.
I find it worse and less convenient.
You wrote yourself that you considered the focal/new second.
It's legitimate to request a certain feature/behavior which suits you better.
But the decision should be based on the application's design and workflow.
And for that we have a reference point: the old basic compare method whose default layout is first == old and current/new == second.

It's like the shortcuts:
You personally (and so do I) find Alt+letter more convenient.
But seeing the broader picture, it's better to use another combination which doesn't collide with Windows convention.

from compareplus.

Hello Yaron,

It's legitimate to request a certain feature/behavior which suits you better.

Quoting myself:

I'm aware set-old is exactly what I described several days ago.

Unfortunately, I cannot claim to have requested the master implementation, but I can recognise gold when it's staring me in the face. :)

It means that the compare process actually starts with the old file.

I have to agree with Pavel on this one:

So the whole compare process in my head starts from the focal/new file -
the file that I want to compare, the file which differences I'm interested in.

In my head comparing also starts with the focused file. The reason I think about this file as the ‘second file’, is that it is the second argument when I invoke diff(1) from the shell: diff old new.
It's sort of a ‘side effect’ of having used diff(1) for hundreds of years. :)

from compareplus.

Hello xylographe,

The reason I think about this file as the ‘second file’, is that it is the second argument when I invoke diff(1) from the shell: diff old new.
It's sort of a ‘side effect’ of having used diff(1) for hundreds of years. :)

We both use the default layout which is equivalent to "diff old new".

It seems that you and Pavel consider "Set first" as the main compare method and therefore this is your reference point.

I think the reference point should be the old basic method.
IOW the old method is the first floor (being the simplest way) and "Set first" should adapt and be consistent with it.

And this is related to the items order as well.

At least I'm beginning to understand (but not to agree with) your approach. :)

BR

from compareplus.

Hello guys,

@Yaron10 ,

I might be repeating myself but anyway...

Let's say my mom want's to use the CP.
What does she know about it, about how it works? Nothing.
What does she know about compare in general? She needs two files. She is also interested in the new one, btw.
Well, she now opens CP menu. What does she see? "Compare" command first. Ah? Compare what? To what? Where do I start? I need to select the files, this is what I'm supposed to do, right?
So the first, logical step is to select one of the files. Only then is the logical moment to compare. After that is the logical moment to close compare.
"Set first" is the only logical, visible, non ambiguous method to compare. It is the full compare flow without any assumptions, secret knowledge about the specific compare program, the only explicit way to compare. It is also with the highest priority. No matter if you have adjacent file, no matter if you are in single or in two views mode, "Set first" flow will take precedence and will do exactly what the user is telling it to do. It will also work even if you have a single opened file - the file you'd like to compare (the focal one).
I used to drive a truck before. It usually started from second gear. However the first gear was there, before the second one anyway. Not somewhere on the back because it was just too powerful to be used.
So the logical order of the commands should be the current one. I'm not changing it. Sorry.

Back to my mom's CP experience.
She starts to understand how CP works and gets comfortable with it. She discovers the "secret" methods CP operates - the two view mode and the most "secret" one - adjacent files compare.
Well, OK, she starts to use those because they provide convenience but again those are there for convenience, they are not the explicit (main) flows.
When she gets so far in using CP she is no longer confused by how it operates - she doesn't care that much about the "inconsistencies" between the "Set first" flow and the more convenient one "adjacent compare".

So, IMHO, the new user wouldn't feel OK with the adjacent compare anyway (if he hadn't been told about it), at least I wasn't, thus it is not the main way and is not a reference point for how things should work.
The seasoned user (like you and @xylographe ) knows perfectly what to expect from CP and how to use it, @xylographe even considers the master approach more optimal and convenient (even if it is in a single, very specific scenario it justifies the master's approach to be used instead of set-old).
So it appears that the experienced CP user would leverage from master, the newbie wouldn't be more confused than usual... Why would we go to set-old, what's the point really?

Can you think of a use-case where set-old is more optimal / convenient than master?

Even if set-old looks more clear to the new user for the first three hours it doesn't justify implementing it if it is less convenient for the rest of the users work with CP.

I find it worse and less convenient.

So how do you find master less convenient? Why?

If it is so confusing because "Set first" begins with the focal file but "Compare" is triggered from the old/base one and in the "basic" ("adjacent files") method the current file (where "Compare" is triggered) is the new one well...
then the option might equally OK be to make "adjacent files" method start from the old file. So you would need to go to the old/base file and run "Compare" (and the new would be selected from the neighbor files).
That will also be perfectly congruent with this statement of yours:

It means that the compare process actually starts with the old file.

That idea is awful actually, please don't consider it :) It was just an illustration of my POV.

I hope I don't sound rude or impolite @Yaron10 . I am not at all.
I really appreciate you opinion and I can see your point and reasoning so far (at least I think so).
I even agree that it is really more consistent to explicitly select the old/base file and then go for "Compare". It really is more consistent with the old "adjacent file" compare method.
I would also use it officially, I have no problem with it.
But if there is a slightest chance set-old to be less convenient / efficient than master then the consistency would have to step back. I consider convenience to have higher priority than consistence.

Thank you both for the valuable opinion, I appreciate it.
Let's make the right decision - choose what's most justified, what would be best from functionality perspective and as user experience.

BR

from compareplus.

more optimal and convenient (even if it is in a single, very specific scenario

Here's another one that happens more often, and will most likely affect more users:

• focal file F is active
• one look at the tab bar tells you the file to compare to (say, C) has not been opened
• press Alt-F Ctl-O, select and open C
• press Alt-D to start the compare

Notwithstanding all praise, I think, there is one situation where improvement might still be possible, as elaborated in #53.

from compareplus.

Hello @xylographe ,

Can you summarize for me here, why set-old is not as convenient / efficient as master for you?
In what use-cases for example.

Sorry if you have to repeat yourself but we need to make a fair final judgement and continue with the other CP issues / improvements and I admit that @Yaron10 's point of view has it's logic and justification.

Let's summarize the pros and cons of both implementations.

Thank you for the extra effort.

BR

from compareplus.

Hello Pavel,

Most of all master is consistent with how my brain works: first decision is "which file will I be working on", which is the focal file. Next comes the choice of 'the other file', unless there is only one alternative, of course. Although I was used to selecting 'the other file' first, due to software implementation, it took less than two days to get used to the master implementation, clearly indicating it is a more natural approach to the compare process.

About efficiency:
In practice, four out of five times I'm already working on a file (the focal file), then decide to revive some stuff from an older revision (or from another branch or a different repository).

If both files are already open in NPP, but not adjacent, master will be more efficient, because I want to compare the file I'm editing (i.e. NPP active tab) against some other file. With master: Alt-F, move to other file, Alt-D. With set-old: move to other file, Alt-F, move back to focal file, Alt-D (at least a few, potentially a lot of, surplus Ctl-Pg{Up,Down}).

If the other file is not opened in NPP, the number of shortcuts becomes less important, it will be more a matter of "redirecting attention". With master I can first select (Alt-F) the focal file, then switch to ConEmu (terminal emulator for Windows) to retrieve the file to compare to, which might involve fetching a branch or cloning a repo. Afterwards I'd invoke NPP with the checked out file. As soon as NPP has regained focus, Alt-D will start the compare. With set-old I would have to search and activate the focused file first, before triggering "Compare", unless I would have rearranged tabs before switching to the terminal emulator, but rearranging tabs is exactly what I would like to avoid as much as possible.

from compareplus.

Hello @xylographe ,

Thank you for this summary.
It matches my opinion also as I have explained so far.

Let's wait to see if @Yaron10 has anything to add to justify switching from master to set-old.

BR

from compareplus.

Hello Pavel,

I'd like to start by thanking you again for your time and work.
Please don't consider the following lines ungrateful.

"Set first" is a great feature but the old compare method is more suitable to my personal use. - I open two files at a time and compare.

This is true regarding most of the other issues we have discussed. I never use the shortcuts and I couldn't care less whether they be Alt+F or anything else. :)
The main new feature/behavior I find useful to my personal workflow is removing the marks when a line is deleted (special thanks for that).

Why did I ask you to continue developing CP at all? Why should I open all those issues?
Well, I spent some time on this plugin, became "attached" to it, and being too much of a perfectionist wanted to improve it.
After posting here yesterday I thought that this attachment of mine went too far. For two reasons:
A) You had expressed your opinion and I had mine; the matter should have ended there.
It's your project and you have every right to design it as you wish. You are a smart man and a good thinker, and great minds don't always think alike. :)
B) I also realized I had been spending too much of my expensive spare time on it.

Reading your response, the situation is clearer.
You can't state "I'm not changing it. Sorry." and expect me to further clarify my view. Sorry.

Please let me know if you would like me to report issues as I come across them. Or would you rather wait until you reach a more advanced stage in your work?

Best regards.

from compareplus.

Hello...

I try compile this with VS 2015 pro and give me compile errors

How can I compile this with VS 2015 PRO and windows 10 pro???

I need help to compile this, I don't understand c++ language

from compareplus.

@marb99
This is how I invoke MSBuild in a powershell script

function MSBuild {
    $vsct = try { (get-item -path env:\VS???COMNTOOLS | sort-object -property Name)[-1].Value } catch { $null }
    if ($vsct) {
        cmd.exe /C "CALL ""${vsct}vsvars32.bat"" & MSBuild.exe ""$($args -join '" "')"""
    } else {
        &"$(join-path (split-path -literalpath ([object].Assembly.Location)) MSBuild.exe)" @args
    }
}
MSBuild projects\2013\Compare.sln /m /v:minimal /t:Rebuild /p:"Configuration=Release;Platform=Win32"

Short version in PoSh:

cmd.exe /C "CALL ""${env:VS140COMNTOOLS}vsvars32.bat"" & MSBuild.exe projects\2013\Compare.sln /m /v:minimal /t:Rebuild ""/p:Configuration=Release;Platform=Win32"""

Short version in cmd.exe

"%VS140COMNTOOLS%vsvars32.bat"
MSBuild.exe projects\2013\Compare.sln /m /v:minimal /t:Rebuild "/p:Configuration=Release;Platform=Win32"

from compareplus.

Hello @Yaron10 ,

I'm really sorry if you feel hurt or insulted, I apologize if I've made you feel that way. I've never wanted that. As I wrote in my previous post (I hope you have read it till the end, it was rather long) I truly value and appreciate your opinion. This hasn't changed at all.

I will quote myself:

I hope I don't sound rude or impolite @Yaron10 . I am not at all.
I really appreciate you opinion and I can see your point and reasoning so far (at least I think so).
I even agree that it is really more consistent to explicitly select the old/base file and then go for "Compare". It really is more consistent with the old "adjacent file" compare method.
I would also use it officially, I have no problem with it.
But if there is a slightest chance set-old to be less convenient / efficient than master then the consistency would have to step back. I consider convenience to have higher priority than consistence.

Thank you both for the valuable opinion, I appreciate it.
Let's make the right decision - choose what's most justified, what would be best from functionality perspective and as user experience.

It is inevitable however to reach a point where we start discussing personal preferences and it can go on endlessly which wastes the precious time of all involved. This is were we need to take the decision that is best in the long term for the majority of the users. I'm sure you agree on that.
That's why I'm trying to narrow down the discussion to what's justified and why.

Our discussion above mixed three different topics:

1. master vs. set-old
2. the shortcuts
3. the menu commands order.

This quote of mine

I'm not changing it. Sorry.

was regarding the topic 3) that was already discussed before and agreed upon so I consider it closed.
I kind of put an end to it that way because it led the active and more important debate on 1) astray.

Now the active topics 1) and 2) are still open and we were actually discussing those two. Although the topic 2) had also been discussed before.

You can't state "I'm not changing it. Sorry." and expect me to further clarify my view. Sorry.

Because you personally find master inconsistent and inconvenient I spent my spare time implementing set-old . But it appears set-old is not as efficient as master for everybody.
And now because I find logic behind your request (as there is a logic behind master) I wanted to justify an eventual transition to set-old so I asked if you can think of use-cases where set-old would be more efficient for the user than master.
So I wanted to clarify your view on 1).

1. is actually blocking the progress on all other CP activities because it is a major change and I wanted to resolve it ASAP.
   Then we could move to 2).

Please let me know if you would like me to report issues as I come across them.

Please go ahead.

Thank you for all your involvement, testing, opinion and suggestions.
Those are appreciated.

BR

from compareplus.

Hello @marb99 ,

I don't have VS 2015 and Win10 so I cannot help you with that.
What I can do is to compile the source for you and send you the dll.
But there is still a lot to do on the plugin.
When the most urgent tasks are completed I'll release CP to the community. You can as well wait till that happens if it is not urgent.

BR

from compareplus.

@marb99
Did you upgrade the project file to 14.0? (AFAIK only the three lines below)

diff --git a/projects/2013/Compare.vcxproj b/projects/2013/Compare.vcxproj
index f4c189f..5de4ccc 100644
--- a/projects/2013/Compare.vcxproj
+++ b/projects/2013/Compare.vcxproj
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-<Project DefaultTargets="Build" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
   <ItemGroup Label="ProjectConfigurations">
     <ProjectConfiguration Include="Debug Unicode|Win32">
       <Configuration>Debug Unicode</Configuration>
@@ -19,12 +19,12 @@
   <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release Unicode|Win32'" Label="Configuration">
     <ConfigurationType>DynamicLibrary</ConfigurationType>
     <CharacterSet>Unicode</CharacterSet>
-    <PlatformToolset>v120_xp</PlatformToolset>
+    <PlatformToolset>v140_xp</PlatformToolset>
   </PropertyGroup>
   <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug Unicode|Win32'" Label="Configuration">
     <ConfigurationType>DynamicLibrary</ConfigurationType>
     <CharacterSet>Unicode</CharacterSet>
-    <PlatformToolset>v120_xp</PlatformToolset>
+    <PlatformToolset>v140_xp</PlatformToolset>
   </PropertyGroup>
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
   <ImportGroup Label="ExtensionSettings">

from compareplus.

@xylographe

yes I did and I don't understand the invoke MSBuild code abobe

@pnedev

Ok, i have downloaded the dll from link of xylographe abobe.

thanks to both

from compareplus.

@marb99
If you would like to give it one more try, you can download the ZIP archive from branch vs2015.

The projects\2015\Compare.sln solution file should work fine in VS 2015.

from compareplus.

Hello Pavel,

Thank you for your great work and patience. I do appreciate it.

Efficiency vs. Consistency .
I believe that there should be a balance and each case should be judged on its own merits.

Efficiency in this case:
A) What one considers efficient for his personal workflow may be inefficient for others.
B) It's negligible if I understand you correctly.

Consistency in this case:
I've tried some of the applications asking the user to enter First and Second files.
(I think that using a vertical split (left/right) might give us a clearer perspective).

In an application using this layout, "First" would be the old file.
In an application using this layout, "First" would be the new file.

Any other behavior would surely be a bug.

Conclusion:
In this case consistency is sharp and clear whereas efficiency is questionable.

In the default layout "First" should be old.
In the other optional layout "First" should be new.

Best regards.

from compareplus.

Hello Yaron,

Thank you for the clarification.

In the default layout "First" should be old.
In the other optional layout "First" should be new.

I think we shouldn't mix the compare layout here.
The layout and the concept of base/focal file are different things.
Focal is the file we want compared (we are interested in its differences).
We are not actually selecting First in terms of layout but in terms of "user focus".
Where it is placed after the compare is a user preference - some might like it on the left, other - on the right. Just as some people read and write from left to right and other - from right to left.

A) What one considers efficient for his personal workflow may be inefficient for others.

I cannot see now a use-case where master would be less efficient.
I'll think about it some more.

B) It's negligible if I understand you correctly.

Well, not exactly. If one's usual flow is affected by the "inefficiency".

OK, thanks everyone.
I know your opinion and preferences.
I'll go through the pros. and cons. once more and decide.

BR

from compareplus.

We are not actually selecting First in terms of layout but in terms of "user focus".

Agreed. Therefore, I think, it would be wise to improve the terminology. "Set as first to Compare" might be confusing (first and second are not unambiguous in this context). It should be clear from the description that this menu item is all about selecting the focal file.

from compareplus.

I agree. If I decide to keep master I'll change the names (terminology) accordingly.
Thanks.

BR

from compareplus.

Hello Pavel,

One last clarification. :)

I think we shouldn't mix the compare layout here.
The layout and the concept of base/focal file are different things.

Allow me to disagree.
The concept of the "old in left" layout is "ascended order" perception and workflow:
You open/select the old file first, then the new one and compare.

If this is not true, there's indeed no justification for the default layout.
(As for the other layout: I have some questions regarding its workflow. I'll elaborate later).

I cannot see now a use-case where master would be less efficient.

As I consider the "ascended order" the root perception of the default layout, keeping the behavior consistent with this concept is the ultimate efficiency.

Whatever you decide, CP would be great!

Thank you very much.

Best regards.

from compareplus.

Hello Yaron,

If this is not true, there's indeed no justification for the default layout.

Yes, that's true - There's indeed no justification for the default layout! :)
That's why the layout is configurable now and is a matter of user preference.
The default layout is such because you and @xylographe liked it more that way.

CP would be great!

That's what we all are trying to accomplish, yes :)
Thanks.

BR

from compareplus.

Hello Pavel,

The default layout is such because you and @xylographe liked it more that way.

Ever looked at a diff in Split view at GitHub?
Noticed that all red is on the left side, all green on the right side?
That's what I would call normal diff layout. :)

from compareplus.

Hello @xylographe ,

You are right, I don't argue :)
The default layout is made similar to GitHub and that's perfectly OK. This is the justification for the default layout.

I was referring to the false connection between 'first' file and the layout when I said that.
Sorry about the misunderstanding.

BR

from compareplus.

Hello Pavel,

Yes, that's true - There's indeed no justification for the default layout! :)
...
The default layout is made similar to GitHub and that's perfectly OK. This is the justification for the default layout.

I think we're making some progress. :)
Why is this the GitHub layout?
Why would a user prefer it? Why do I prefer it?

LTR.
In a LTR language the first/old letter is on the left and the second/new letter is on the right.
This is the rational behind the GitHub layout. This is why I prefer this layout. Yes, I want the old file on the left. Yes, the old file is my FIRST.

RTL.
Vice versa. The old/first file would be on the right.

This is why it's the "normal layout".

And if this is not true, you were right in your first statement:

Yes, that's true - There's indeed no justification for the default layout! :)

Because then we might (and should) look at it as you Pavel consistently see it.
You don't care about LTR or ascended order. You want to start with the new/focal file; this is the main file and you want it in the left/top view; this is YOUR FIRST file.

So we have two legitimate concepts. But we can't mix them.
If a (thinking) user prefers the default/normal layout, HIS FIRST is the old file.

Thank you.

Best regards.

from compareplus.

Hello Yaron and Pavel,

[Yaron] I think we're making some progress. :)

Not at all, I'm afraid.

[Pavel] The layout and the concept of base/focal file are different things.

Consequently Pavel argues (and I agree) that one always selects the focal file first, independent of chosen layout.

Yaron wants layout and file selection to be closely connected. Select the file that will be displayed on the left (top) first.

In my opinion, the former is more consistent, although it seems fair to assume that each user will pick their preferred layout and stick with it (otherwise the layout choice should be in the CP menu instead of the Options dialogue, to make a quick change between layouts possible).

In the end, it will be up to Pavel to cut the Gordian knot. :)

from compareplus.

Hello Yaron,

Why is this the GitHub layout?

Well, GitHub is a different case because you are comparing a file against itself in a previous moment in time. Here "old" is well defined and naturally is on the left.

You don't care about LTR or ascended order.

Yes.

You want to start with the new/focal file; this is the main file and you want it in the left/top view;

No. I want to start with the focal file and I don't care if it is on the left or right. All I care about is the focal file to receive the plus compare marks.

@xylographe has summarized the things well.

@xylographe ,

Let's get back to you summary on why you prefer master (several posts up).
I totally agree with you on everything written but let's speculate a bit more on this:

In practice, four out of five times I'm already working on a file (the focal file), then decide to revive some stuff from an older revision (or from another branch or a different repository).
If both files are already open in NPP, but not adjacent, master will be more efficient, because I want to compare the file I'm editing (i.e. NPP active tab) against some other file.

This is exactly one of the most common workflows for me and it's really very convenient.

However I asked myself this:
Where would I like the plus marks to be when I compare? In the file I'm currently working on or in the other file?

Interestingly enough I find it more convenient to have the plus marks in the file I compare against (making it actually the focal file). I hope it is not getting obscure :)
I'll explain further:
I'd like to know actually how the other file differs from the one I'm working on, what has been changed, added (the plus marks), etc. That actually makes the file I'm currently working on the base one - the base of the comparison.

Here is an example:

1. I have 5 open files: A, B, C, D, E
2. I'm working on / editing B
3. I get other revision of B (let's call it B+) from another repository and I'd like to compare it to B
4. I "Set first" B (here "Set first" means "Set base/old"!
5. I open B+: the order is now A, B, C, D, E, B+
6. My current focus is B+ -> I trigger "Compare"

Now what I have is B on the left with minus signs and B+ on the right with plus signs.
I actually see how B+ differs from my version B which is exactly what I want and what my workflow is.
And here B is the base file!

Moving further, I finish comparing B and B+ and I want to close B+ and continue working on B.
I close B+ and the focus is moved back to B.
Now if the "Set first" actually selects the base file and the default layout setting is used (base on the left) then B will also have retained its position because B+ has been moved by CP.
So I'll get back exactly to where I started: A, B, C, D, E!

This flow for me looks very convenient and also the inconsistency between "Set first" compare flow and "adjacent files" compare flow is gone - the currently active file when you trigger "Compare" gets the plus marks.

How do you find the described flow, is it a common use-case for you?
Do you find it convenient?

Thanks.
BR

from compareplus.

Hello Pavel,

Well, GitHub is a different case because you are comparing a file against itself in a previous moment in time. Here "old" is well defined and naturally is on the left.

We have discussed the terms before. :) We can go back to "MinusRed" and "PlusGreen"; the bottom line would be the same.
When I open two files, I know the first file would be "MinusRed". I select it as first.

No. I want to start with the focal file and I don't care if it is on the left or right. All I care about is the focal file to receive the plus compare marks.

So why have the the other layout at all? If I understood you correctly in previous discussions, the position was important to you.

Thank you.
BR

from compareplus.

Hello Yaron,

If I understood you correctly in previous discussion, the position was important to you.

I can't remember, really.
But now it is not important to me. You wanted focal on the left at the beginning and then agreed with xylographe that it would be better on the right. By focal I mean the plus marks file. I implemented an option for this because I consider it a user preference.
The important thing for me is where the plus signs are - I want them in the focal file regardless of whether we have "Set base" or "Set focal".

Thanks.
BR

from compareplus.

Hello Pavel,

These long discussions don't improve our memory. :)

I just wanted to make sure I understand your position correctly.
Yes, I changed my mind when xylographe brought up a good point.
And in general - I think the more we discuss it the clearer it becomes. That's the nature of things.

The current situation is indeed complex.
Allow me to summarize it from my point of view.

I've been trying really hard to "reconcile" "Set focal" with the default layout. Sadly I can't. :)
And I can't see how "Set base" would fit the other layout.
I assume that implementing "Set first" according to the layout would be too much. Correct?

Now, I'm afraid the other layout is not perfectly suitable to NPP.
In NPP you can trigger Compare either from a Single-View mode or Two-Views mode. In other Compare applications you don't have a Single-View mode (I hope I'm not wrong).

Let's refer only to the old compare method in a Single-View mode.
You have one file open and then you want to compare two other files.
(Allow me to use the terms old/new).

With the default layout the workflow is streaming:
I open the old file first, then the new one and Compare.
Result: new is compared to its previous the old.

With the other layout:
A) I open the old file first, then the new one and Compare.
Result: new is compared to its next. WRONG.

B) I open the new file first, then the old one and Compare.
Result: old is compared to its next. WRONG.

C) I open the new file first, then the old one, return to new and Compare.
Result: new is compared to old. Correct but not streaming.

This might be a reason to consider removing the other layout.
And then you only have to implement "Set base" (again, as I see the correct concept and workflow).

Thank you very much.
BR

from compareplus.

Hello Pavel,

I hope it is not getting obscure :)

Let me guess, you also rotate your text by 90° because you prefer to read it from bottom to top? 😜

But joking apart, what you describe is called a reverse diff (diff -R). It is called reverse because it is not the norm. :) It was traditionally used to revert patches. Of course, version control systems revert previous commits without assistance, and reverse diffs have become rare.

Sorry, I cannot understand why anyone would want the already committed file as the 'plus' file. It's part of the history of someone's repository, and you cannot (svn) or shall not (git) change history. To me the focal file will always be the one I'm working on, the one that will be committed and eventually pushed. This is independent of the origin (upstream/local) of the file.

To prevent misunderstandings: local branches in a local git repository are, of course, exempted from "shall not change history". Rearranging and squashing commits until they are ready to be pushed is one of git's chief assets.

from compareplus.

Hello Pavel,

How about two commands "Set as Old" and "Set as New"?

[+] You give the user two useful options.
[+] Users like myself who find the inconsistency confusing could use "Set as Old".
[+] Users who find it more convenient to start with the current file could use "Set as New".

[-] Would it highly complicate the implementation?

If you think it's a good idea, we can discuss again the layout options.

Thank you for your great work.
I've just seen you're also juggling with NppGTags. Unbelievable. :)

BR

from compareplus.

Hello xylographe and Yaron,

@xylographe ,

To be honest, I don't care much about diff(diff also implies diff old new) which appeared not to be that convenient to you. Besides, you are talking from the perspective that the other file is in a repository, some time in the history, unchangeable, etc. This is not always the case.
Your arguments are fine, don't get me wrong. I understand you perfectly.

@Yaron10 ,

How about two commands "Set as Old" and "Set as New"?

Having those both (+ potentially one more precious shortcut:)) looks like an overkill to me.
This is definitely not justified as it doesn't add functionality.

@Yaron10 and @xylographe ,

Ultimately this whole topic is all a matter of perception and preference.

What I wanted to accomplish when I started working on CP was to stabilize it, make its features work consistently the way they are supposed to and provide the user with sheer functionality.

Put in other words - I aimed at providing the user with the 'means' to compare. Provide him with the freedom to choose explicitly the files he wants to compare.
I think I have accomplished that.

If I move to the very beginning - all one needs as a functionality of a compare program is to be able to select one file to be base or focal (doesn't really matter which, it just focuses on one of them which receives the plus marks) and compare it to the other.

There will always be different views on which is more streaming, efficient, consistent, etc. but as long as the 'means' to compare are there the other is a matter of adjustment (getting to know CP and getting used to its specifics). If in some use-case one uses one shortcut more or one shortcut less isn't that important because in another use-case it will be the other way around (just change the perspective and the things reverse).

Because of this I'll stick to master.

It provides the 'means' to effectively compare, doesn't break the old, legacy CP ways to compare + adds a new one ("Set... whatever").
Besides it is more optimal for me because (as I said) in my head I start from the file I want to compare, this is my focus.
Additionally it is more straightforward and easy to implement from coding perspective - in both "set whatever" and "compare adjacent" flows the code sequence is the same - set one file -> switch to the other -> compare. "Compare adjacent" implicitly sets as first the currently active file and automatically switches to the other before comparing.

Thank you both for your time and effort writing and explaining your view and thinking how to make CP best. We all want that.

In "Set whatever", whatever is something you could help me with.
How do you think we should name it?

And as Yaron mentioned implementing both "Set old" and "Set new" if you think it is justified and will add value to the user I can implement at some point a user option that selects what whatever means.
Just as example we can keep "Set First" and have user option saying "First is Old" or "First is New".

Tell me what you think.

Yaron,

One more thing. I intend to keep the layout setting because it (according to me) is not connected to the old/new file selection and it just provides the user with the freedom to customize CP to his liking without constraining him to our ideas of what is right/logical.

And last, as @xylographe doesn't care much about shortcuts (so do I as long as N++ can overwrite them), what is your suggestion about the shortcuts?
Thanks.

Thank you both once again.

BR

from compareplus.

Hello Pavel,

you are talking from the perspective that the other file is in a repository

Good point, I've been using some sort of VCS for so many years, starting with SCCS IIRC, that it has left its indelible marks. :)

Just as example we can keep "Set First" and have user option saying "First is Old" or "First is New".

If I understand correctly, this theoretical option would still be independent of the user selected layout?
It would be a toggle between "Set focal" and "Set other"?
If so, it certainly would add value to CP.

In "Set whatever", whatever is something you could help me with.

As the definition of focal point is "a center of activity, interest, or attention", "Set focal file" (set the file of interest / attention) could be an option. Or, perhaps, "Set primary file", or "Set principal file"?

from compareplus.

Hello Pavel,

Congratulation! :) You've done wonders to CP.
Thank you very much. I highly appreciate your remarkable work.

I can implement at some point a user option that selects what whatever means.
Just as example we can keep "Set First" and have user option saying "First is Old" or "First is New".

That would be great.
As IMO the preferred layout is essentially and fundamentally related to "Set first", I'd suggest to set its default value in accordance with the default layout.
If you keep old vs. new as the default layout, set the default value of "First" to old.
(Last attempt to save CP from what I consider "not a very good design" in this particular feature. :) No offense please).

I'd use Set as First to Compare: set Old as First.
I prefer the terms "Old" and "New" for two reasons:
A) Being old (or considered old) is the only justification for placing "MinusRed" in the left/top view.
B) We've gotten used to "Focal", but it would require some extra thinking from new users.
"Old" and "New" are used in other Compare tools.

I intend to keep the layout setting

Great.
My suggestion to consider its removal was in the context of implementing "Set first" according to the selected layout (which I assumed would be too much).

what is your suggestion about the shortcuts?

Ctrl+Alt+letter or any other available combination which doesn't collide with Windows conventions.

Best regards.

from compareplus.

@xylographe

thanks for 2015 solution, but give me error on load

this error
C:\Users\marb99\Desktop\compare-plugin-vs2015\projects\2015\Compare.vcxproj : error : Unable to read the project file "Compare.vcxproj".

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v140_xp\Toolset.targets(0,0): The project file could not be loaded. Root element is missing.

from compareplus.

Hello guys,

@xylographe ,

If I understand correctly, this theoretical option would still be independent of the user selected layout?
It would be a toggle between "Set focal" and "Set other"?

Yes.

If so, it certainly would add value to CP.

Thanks.

As the definition of focal point is "a center of activity, interest, or attention", "Set focal file" (set the file of interest / attention) could be an option. Or, perhaps, "Set primary file", or "Set principal file"?

Good suggestions. Because of the discussed new user setting I'll keep the term first, thank you.

@Yaron10 ,

That would be great.

Thanks.

If you keep old vs. new as the default layout, set the default value of "First" to old.

Sounds OK, I agree.

I prefer the terms "Old" and "New" for two reasons:

I personally like base and focal (or modified) but I'm not "attached" to those terms.

Ctrl+Alt+letter or any other available combination which doesn't collide with Windows conventions.

OK, thank you.

@marb99 ,

I'm not sure if that will help but you could try the following:

1. Make sub-folder 2015 in folder projects
2. copy Compare.vcxproj and Compare.vcxproj.filters from 2013 to the new 2015
3. go to 2015 and double left-click on Compare.vcxproj

VS2015 should ask you to convert the 2013 vcxproj file to its format - if it does, answer "Yes".
Then try to compile CP.

BR

from compareplus.

Hello Pavel,

If you keep old vs. new as the default layout, set the default value of "First" to old.

Sounds OK, I agree.

Great.
Thank you.

BR

from compareplus.

@pnedev

thanks, but I got the same errors

but no problem ;)

from compareplus.

@marb99
Does this happen with the same VS 2015 (same computer) with which you build Subtitle Edit?

from compareplus.

@xylographe

yes, I can build Subtitle Edit and others like mp4box (GPAC) without problems

from compareplus.

@marb99

I cannot think of a reason for the second error message from VS. This file,

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v140_xp\Toolset.targets 

is part of VS 2015.

Could you verify that this file starts (after the copyright notice) with the following line?

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

This is the root element that VS 2015 claims is missing.

from compareplus.

@xylographe

Not missing.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Import Project="$(MSBuildThisFileDirectory)ImportBefore\*.props" Condition="Exists('$(MSBuildThisFileDirectory)ImportBefore')" />

from compareplus.

@marb99

You could try to,

• close VS 2015
• backup the C:\Users\marb99\AppData\Local\Microsoft\MSBuild\v4.0 folder
• remove the *.props files
• start VS 2015

from compareplus.

Hello guys,

I added config option to select which is the first file. I have used the terms base and focal.
The code has been pretty much refactored due to this feature so please try different scenarios and if you come across something please report. Regressions are also possible although I haven't observed any so far.
Thanks.

BR

from compareplus.

One more thing - please delete your Compare.ini file from your N++ plugins config folder.
It is not mandatory but will remove the obsolete settings names from the file.
Shortcuts are also changed - to use the new default CP shortcuts please delete from shortcuts.xml N++ config file all entries concerning CP.

BR

from compareplus.

Hello all,

I've changed base / focal to old / new. This looks better and seems clearer.
You'll again have to delete your Compare.ini file from your N++ plugins config folder.
Sorry for the inconvenience.

BR

from compareplus.

Hello Pavel,

Great work! Thank you very much.

1. Ctrl+Alt+S is used for Save As. How about Ctrl+Alt+T?

2. Some applications use the term "Compare" and others use "Diff".
   Do you think "Last Save diff" is clearer than "Compare to last Save"?
   The latter is not ideal but the new command is slightly confusing IMO.

3. How about "Old file" and "Left/Top" (big first letters)?

4. The new Options/Settings dialog is really good.
   How about changing "Options..." to "Settings..."?

Best regards.

from compareplus.

Hello Yaron and Pavel,

Thank you, Pavel. New features are looking good!

I agree with Yaron, "Setings..." (or "Preferences...") would be better than "Options...", because those are the terms used in NPP, as well as inside the "Compare Plugin Options" dialogue ("Main settings" and "Color settings"). Also, "Compare to Last Save" is clearer than "Last Save diff".

IMO "focal file" and "base file" ("First is:") are better than the ambiguous "new file" and "old file".

For "Old file position:" I would have chosen "Compare layout:" ("left-to-right" / "right-to-left"). However, the current descriptions are better: easier to understand, and covering the top/bottom variant.

I've tried upper case "Left/Top" and "Right/Bottom", but I think lower case looks better in a combo box. But, perhaps, with a hair space (U+200A) before and a thin space (U+2009) after the slash it might be all right (will try that later on).

from compareplus.