Why doesn't a tab close return you to tab most recently worked in?

[Alan Kilborn]

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?

[Claudia Frank]

@Alan-Kilborn

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 ;-)

Cheers
Claudia

[gstavi]

If you want to build Notepad++ by yourself, here is a patch for this:
Use-MRU-when-choosing-new-file-to-activate-after-clo.patch

[Alan Kilborn]

@gstavi

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?

[gstavi]

@Alan-Kilborn

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.