Move to Other View moves the wrong file
-
With 2 files open selecting ‘Move to other view’ on the name tab of one of them moves the other file to the other view instead!
-
Hello Tim-Jarrett,
tried with different scenarios but wasn’t unable to reproduce it.
Does this always happen?
Have you installed some plugins? If so, can you give it a try to start npp with -noPlugin switch to check behaviour?Cheers
Claudia -
Hi Claudia
Tried -noPlugin option, but it still occurs.Here’s how I could reproduce it -
1: Start Notepad++
2: Close all files so you just have New:1 open
3: Type text “File 1” in New:1
4: Create a new file New:2
5: Type text “File 2” in New:2
6: Select New:1 tab
7: Right-click New:1 tab and select “Move to Other View”
8: New:1 stays where it was and New:2 moves instead.I noticed it doesn’t happen every time, but more often than not.
Regards
Tim -
Hello Tim,
that is strange, indeed. I tried it 1000 times and it didn’t occur.
A shot in the dark, as you installed npp, did you choose local or appdata config?
If it was appdata, do you mind renaming notepad++ in %APPDATA% directory and trying again?
If this solves the issue, can you zip the renamed notepad++ directory and upload it?Cheers
Claudia -
Tim, here’s what is probably going on:
NPP has two ‘view ports’. For my setup, it’s a top view and a bottom view.
If I open/create two files as you outlined, both files are in the top view port. If I move file1 to the bottom view and then move file2 to the bottom view, there’s nothing left in the top view, and it collapses and disappears. At this point the bottom view takes up the whole window and NPP looks just like it did when I started, but in actuality, both files are now in the bottom view and the top view is hidden. Now, if I move file1 to ‘other view’ what I’m really asking it to do is move file1 from the bottom view to the top view. What you THINK you’re doing is moving file1 to the bottom view, but it’s already in the bottom view. It just looks like file2 is getting moved but in reality it’s staying in the bottom view and the top view is uncollapsing and getting filled with file1.If you move both files to top view (or maybe in your case the left view) the move behavior you’re expecting should be back.
TLDR: NPP has two views that stay put. If you move everything out of a view it will collapse, but it keeps the same place relative to the other view.
-
@cipher-1024 said in Move to Other View moves the wrong file:
NPP has two views that stay put. If you move everything out of a view it will collapse, but it keeps the same place relative to the other view.
I feel this is very non-user-friendly and is not what the expected behaviour is. The ‘other view’ should be exactly that - the other view, regardless of which view is ‘active/visible’. If there’s no other way for this work, at the very least, it would be helpful to name, or indicate in some other way, which view is which.
It would also be helpful if what you’ve said was included in the user manual because it currently just says “the current file will be moved from one View to the other”.
-
@deleelee said in Move to Other View moves the wrong file:
@cipher-1024 said in Move to Other View moves the wrong file:
NPP has two views that stay put. If you move everything out of a view it will collapse, but it keeps the same place relative to the other view.
I feel this is very non-user-friendly and is not what the expected behaviour is. The ‘other view’ should be exactly that - the other view, regardless of which view is ‘active/visible’. If there’s no other way for this work, at the very least, it would be helpful to name, or indicate in some other way, which view is which.
I think you have misunderstood the statement you quoted…
It would also be helpful if what you’ve said was included in the user manual because it currently just says “the current file will be moved from one View to the other”.
… and/or misunderstood what the User Manual describes.
Notepad++ has two views: internally, it calls them “Primary” and “Secondary”, but the end user doesn’t care about that (though plugin and script authors do) – because from the end-user’s perspective, everything is relative to where the file currently is. The “Other View” means the View it’s not currently in, always, no ambiguity about it. This is completely natural to me, and has been from the moment, all those many years ago, that I learned about Notepad++ having two Views.
With a brand-new installation of Notepad++, when you first open files, they all go in the Primary View. If you tell a file in the Primary View to Move to Other View, it will move to the Secondary View. If you tell a file in the Secondary View, it will move to the Primary View.
If you started with two files in the Primary View, and moved them both into their Other View, they are now all in the Secondary View, and the Primary View is hidden. But if you then move one or more back to the Other View again, the Primary View will become visible again, in the same location it used to be in. See this series of screenshots:
-
@deleelee said in Move to Other View moves the wrong file:
I feel this is very non-user-friendly and is not what the expected behaviour is. The ‘other view’ should be exactly that - the other view, regardless of which view is ‘active/visible’.
The example given in the year 2016 created confusion because there were just two files involved. During testing, both files were moved to the secondary view, which caused the primary to collapse or vanish. From a user perspective they were looking at the primary view as it was the only one visible. However, both files were on the secondary view. When they moved one of those two files to the “other” view, from Notepad++'s perspective, they were moving it to the primary view. Notepad++ made the primary view visible again which popped up in its usual spot. The original person was confused as Notepad++ appeared to move the “other” file.
Had the OP’s testing been done with a bunch of files in the secondary view and none in the primary then I suspect there would have been less confusion as the one file they moved did indeed move from the view they were looking at into the “other” view, which popped into visibility in its usual spot for the primary view.
If there’s no other way for this work, at the very least, it would be helpful to name, or indicate in some other way, which view is which.
I agree with this. I think at one time Notepad++'s developer was thinking about implementing many views and not just the primary/secondary views we ended up with. The code is mostly there to support many views. If you look at your session.xml file while experimenting I think you’ll get a better understanding of the views. Exit and restart Notepad++ to refresh the session.xml file when doing this. At present only the
As the multiple views logic was, and remains, a work in progress, it seems the developer never got around to making the views more visible, allowing you to name them, etc. Plus I personally would love to make it so that I could tell Notepad++ which view to open a file in. Opening files defaults them to being added to the active view and there are times I’d rather it be opened in another view.
It would also be helpful if what you’ve said was included in the user manual because it currently just says “the current file will be moved from one View to the other”.
The manual is correct. Let’s try this, if you can propose wording that clearly describes this view thing without leaving the average person feeling lost then I suspect your wording would be accepted for the manual. The official place to suggest changes to the manual is https://github.com/notepad-plus-plus/npp-usermanual/issues/ If you make a formal suggestion then I would include a link back this forum thread to provide people lurking on github with some context to your suggestion.
-
Depending upon what you care about, this issue may be relevant to the current discussion:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/8526 -
@Alan-Kilborn said in Move to Other View moves the wrong file:
Depending upon what you care about, this issue may be relevant to the current discussion:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/8526Thanks Alan, Maybe I could have worded it better but that is what I was trying to say. When in single pane view, that pane should ALWAYS become the PRIMARY view.
-
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? -
@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
new1tab) - 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 2and Move to Other View.
The user’s expectation is that the view will be split andnew 2will be on the right.
However, when the split occursnew 2is 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 anew 1document 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.
- fresh copy of N++ (has only
-
@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 …
-
@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.
-
@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
-
@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. -
@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…)
-
@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.
-
This post is deleted! -
@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.
