I’ve been footling around with my plugin a bit to try and generate a PR automatically when a new version is released. So - is the layout of the json files significant.

Most of the entries look like

\t\t\t{ \t\t\t"folder-name": "Linter++", \t\t\t"display-name": "Linter++", \t\t\t"version": "1.0.3.0", \t\t\t"npp-compatible-versions": "[8.7.5,]", \t\t\t"id": "F56573351010B62BFC75039725496C8687D53E82A3F47074F1F1B629A37A92C1", \t\t\t"repository": "https://github.com/ThosRTanner/notepad-pp-linter/releases/download/1.0.3/plugin_dll_ARM64.zip", \t\t\t"description": "Allows realtime code check against any checkstyle-compatible linter: jshint, eslint, jscs, phpcs, csslint, and many others.", \t\t\t"author": "Tom Tanner", \t\t\t"homepage": "https://github.com/thosrtanner/notepad-pp-linter" \t\t\t},

So I thought i could do my updater in python, just load up the json file, modify my entry, and dump it back, then commit

One entry (just one) uses spaces instead of tabs.

So my question is is there an official layout for these files? Is any valid json permissible (all on one line for instance), or is it expected to be formatted as 1 line per key and indented with tabs?

Would converting those spaces to tabs as part of my PR be frowned upon, or should I just read the file and modify the lines appropriately?

@PeterJones said in Is There a Way to Prevent Pasted Text from Spreading Out with Rows of Spaces?:

Or, since you said,

there aren’t any unused ones available under Plugins > Customize Toolbar

- I assume this is the one where you say, "there aren't any unused ones available". I cannot imagine that you've _actually_ enabled another couple-dozen buttons from its list, so that there are no other "available toolbar buttons", as that toolbar would be so full as to be unusable. On the other hand, that's the only thing I imagine that you _could_ mean by such a sentence.

Yes, all of the Old Large Legacy Icons are in the Current toolbar buttons box. After checking them, I decided that I might use all of them in the future.

Well, with all of that said, thanks for being patient and hanging in there through all of this. I have everything working, including adding a new icon to the toolbar. And thanks for the updated scripts.

I hope this thread serves many others.

@Deepa-Asthana
Before anyone can offer some ideas you will need to expand your description of the problem.

Like how many tabs open. How big are some of the files/tabs. What are your backup settings. It seems that your problem has existed before the latest update, correct? Provide the details of your installation using the ? menu option, copy and paste here. There is a FAQ post to help you. Sorry writing on phone so can’t easily provide the link.

Terry

@rdipardo ,
Thanks for pointing out the Native AOT template — I wasn’t aware of it when I started the ARM64 migration.

I did actually try Native AOT early on, but ran into two issues: the export limitations you mentioned, and the resulting DLL size (~57 MB), which felt way too large for a Notepad++ plugin. That’s why I ended up going with DNNE — the plugin DLL stays small (~1 MB), though it comes with the .NET 8 runtime dependency.

How large are the DLLs you’re getting with the Native AOT template? Has trimming improved enough to bring the size down to something reasonable for a plugin?

@Carlos-Sánchez said in [New plugin] Smart Math:

I’m a bit lazy and haven’t got a clue

I can’t solve the first part, but for the clue:

it’s just a PR to the nppPluginList project. Since you’re working in GitHub already, I assume you know how to do the PR fork the nppPluginList repo, create your own branch in that branch, edit pl.x64.json to link to the 64-bit version, and pl.x86.json to link to the 32-bit version the id required in the JSON is just the SHA256 hash, which GitHub provides for you:
fd4a838f-9724-477d-b755-24836141dc88-image.png once you have edited both files in your branch, submit the PR from that branch

@Murray-Sobol-1 said in Idea of a new installation routine:

@PeterJones said in Idea of a new installation routine:

No one should ever download a 32bit installer for modern OS. For any app. (Modern OS don’t come in 32-bit versions anymore, so I don’t understand why apps still bother distributing the 32-bit versions)

I agree with the above statement, however when I ask for an update by clicking Downloads I see this section:
Download 32-bit x86
Installer | GPG Signature
Portable (zip) | GPG Signature
Portable (7z) | GPG Signature
Mini-portable (7z) | GPG Signature

Why is this even being distributed anymore??

Because my statement was just my opinion, and not everyone agrees with it. Because there are some people who mistakenly think they need a 32-bit even though they have a 64-bit OS. And there are some people who have some unmaintained plugin that only comes in 32-bit (*). And because the developer has never decided to cut off those poor, unfortunate souls.

(*: aside: anytime I come across someone like that, I do a bit of research to help them find an alternative, or find someone who has done an unofficial recompile of the plugin for 64-bit. there are very few public plugins that have no 64-bit version and no alternative)

