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?



  • @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



  • 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



  • @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?



  • @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.


Log in to reply