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.