View files order changes after compare about compareplus

[Yaron10]

Hello xylographe

Good to have you more involved. Just promise to be a fair judge. :)

See notepad-plus-plus/notepad-plus-plus#1515 and jsleroy/compare-plugin#13 (comment).

Best regards.

[pnedev]

Hello @xylographe ,

That's the current behavior, yes. Thanks for moving it here as a separate issue.

Hello @Yaron10 ,

I do remember that you had already reported this in the original repo, thanks for that.
We discussed this back then and as far as I remember I told you this would be rather controversial requirement aside from the implementation difficulties. Besides, with the old plugin implementation it was impossible.

Well, now things are a bit different. It should be possible to implement it now after the code re-organization but still quite difficult (as a preliminary assessment).

I'll think about that but I don't promise anything.

---

And now let's view some behavior details that bother me (leaving the implementation aside):

Scenario 1

1. We have 4 files - A, B, C, D
2. We compare B and C -> View1: A, B, D; View2: C
3. We manually reorder View1 -> A, D, B
4. We close the compare -> What should be the order? A, D, C, B? A, D, B, C?

Scenario 2

1. We have 4 files - A, B, C, D
2. We compare B and C -> View1: A, B, D; View2: C
3. We open in View1 a new file E -> A, B, D, E
4. We close B -> C is returned to View2, should the order be A, C, D, E? A, D, E, C?

Now imagine a mix of several compared pairs.
Imagine a mix of the above scenarios.
What if we start the compare from 2 view mode and move one of the files to the other view? Where should it be, as the last file or next to the file it was compared to?

Thank you both.

BR

[xylographe]

@Yaron10
Thank you for the links. I must admit I'm not a regular sub-view user. I assigned Alt-C to "Clone...", then use Ctl-W to restore. On the rare occasion that I use "Move..." it will be immediately after opening a file with the intention to keep it open for only a short period of time (typically to copy/cut&paste a few lines). In any case my sub-view will (almost) never accommodate more than one file. Having read the links you posted, I “played” a bit with the NPP views. I found it astonishing that NPP behaviour is often counter-intuitive. I also now realise the annoying file order changes are an NPP “feature” rather than a CP issue.

Regarding the CP sub-menu item order, I wouldn't mind either way. If you really dislike it, why not adjust it in createMenu() in Compare.cpp?

