Why doesn't a tab close return you to tab most recently worked in?
I’ve noticed an annoying-to-me Notepad++ behavior.
Make a bunch of new editor tabs:
new1 new2 new3 new4 new5 new6
Click on the new2 tab as if you want to edit that “file”.
Now click the little red X on the new5 tab.
new5 closes and you are still in the editing area for the new2 tab (good).
So now we have:
new1 new2 new3 new4 new6
Click on the new4 tab as if you want to edit that “file” (but don’t make any edits).
Now click the little red X on the new4 tab.
new4 closes and you are taken to the editing area for the new6 tab.
I find this bad and wish I was returned to new2 as that is where I was last working, not placed into new6 apparently because it is the right-most tab.
Is there a solution/workaround to this?
I don’t know of a npp internal solution but a python script may do the following
register notepad callback BUFFERACTIVATED and FILECLOSED
an editor callback UPDATEUI
have a variable which holds the bufferid returned by BUFFERACTIVATED calback
and a variable which indicates that something has changed by checking UPDATEUI
High level logic:
whenever the BUFFERACTIVATED callback returns save the current bufferid
when UPDATEUI callback returns and is different to updated=10
save the saved bufferid as the last edited document.
When a FILECLOSED callback returns, check if last edited document is still there and
if it is activate it.
Only tested in brain - so unreliable ;-)
If you want to build Notepad++ by yourself, here is a patch for this:
I haven’t tried this, but thank you for your comment.
What are the chances that something like this will get integrated into the main Notepad++ sources? (I would launch a campaign for this!)
I also noticed this other related scenario:
- Have 3 documents open in View 0 (main view) and View 1 (secondary view) unopened
- Be editing in the leftmost (FIRST) editor tab
- Right click editing tab for the THIRD editor tab
- Choose “Move to other view” from the popup context menu
What will result is the THIRD document will move to View 1 as desired, but the active editor tab in View 0 will be set to the SECOND document tab instead of the FIRST. @gstavi , I wonder if your patch handles this situation as well?
I guess that this patch would not have much objection.
Since I have multiple patches that some of them will encounter objection I didn’t try to submit anything to mainline.
Not sure exactly what are your expectation from the scenario you described and what will be the results but my guess is that when a document is moved to another view the source view should choose another document and that will probably happen using the same code I patched so this decision will be based on MRU ordering rather than tab ordering.