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

xomx

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