@pnedev
I think, file order would be best based on predecessors (I'm used to left-to-right latin script, it might be different for those who are used to right-to-left scripts). Let's say, the predecessor of file X in the main view is PM(X), i.e. the file to the left of X. The predecessor of file X in the sub view will be PS(X). If P*(X) equals none file X is the leftmost file in that view. If P*(X) equals null file X has never been in that view, i.e. if NPP is invoked with argument X (and there is no previous session) then PM(X) = none and PS(X) = null.

Trivial example: assume one view (main view), four files: A, B, C, D. PM(D) == C, PM(C) == B, PM(B) == A, PM(A) == none,PS({A,B,C,D}) == null`.

• When B is moved to the right: PM(C) = PM(B); PM(B) = C; PM(D) = B (new order is A, C, B, D).
• When B is moved to sub view: PM(C) = PM(B); PS(B) = none (A, C, D | B)
• When A is moved to the right: PM(C) = PM(A); PM(A) = C; PM(D) = A (C, A, D | B)
• When B is moved back to main view, position follows PM(B) (== C): PM(A) = B (C, B, A, D)

Applied to scenario 1:

1. (A, B, C, D | -) PM(A) == none, PM(B) == A, PM(C) == B, PM(D) == C, PS({A,B,C,D}) == null
2. (A, B, D | C) <== PM(D) = PM(C); PS(C) = none; move(C)
3. (A, D, B | C) <== PM(D) = PM(B); PM(B) = D
4. (A, D, B, C | -) <== move(C) [position follows PM(C) == B]

Applied to scenario 2:

1. (A, B, C, D | -) PM(A) == none, PM(B) == A, PM(C) == B, PM(D) == C, PS({A,B,C,D}) == null
2. (A, B, D | C) <== PM(D) = PM(C); PS(C) = none; move(C)
3. (A, B, D, E | C) <== PM(E) = D; PS(E) = null; open(E)
4. (A, D, E | C) <== PM(D) = PM(B); PM(C) = PM(B); close(B)
5. (A, C, D, E | -) <== PM(D) = C; move(C) [position follows PM(C) == A]

[pnedev]

Thanks for the detailed feedback @xylographe .
I'll read it carefully when I get to this point.

BR

[Yaron10]

Hello Pavel and xylographe,

Thank you Pavel for considering fixing the order issue.

If the order in the top view didn't change, how would you restore the order?
File C's index was 2 (first is 0 I assume) before Compare, you would look for index -1 (taking into consideration first/last) and place C after it.

So: A, D, C, B.

Alternatively you can look for index + 1 and place C before it. - A, D, B, C.
So your two options are OK. :)

Thinking a bit more about it:
If the order (or the number of opened files) does change it's "a whole new ball game". Now it's not restoring but rearranging.
How about a third option? - Don't do anything.
If you can restore the previous order - great. If you have to rearrange (and you can't really know if the user prefers option A or B) - don't even try. :)

What do you think?

---

xylographe,

I found it astonishing that NPP behaviour is often counter-intuitive. I also now realise the annoying file order changes are an NPP “feature” rather than a CP issue.

Indeed. Apparently NPP's views handling can be much better. :)

Regarding the CP sub-menu item order, I wouldn't mind either way. If you really dislike it, why not adjust it in createMenu() in Compare.cpp?

Thank you.
I can change that for my personal use.

We can't even start to compare Pavel's work and investment to ours. :)
Still, we all want to get the best final product (not necessarily for our use).

Pavel considers "Set first" as the main Compare method.
I think the main method is: start NPP, open two files and Compare.

Thank you also for the order analysis.
If Pavel decides to "rearrange", I'll go over it again.

Best regards.

[xylographe]

It's simply a matter of "getting used to". At first I didn't know what to think of this new "Set first" ("Select first" at that time) item, but now I wouldn't know what to do without it. Before "Set first" I had to move tabs before "Compare" and after "Clear Compare", now only after "Clear Compare". And perhaps (fingers crossed :) ) Pavel will find a way to fix that too.

[Yaron10]

"Set first" is undoubtedly a fantastic feature.
Indeed, it may be a matter of "getting used to".

[pnedev]

Thanks @Yaron10 for you feedback on this.
As I said to @xylographe I'll come back to this issue later and will read both your suggestions more carefully then.
I'll postpone this for now.

BR

[Yaron10]

Thank you Pavel.

BR

[pnedev]

Hello guys,

A quick update on this request.

Currently it appears there is no effective way to re-order the N++ file tabs programmatically. Only mouse Drag'n'Drop action can do that.
I have created N++ feature request about that (notepad-plus-plus/notepad-plus-plus#1864) and I could probably implement it at some point.
Without file re-order commands support from N++ there is not much I can do from CP to restore the files order after compare. The workaround method is REALLY ineffective.

BR

[Yaron10]

Hello Pavel,

Thank you very much. I do appreciate that.

BR

[pnedev]

Hi guys,

FYI:
Move tab forward/backward commands are implemented in the latest Notepad++ code base:
notepad-plus-plus/notepad-plus-plus@9cf45de

I suppose next N++ version will have those so I'll be able to implement compared files order restoring.

BR

[Yaron10]

Hello Pavel,

That's great.
Thank you.

BR

[pnedev]

Hello all,

File position restoring is implemented now in a most simple form. This seems to work for me but in your more advanced work-flows you might need some additional tuning, so please try.

You'll have to use N++ v7 x32 Release Candidate.

I'm closing this issue now but you can still use it to provide feedback if need be.
Thank you.

BR

[Yaron10]

Hello Pavel,

Great news.
I'd like to apply my personal adjustments to v7. I'll try this important commit soon.

Thank you very much.
BR

[Yaron10]

Hello Pavel,

The "simple form" is a beautiful implementation.
And as I've written numerous times before: Another major improvement.
Thank you so much.

Scenario 1

1. We have 4 files - A, B, C, D
2. We compare B and C -> View1: A, B, D; View2: C
3. We manually reorder View1 -> A, D, B
4. We close the compare -> What should be the order? A, D, C, B? A, D, B, C?

Result: A, D, C, B. 👍

Scenario 2

1. We have 4 files - A, B, C, D
2. We compare B and C -> View1: A, B, D; View2: C
3. We open in View1 a new file E -> A, B, D, E
4. We close B -> C is returned to View2, should the order be A, C, D, E? A, D, E, C?

(4) We close B -> C is returned to View1).

Result: A, C, D, E. 👍

What if we start the compare from 2 view mode and move one of the files to the other view? Where should it be, as the last file or next to the file it was compared to?

Result: Last file. 👍
Currently this is NPP's behavior on "Move to Other View" and CP should not interfere.

---

Some fine-tuning. :)

Single-View - A, B, C.
Compare B and C (B in the Sub-View).
Close A.
Clear Compare.

Result: C, B.

As I've argued above:

If the order (or the number of opened files) does change it's "a whole new ball game". Now it's not restoring but rearranging.

What do you think?

BR

[pnedev]

Hello Yaron,

Thanks for the thorough testing.
This is a good catch, I'll fix it soon.

BR

[Yaron10]

Hello Pavel,

Thank you very much. I do appreciate it.

BR

[pnedev]

Hello Yaron,

The latest problematic case you reported should be fixed, thank you.

BR

[Yaron10]

Hello Pavel,

It works like a charm.
Thank you very much.

The Issues List is getting shorter; not a single major one (from a user point of view) is still there. 👍 👏

BR

[pnedev]

Hello Yaron,

This one - #58
is still a critical one.

Thank you.

BR

[Yaron10]

Well...

Anyway, you certainly deserve a standing ovation. :)

BR