But that’s why we lobbied to put the 32-bit below the 64-bit, so the 64-bit gets the prominence it deserves – and why I rejoiced when it happened. Someone downloading N++ for the first time will see the 64-bit first, and will likely download that. Someone updating N++ should use the menu or auto-update, and never have to go back to the website.

Hi, @b, @peterjones, @coises and All,

Let’s consider the Spanish word comparación and its various forms below, pasted in a new tab :

comparación cömparÅciõn ＣömꝕarÅcⓘoñ ȻOℳₚA⒭ⱯℭᴵꝊᵰ ƆºᶆⱷǞℝȺꜿᵼᴓɲ ɕƢꟽⓟǻꝝⱭƆⅈᴗN

Note that I have deliberately exaggerated the shapes and modified the case of the possible characters !!

If you do any of the six N++ searches, below, against the six lines in the new tab, you’ll see that ONLY the two first regexes, which refer to standard equivalence clases, can find all the lines.

SEARCH (?=[[=c=]])\X(?=[[=o=]])\X(?=[[=m=]])\X(?=[[=p=]])\X(?=[[=a=]])\X(?=[[=r=]])\X(?=[[=a=]])\X(?=[[=c=]])\X(?=[[=i=]])\X(?=[[=ó=]])\X(?=[[=n=]])\X

SEARCH (?=[[=c=]])\X(?=[[=o=]])\X(?=[[=m=]])\X(?=[[=p=]])\X(?=[[=a=]])\X(?=[[=r=]])\X(?=[[=Å=]])\X(?=[[=c=]])\X(?=[[=i=]])\X(?=[[=õ=]])\X(?=[[=n=]])\X

SEARCH (?=[[=Ｃ=]])\X(?=[[=ö=]])\X(?=[[=m=]])\X(?=[[=ꝕ=]])\X(?=[[=a=]])\X(?=[[=r=]])\X(?=[[=A=]])\X(?=[[=c=]])\X(?=[[=ⓘ=]])\X(?=[[=o=]])\X(?=[[=ñ=]])\X

SEARCH (?=[[=Ȼ=]])\X(?=[[=O=]])\X(?=[[=ℳ=]])\X(?=[[=ₚ=]])\X(?=[[=A=]])\X(?=[[=⒭=]])\X(?=[[=Ɐ=]])\X(?=[[=ℭ=]])\X(?=[[=ᴵ=]])\X(?=[[=Ꝋ=]])\X(?=[[=ᵰ=]])\X

SEARCH (?=[[=Ɔ=]])\X(?=[[=º=]])\X(?=[[=ᶆ=]])\X(?=[[=ⱷ=]])\X(?=[[=Ǟ=]])\X(?=[[=ℝ=]])\X(?=[[=Ⱥ=]])\X(?=[[=ꜿ=]])\X(?=[[=ᵼ=]])\X(?=[[=ᴓ=]])\X(?=[[=ɲ=]])\X

SEARCH (?=[[=ɕ=]])\X(?=[[=Ƣ=]])\X(?=[[=ꟽ=]])\X(?=[[=ⓟ=]])\X(?=[[=ǻ=]])\X(?=[[=ꝝ=]])\X(?=[[=Ɑ=]])\X(?=[[=Ɔ=]])\X(?=[[=ⅈ=]])\X(?=[[=ᴗ=]])\X(?=[[=N=]])\X

In constrast to the last release of the Columns++ plugin, independant of Scintilla and doing true UTF-32 searches, which is able to match the six lines of our example, whatever the regex used among the six regexes above !

This example clearly demonstrates that it’s possible to perform a search without considering case and/or accentuated characters with the v1.3.1 release of Columns++ plugin ;-))

Best Regards,

guy038

@KelltimeOG
Fixed in https://github.com/notepad-plus-plus/wingup/commit/5d89e486a5cb63251b8ed0b0e9f441a9774709ff
The fix will be in WinGUp v5.4.1, which is included in Notepad++ 8.9.3 release.

@Evelyn-Walker ,

I tested the behavior you described. In Notepad++ the Ctrl+L (Delete Line) command

That is wrong terminology, as already described above. Ctrl+L is Line Cut, not Line Delete. To use the wrong terms causes confusion for everyone. From the OP, it was acceptible, because they didn’t know better. But to post like you are an authority, but to use the incorrect terminology, is detrimental to yourself and anyone who reads the answers here.

internally performs a cut-like operation,

Of course it does. It’s literally Line Cut, so it definitionally affects the clipboard

which means the deleted line is temporarily placed into the clipboard.

It’s no more “temporarily” on the clipboard than any Ctrl+C or Ctrl+X is “temporarily” in the clipboard. It’s in the clipboard until something else replaces it, just like every other clipboard action.

Use Ctrl+Shift+L (if configured) or another plugin/command that deletes the line without copying it.

