[Feature Request] Close file without confirmation on Ctrl+Click on close button

guy038

Hello, @vlad-che and All,

I certainly misunderstand your goal, because, to my mind, no need for an additional feature !

For example, I opened 9 files, from new 1 to new 9 and, for each of them, I just wrote the line file # where the # char stands for the number after new

Now I right-clicked on the new 3 tab, then on the close Multiple tabs option and on the Close All to the Right option

So :

Now, I got this dialog :

And, after clicking on the No to all button, I’m left with this configuration :

Best Regards

guy038

mkupper

@Vlad-Che said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

So when I finished, I just close them without saving

My automatic habit when I’m done with one of those scratchpad tabs is Ctrl+A and then Delete and then Ctrl+W on the keyboard. That’s a select-all, delete everything which empties the tab, and Ctrl+W closes it. Notepad++ already has a special case where when close an empty New ### tab that it does a silent close without prompting.

Alt+W is available as a keyboard shortcut meaning you can do

Macro / Start Recording
Ctrl+A and then Delete and then Ctrl+W on the keyboard
Macro / End Recording
Macro / Save Current Record Macro - assign Alt+W that.

Now, while it works, Alt+W will be dangerous as it will zap and close normal files too. That will make you sad, regardless of how good your backups are.

Maybe one of the Python wizards here can propose something where Alt+W fires a python script that checks to see if the current tab has no file name, meaning it’s one of the New ### tabs, and if so will clear out and close the tab. That will make it much less deadly then the keyboard macro.

Mark Olson

@mkupper said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

Maybe one of the Python wizards here can propose something where Alt+W fires a python script that checks to see if the current tab has no file name

This should probably do the trick:

'''
Empty and close a "new ###" file. Do nothing for other files.
ref: https://community.notepad-plus-plus.org/topic/25858/feature-request-close-file-without-confirmation-on-ctrl-click-on-close-button/3
uses PythonScript: https://github.com/bruderstein/PythonScript/releases
'''
import re
from Npp import notepad, editor

def EaCinX_callback():
    fname = notepad.getCurrentFilename()
    # This checks if it's a "new ###" file using the filename.
    # This isn't foolproof; a "new ###" file that was renamed could fail this check.
    # However, I'd rather avoid accidentally writing a check that matches normal documents by accident
    if not re.fullmatch(r'(?-i:new \d+)', fname):
        print('*NOT* running empty_and_close_if_new_X_file.py because %s is not a "new ###" file' % repr(fname))
        return
    print('Running empty_and_close_if_new_X_file.py on file %s' % repr(fname))
    editor.clearAll()
    notepad.close()

    
if __name__ == '__main__':
    EaCinX_callback()

TBH, I prefer the (Ctrl-A ->Backspace -> Ctrl-W) sequence for single files, and the “Close all to the Right/Left” for large numbers of files.

xomx

@Mark-Olson

I use a similar script myself. I see two problems with yours:

There can be a regular file named “new 1”, this can be simply fixed by adding one more check (this also fixes your dilemma with the renamed “new ###”):

if os.path.isfile(fname):
        return # the N++ tab is a real file (not a DOC_UNNAMED "new xxx")

N++ user can use translated GUI, so the “new xxx” will have a different name. For this I have no easy Python sln. (in N++, you will obtain the right string e.g. by

generic_string newTitle = ((NppParameters::getInstance()).getNativeLangSpeaker())->getLocalizedStrFromID("tab-untitled-string", UNTITLED_STR);

I also already thought about adding something like (I saw many requests for similar feature):

but when I saw that some people can use the “new xxx” for months without a regular saving, I decided to not create such PR.

guy038

Hello, @xomx and All,

@xomx, you said :

but when I saw that some people can use the “new xxx” for months without a regular saving, I decided to not create such PR.

But, how is the situation different, for example, from the case Close All BUT This ? Indeed, whatever your choice, in the Close Multiple Tabs sub-menu, you always get the dialog for saving, isn’t it ?

So, I suppose that a new option Close All Unnamed could be of some interest ;-) Of course, the obvious condition would be to verify that such files do not exist at all on the system !

Best Regards,

guy0038

Alan Kilborn

@Mark-Olson said:

def EaCinX_callback():

Whew, had me afraid for a minute that the script actually used real scripting callbacks…it doesn’t.

editor.clearAll()

A seemingly equal alternative to clearAll() here would be editor.setSavePoint().

It should be pointed out that for optimal use the running of the script should be tied to a keycombo, and, while that’s fine, it doesn’t meet the desire of the OP to “Ctrl+Click on (the) close button (on the tab)”. But OPs don’t always get everything they want.

@xomx said :

N++ user can use translated GUI, so the “new xxx” will have a different name

I don’t consider this type of thing a problem when providing scripts here. If someone is using a different localization, it’s on them to change the string in the script’s code to match what they’re using. Having the script solve this problem is too much burden on the script.

@guy038 said:

how is the situation different, for example, from the case Close All BUT This ?

It’s (a hypothetical “Close All Unnamed”) different because we’re talking about closing only new # files, and Close all BUT this will close everything except the currently active tab, regardless of the other tabs being softnamed (new # files) or hardnamed (saved into the file system).

guy038

Hello, @vlad-che, @mkupper, @mark-olson, @xomx, @alan-kilborn and All,

Alan, I still don’t understand why this hypothetic new option Close All Unnamed would be more delicate to manage than all the other options ?

As I said above, after clicking on this new option, you would get the save dialog, anyway !?

RR

guy038

Alan Kilborn

@guy038 said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

I still don’t understand why this hypothetic new option Close All Unnamed would be more delicate to manage than all the other options ?

As I said above, after clicking on this new option, you would get the save dialog, anyway !?

Truly @somx should answer this.

It seems everyone views softnamed files differently. I’d only use them for something temporary and unimportant (but I don’t even do this; see next paragraph). If I had several open (for whatever reason) and I wanted them gone, I would want a quick way to close them without being prompted. So maybe that’s the kind of command that @xomx had in mind – but then he rethought it because he realized others used softnamed files in other ways, i.e., more permanent ways, even though this is not really advisable.

As I’ve said a few times in various postings, I never use softnamed files. I have remapped my Ctrl+n to run a script that creates a file named (e.g.) 202406060801_.txt in my %TEMP% folder. Softnamed files create so much noisy discussion here, I wish they didn’t exist.

PeterJones

@xomx said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

There can be a regular file named “new 1”, this can be simply fixed by adding one more check (this also fixes your dilemma with the renamed “new ###”):
if os.path.isfile(fname):
        return # the N++ tab is a real file (not a DOC_UNNAMED "new xxx")

Instead of making it “adding one more check”, why not make that the only check – that way, whether it’s “renamed-but-never-saved” files, or “different-localization-default-name” files, that singular check will

For this I have no easy Python sln. (in N++, you will obtain the right string e.g. by
generic_string newTitle = ((NppParameters::getInstance()).getNativeLangSpeaker())->getLocalizedStrFromID("tab-untitled-string", UNTITLED_STR);

Should there be an NPPM_GETLOCALIZEDSTRING message that plugins can use to gain access to the internal localized strings? Because I have a feeling (*) that a lot of plugins completely ignore localization , and if the plugin-message-interface were to at least give them access to the same localizations that Notepad++ uses, that could be a step-up in accessibility for plugins in localized N++ instances.

(*: “I have a feeling” = I am not sure, because I don’t use localized N++. But maybe some or all plugin authors are more on top of giving translated versions than I guess.)

xomx

@guy038 said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

But, how is the situation different, for example, from the case Close All BUT This ?

My script (and previously considered PR) closes such “DOC_UNNAMED” tabs without the msgbox warning even when they are dirty. That is why the script contains the line with editor.clearAll() because in N++ are the empty tabs closed without a warning (even if they have the N++ dirty-flag ON). I am using so because I agree with:

@Alan-Kilborn said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

I’d only use them for something temporary and unimportant

@Alan-Kilborn said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

I would want a quick way to close them without being prompted

But maybe what could be acceptable is a variant of “Close All Unnamed” without the above W/O-any-warning-closing speed up. Now when I think about it, it might not be a bad idea to have a function that could generally handle other types from the enumeration similarly (DOC_UNNAMED, DOC_DELETED, DOC_MODIFIED, DOC_NEEDRELOAD, DOC_INACCESSIBLE). So then one could be able to close e.g. all the inaccessible files at once.

xomx

@PeterJones said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

Instead of making it “adding one more check”, why not make that the only check

There could be also the DOC_DELETED and DOC_INACCESSIBLE N++ tabs…

Alan Kilborn

@PeterJones said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

Should there be an NPPM_GETLOCALIZEDSTRING message that plugins can use to gain access to the internal localized strings? Because I have a feeling (*) that a lot of plugins completely ignore localization , and if the plugin-message-interface were to at least give them access to the same localizations that Notepad++ uses, that could be a step-up in accessibility for plugins in localized N++ instances.

But do plugins need enough of this to make it worthwhile?
You’d only get access to strings that exist already in Notepad++, and plugins, by their nature, do different things from native Notepad++, so they use their own wording typically.

PeterJones

@Alan-Kilborn said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

But do plugins need enough of this to make it worthwhile?
You’d only get access to strings that exist already in Notepad++

There might be a reason for knowing the text of certain menu entries (for example). Or when you are trying to manipulate an existing Notepad++ dialog, sometimes you have to search for a control with a certain title text – which will be different in a different localization.

But being able to borrow the localization for standard entries like “Copy” or “Paste” or “OK” and “Cancel” would definitely be useful for plugin user interface; or for the people who make extra-find/replace, knowing the translations for “Find What” and “Replace With” and “Find Next” and similar commands would be useful.

Whether such situations are enough to justify the interface, I don’t know. It just sounded useful to me.

Alan Kilborn

@PeterJones

OK, you’ve made some good points about it!
Put your feature request in. :-)

PeterJones

@Alan-Kilborn said in [Feature Request] Close file without confirmation on Ctrl+Click on close button:

Put your feature request in. :-)

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/15250