Move to Other View moves the wrong file

[Ekopalypse]

@deleelee

But I don’t understand when this should matter?
If you are thinking about a plugin or a scripting issue,
you have to check which view the document is currently in anyway.
But why is it important from a usage point of view whether the open document is in the first or second view?
And the other view is … the other view!
What am I missing?
I understand that it can be useful to open documents in a certain view, but then … why is it important to know where the document is now?

[Alan Kilborn]

@Ekopalypse said in Move to Other View moves the wrong file:

But why is it important from a usage point of view whether the open document is in the first or second view?
What am I missing?

Possibly this example:

• fresh copy of N++ (has only new1 tab)
• Ctrl+n to create new 2
• IMPORTANT: type a character into each tab so that they are dirty/modified (see way down below on why this is important)
• right-click each tab in turn and Move to Other View

There are now no tabs in the primary view and 2 in the secondary.
But user thinks of both being in the primary (because that’s what it LOOKS like to them – “only one view so of course it is the primary”).

Now right click on e.g. new 2 and Move to Other View.
The user’s expectation is that the view will be split and new 2 will be on the right.
However, when the split occurs new 2 is on the left – user is feeling disconcerted. :-)

---

Now, about the IMPORTANT step above:

Try doing the above steps without doing the “important” step.
As soon as the second tab is moved to the other view, the other view is closed and only a new 1 document remains open. Now the user is very surprised! :-(

I believe this is an effect of second-class handling of unmodified softnamed (e.g. new 1, new 4) “files” (er, tabs). Further examples would be:

• an unmodified softnamed file cannot be saved (an issue was rejected on this point in the distant past)
• unmodified softnamed files will not be remembered as even being present, over a N++ restart cycle

To me, these are just further reasons to not use softnamed files (and to not allow quitting N++ with such tabs in existence). For myself, I have a script that, when I want to make a new file, creates a file in %TEMP% and names it with something derived from the current timestamp. If this file is to be “permanent”, when I’m ready (which typically isn’t too far in the future), I’ll rename the file to the correct location for it and give it a proper name.

[Ekopalypse]

@Alan-Kilborn said in Move to Other View moves the wrong file:

I think I understand what you mean, but the reason why it would be important for me as a user to know,
whether buffer X was opened in the primary or secondary view is not yet clear to me.
The example with the empty buffers is nice to demonstrate that something is wrong,
but why should someone have to do this every day?

To me, these are just further reasons to not use softnamed files (and to not allow quitting N++ with such tabs in existence)

same for me … unsaved files are unimportant … otherwise I would save them …

[Alan Kilborn]

@Ekopalypse said in Move to Other View moves the wrong file:

I think I understand what you mean, but the reason why it would be important for me as a user to know,
whether buffer X was opened in the primary or secondary view is not yet clear to me.

On its own, I suppose it isn’t important. But, as I tried to point out, it becomes important to a user if they expect to see something happen in area X of the window and it actually occurs in area Y.

The example with the empty buffers is nice to demonstrate that something is wrong,
but why should someone have to do this every day?

The empty buffer example was totally tangential to the main discussion in this topic. It can be disregarded.

[xomx]

@Alan-Kilborn & all

Due to lack of time I have not fulfilled my promise in that issue yet, sorry.

I looked at this now and it seems to me not as easy as it looks like to Yaron10 there.
I quickly found the right place in the N++ src where to interfere but at the end I found only one way how to do the requested “Make sure a single-view is always MAIN_VIEW” (I just reused the same N++ code activated, while a user manually moves N++ tab to other view, means that I simply moved all that N++ other-view tabs back to the main-view one-by-one in the right order, sigh). So maybe my solution found could become pretty slow with many many N++ tabs, IDK.

Anyway, before any possible follow-up on this issue on GitHub, I would like to know if this patched binary behaves as users here say it should:
http://xomx.wz.cz/NotepadPlusPlus/npp_issue8526_v866devel_x64_Release.zip

[Alan Kilborn]

@xomx said in Move to Other View moves the wrong file:

Due to lack of time I have not fulfilled my promise in that issue yet, sorry.

No worries; thanks for your efforts.

---

my solution found could become pretty slow with many many N++ tabs, IDK.

Yes, probably that would be true.

---

What about an alternative idea?: If the second view is open, don’t let the final tab be removed from the primary view (either via a move-to-other-view or a closure) – if this occurs, maybe simply open a blank new # file in the primary view, which would keep that view open. Thus one always has open either primary or primary-and-secondary.

[xomx]

@Alan-Kilborn said in Move to Other View moves the wrong file:

If the second view is open, don’t let the final tab be removed from the primary view (either via a move-to-other-view or a closure) – if this occurs, maybe simply open a blank new # file in the primary view, which would keep that view open.

Hmm, I rather like how it is now (the last closed tab closes the view at the same time if there is the dual view mode). But you have a point - in the Preferences > General > Tab Bar is the “Exit on close the last tab” checkbox, which is OFF by default, so such a “new xxx” tab is spawned whenever the last tab is closed in single view (which is somewhat similar to your suggestion for the double-view mode).

BTW, even now, if a 2nd view is closed in the N++, a “new xxx” tab is already opened as a precaution for the now closed & hidden view (I saw this while debugging the views closures, this is how the N++ is designed to always have at least one opened tab in view…)

[Alan Kilborn]

@xomx said in Move to Other View moves the wrong file:

BTW, even now, if a 2nd view is closed in the N++, a “new xxx” tab is already opened as a precaution for the now closed & hidden view (I saw this while debugging the views closures, this is how the N++ is designed to always have at least one opened tab in view…)

OK…but this does nothing for the user (i.e. user doesn’t care what N++ does internally and he can’t see) and doesn’t do anything for the main discussion of this thread.

[Verify Btc]

This post is deleted!

[xomx]

@Alan-Kilborn said in Move to Other View moves the wrong file:

and doesn’t do anything for the main discussion of this thread.

As you suggested:

@Alan-Kilborn said in Move to Other View moves the wrong file:

maybe simply open a blank new # file in the primary view, which would keep that view open

I wanted to show that N++ in fact already does that stuff and so it would be enough to change just the main-view hiding part of the code.

[mkupper]

I’m thinking that it’s a design choice that the primary/secondary names of the views is not displayed. You can move files from one view to the “other” view. You can rotate the views. If you rotate twice then you have swapped them. When you close the last file in view then it vanishes and the remaining view runs in full screen mode.

The default is the primary view on the left and secondary view on the right. When both views have files and thus are visible you can:

• Switch the focus between the views using F8.
• Snap a view to “full” screen using the little arrows at the top and bottom of the view divider. This is a bit confusing as you can’t snap back to the divided 2-view mode but instead need to drag the divider. The confusion increases after snapping when you see the little arrows pointing towards the outside edge of Notepad++ but they don’t do anything when clicked. The F8 switch between views does “nothing.” The first time you use the F8 toggle it shoves the divider over a few pixels but not enough to make the other view usable.
• Right click the divider bar and rotate the views. You can rotate right (which means clockwise) or left (which means counter-clockwise). If you rotate in the same direction twice you have reversed the positions of the views. A confusing aspect is when you have a view snapped to be visible and then do rotate twice then it snaps to the other view.

One more detail that can be confusing is the handling of empty new # tabs. If an empty new # tab is the only thing in a view and then you move either a normal file or another new # (empty not) then the empty new # tab vanishes, if, and only if, it also does not have an undo buffer. Normally you can Ctrl+W close an empty new # and it’s silently destroyed, even if it has an undo buffer and is thus dirty. Notepad++ has an exception where it won’t auto-destroy a dirty new # tab if it’s the only thing in a destination view.

When you close or move-out all of the tabs in the primary view then the secondary view snaps to full screen without a divider bar. The OP that started this thread was confused when then then did a “move to other view” which made the primary view visible. The OP does not mention rotating and so I assume that means the primary view was restored to the left side of the divider. The OP either had forgotten the view that had been looking at was the secondary view or had made the assumption that if only one view is visible that it must be the primary. The OP was confused that the “other” view popped up on the left when they had expected it to be on the right.

Thus, while the view system has its quirks I don’t see a compelling case to make any changes to it. It may help to know why @Tim-Jarrett, the OP, or others are using the view system.