Did you come up with that alternative all on your own, or did you just reiterate what @guy038 and I had already said?

Alternatively, copy the text again after performing line deletions if you still need it in the clipboard.

That’s horrible advice.

If preserving clipboard content during line deletion is important, it could be considered as a feature request rather than a bug.

No it couldn’t, because the feature already exists. Line Delete already exists as Ctrl+Shift+L: use Line Delete if you don’t want to affect the clipboard, and Line Cut if you do want to affect the clipboard.

@Evelyn-Walker , make sure you are not using LLM or GPT or any other AI to write your posts for you: that’s expressly forbidden in this forum.

Hi Harmandeep,

Welcome to the community.

Yes, there is a good chance you may still be able to recover your unsaved work. Notepad++ has a built-in backup and session snapshot feature that often restores files after a crash.

First, try reopening Notepad++. If the session snapshot feature was enabled, the file may reopen automatically with the content you were working on before the crash.

You can also check the backup folder manually. Go to:
C:\Users\YourUsername\AppData\Roaming\Notepad++\backup
Sometimes Notepad++ stores temporary backup files there, which may contain the unsaved content.

To reduce the risk of losing data in the future, it’s a good idea to enable a few settings:

Open Settings → Preferences → Backup. Enable Session snapshot and periodic backup. Choose Remember current session for next launch. Set a backup interval such as every 7 or 10 seconds.

With these options enabled, Notepad++ will automatically save temporary snapshots of your work and restore them if the program closes unexpectedly.

Hopefully your file is still in the backup folder. Let us know if you need help locating it.

Regards.

@P-A hasn’t come back since my reply. But I had a few minutes to experiment.

Using the published v8.9.2, I could replicate the problem:

Open fresh v8.9.2 Language > User Defined Language > Define your language… Folding in code 2 style: open = openfold, close = closefold Save as… = SomethingNew open disappears, but close remains Exit and restart Notepad++ Language > User Defined Language > Define your language…, choose UserLanguage: SomethingNew Folding in code 2 style> open still missing, but close remains Add again open = openfold, and close the UDL dialog: it appears to be there, but repeating 6/7 will show back in condition 8 at this point.

But, when I try the same sequence with the bugfix version from PR#17522, it works as expected (openfold doesn’t go missing at all).

That PR will be part of v8.9.3 Release Candidate, expected Mar 14. So it looks to me like the bug has already been fixed.

@Alan-Kilborn

I understand, but unfortunately, to have it hosted on the App Store, Apple charges £80 a year for the developer license, so I need to cover this cost, hence the 99p price.

@Vitalii-Dovgan
Thanks for the feedback!
v1.1 is now out with full Unicode compliance - all Win32 API calls migrated to W variants.
Also added separate color settings for dark and light themes.

GitHub

Hi, @kjell-rilbe, @peterjones, @Coises and All,

In my previous post, I said :

I did not need to use the atomic forms *+

I did additional tests and there a difference of execution time between the two solutions : greedy quantifiers vs atomic quantifiers

If I use the same test file , containing 524,288 correct lines, so with 0 match :

line 1 : one;two;three;four;five;six;seven;eight;nine;ten;eleven;twelve;end line 524288 : one;two;three;four;five;six;seven;eight;nine;ten;eleven;twelve;end

The regex ^[^;\r\n]*(?:;[^;\r\n]*){12}$(*SKIP)(*F)|^.+$ displays the message Mark: 0 matches in entire file after between 1.65s and 1.71s

The regex ^[^;\r\n]*+(?:;[^;\r\n]*+){12}+$(*SKIP)(*F)|^.+ displays the message Mark: 0 matches in entire file after between 1.45s and 1.51s

Now, if I add the six incorrect lines below, at the very end of the test file :

line 524289 : one;two;three;four;five;six;seven;eight;nine;ten;eleven;end line 524290 : one;two;three;four;five;six;seven;eight;nine;ten;eleven;twelve;thirteen;end line 524291 : one;two;three;four;five;six;seven;eight;nine;ten;end line 524292 : one;two;three;four;five;six;seven;eight;nine;ten;eleven;twelve;thirteen;fourteen;end line 524293 : one line 524294 : ;two line 524295 :

The regex ^[^;\r\n]*(?:;[^;\r\n]*){12}$(*SKIP)(*F)|^.+$ displays the message : Mark: 6 matches in entire file after between 1.58s and 1.65s

The regex ^[^;\r\n]*+(?:;[^;\r\n]*+){12}+$(*SKIP)(*F)|^.+ displays the message Mark: 6 matches in entire file after between 1.45s and 1.51s

Remark that, if the Match case option is not checked, the execution time increases significantly ( between 6.1s and 6.2s ) :-((

I repeated each test many times to obtain average values !

Best Regards,

guy038

Of course, the . matches new line option is not cheched and the Wrap around option is checked