@PeterJones I got it to work. I copied the files as instructed. However, there are a few things I need to know.

Should I delete python27.dll from the PythonScript folder? This time, I copied and pasted and followed the prompt to replace the existing files. Last time, I deleted everything before copying over the extracted files. Is that why it didn’t work?

How is the script enabled? The only way I can figure out how to make the script work is via the toolbar, Plugins > PythonScript > Run Previous Script (No New Lines)

Is this the only way to enable it? Is there a way to make it automatic? Or at least, an icon on the toolbar? I tried doing that via Plugins > PythonScript > Configuration, but to no avail.

Is it possible for the script to work without first pasting the IMDB text into the Find search box?

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

@Linen-Gray said in Adblock360Updater Batch File Keeps Appearing:

but wanted to know if anyone else had experienced this happening and if so how they took care of it.

Well if you are certain your system isn’t infected then that is a step in the right direction. Just understand that according to the bat file’s contents the “malware” had been apparently residing in the location referenced in almost every line. I would still take a look at that location to be absolutely sure it is gone.

I am re-reading your initial post and trying to understand what is occurring. You say this “bat” file is opening regularly. What is the app that is opening this file? If it is Notepad++ (the “bat” file shows within a Notepad++ tab), then try to identify the location of that file. It should show the location if you move the mouse pointer over the tab’s title line. Then open that location to have a better look around, you should be able to right click on the tab’s title line and select Open into… and select the Explorer line. Once you are happy that you can delete the file, just close it in Notepad++ and then remove it from the location.

So in terms of the question has any one else experienced this issue, the answer is no, no one else has mentioned this on this forum. You could easily do a forum search on the string “adblock” but you won’t find this specific one, just mentions of “real” adblock apps.

Terry

@Coises said in Regex matching anomaly:

If the line endings in the file aren’t consistent, it could mismatch.

Huh. Right you are. Ironically, that possibility had actually occurred to me, and I even thought I’d checked for it adequately by enabling View > Show Symbol > Show EOL, but apparently I failed to pick the single LF out of all the CRLF. Thanks.

Just 6 votes… Not many.

Anyway, I’m continuing to improve the HTML version of the Manual, this time with close help of Gemini.
I still don’t understand the HTML/JS/CSS things good enough, but with the trials and re-trials guided by the AI, I think I’ve already achieved such level of flexibility and complexity that rdipardo and Joseph Samuel (who originally significantly helped with bringing the Manual online) may be proud of the result :)
I seemed to achieve the same behavior between the offline (local) and online (web) version of the HTML Manual today, so you may try it.
The most important changes have been made around the “Search Topics” logic:

Now the search results (left frame) and the document content (right frame) both listen to the ‘mouseenter’ event. Once this event happens, the corresponding frame becomes focused, allowing e.g. scrolling by the arrow keys. While working with the search results list (such as changing the selected item via the mouse or the keyboard), the focus remains in the results list, thus allowing to navigate through different documents. Pressing Enter or double-clicking the search results list brings the focus to the document content (right frame). The search results list can be closed by Esc. The http and https links in the documents are blocked for the CHM version of the manual and allowed otherwise.

@PeterJones said in File type associations not working:

it’s at the mercy of the OS as to whether the OS will propagate such settings to the user, or completely bypass them

It worked reasonably for me. I ran my installed Notepad++ v8.9.1 As Administrator, then went to the File Association setting, picked customize, typed .pcj (which is a file extension that didn’t have any associated app or filetype), then clicked -> to move it to the Registered extensions column. If I then exit Notepad++ (to get out of Admin mode), and double-click on blah.pcj in Windows Explorer, it opened it in Notepad++. (And looking at the registry, I can confirm it added HKCR\.pcj to point to Notepad++_file, and HKCR\Notepad++_file sets the shell\open\command as expected. (But maybe you didn’t think it “worked” at this point, because it doesn’t necessarily change the text of the “file type” column in Explorer. Even if it doesn’t, the double-click did what I expected.)

When I tried with the preferences dialog misc > .nfo, it edited the existing HJCR\.nfo to point to Notepad++_file (with a Notepad++_backup entry pointing to the original MSInfoFile. When i double-click on an NFO file, Windows actually pops up a Select an App to open this .nfo file, which includes the “Notepad++ (New)” entry (because Windows has been trained to not fully allow applications to hijack extensions, because users hate it when an app does that without their permission) – and from there, you can choose whether you really want to.

But by doing it through the Windows OS Open With interface to begin with, you make sure Windows knows it’s you who wants the change, not the app, and so lets you do it more easily there.

IOW: it works for me on Windows 11 as Notepad++ tries it, with the caveats that Windows 11 is trying to protect me from nefarious apps, so might require a confirmation; and when I do things the way Windows OS wants, it works as expected rather than having to do the extra steps.

@Pawan-Sharma
If I had to guess, two words: race conditions (and an opposite-ish problem, deadlocks).
Iteratively updating the results while searching seems like a great way to introduce endless difficult-to-reproduce bugs.

@PeterJones sure.

You can use sites that can transform text, simply put you text and then transform it and place in your sentence, that is how you have two types of fonts