• @guy038 Thank you. Merry Xmas & Happy new year to you Guy! And to Notepad++ Community!!

  • Hello, @per-isakson,

    My first attempt, with the initial-key words if, for, while, switch, try, parfor and the final-key word end, all in lower-case, would be the regex, below :


    Just try it against the sample text :

    if while end end forend ( Test : normally NOT matched ) if end end for if end while for if end end end for if end end end end end for if end while for if end end end for if end end end end end end end for if end while for if end end end for if end end end end end end

    You should obtain five occurrences, capturing 2 single-line zones and 3 multi-lines blocks

    Of course, as this regex just search for the exact words, without word boundaries, it wouldn’t mind, for instance, about the wrong block, below, selecting from the letters for to the letters end

    afor .... .... .... endz

    I tried to build a more complete regex, with word boundaries, as \W, and the look-arounds (?<=\W) and (?=\W), but my solutions led to other problems and didn’t match all the cases, anyway ! Then, I realized that it would be better, finally, to detect, FIRST, in your code, any key-word, used in that regex, when “glued” to other letters, in a bigger word ! To that purpose, use the regex( again ! ), below :


    IMPORTANT : Sometimes, when clicking, ONE MORE time, on the Find Next button, all the file contents are wrongly selected. It’s a well-known bug, which occurs, while using, mostly, recursive regular expressions :-(( I can’t explain that behaviour ! May be, my regex is not well-formed !?

    Best Regards,


    P.S. :

    If this regex put you on the right direction, I give you, next time, some details on what it means !!

  • Hello, @alan-kilborn,

    The problem, Alan, that you raised, is due to the fact that the present N++ Boost regex engine, does NOT handle backward assertions properly !! It’s the case, for instance, for the syntaxes \A ( or (?m)^ ), \b, \B, \< as well as some look-behinds syntaxes :-((

    Indeed, with your regex (?-m)^|\z` and the sample text, below :

    abc def ghi

    When you hit the Find Next button, repeatedly, it matches, wrongly, 12 times, the zero-length string, instead of 2 times ( at the very beginning and at the very end of the file )

    To get the right behaviour, like with the RegexBuddy software ( except for my work-around ), the ONLY way is to use the Francois-R Boyer regex code, which is a very good N++ implementation of the Boost regex library !

    If you install the improved François-R Boyer version, of the BOOST regex engine, you’ll get some strong new regex features :

    Search is performed in 32 bits code-points, so it can handle characters, over the BMP ( Basic Multilingual Plane ). An interesting feature for most Asiatic people !

    It can manage NUL characters, both, in search and in replacement, too.

    Look-behinds are correctly handled, even in case of OVERLAPPING, with the end of the previous match.

    It can handle ALL the Universal Character Names ( UCN) of the UCS Transformation Format , from \x{0} to \x{7FFFFFFF}, particularly, all those of code-points over \x{FFFF}, which are outside the BMP.

    The backward regex search isn’t stopped, on matching a character, with Unicode code-point over \x{00FF}

    The case modifiers \u, \l, \U and \L, in replacement, do change any accentuated letter !!

    Most of the time, the step by step replacement, often broken with the present version, works nice with François-R Boyer version

    Here are, below, a non exhaustive list of issues, with the CURRENT regex engine, which DO NOT occur, with the François-R Boyer's version :

    Overlapping lookbehinds and matched strings are NOT correctly handled. For instance, giving the 20 characters subject string aaaabaaababbbaabbabb and SEARCH = (?<!a)ba*, we get 6 matches, but, unfortunately, 2 results are wrong. With the improved version of François, it’s all OK !

    We can’t use the NUL character in replacement. For example, the simple S/R : SEARCH = ABC and REPLACE = DEF\x00GHI, the result is the string DEF only :-(. The François's version do insert the NUL character between the strings DEF and GHI !

    BACKWARD assertions are NOT correctly supported. E.g. : SEARCH = \A. matches, successively, all the characters of the FIRST line. With the François's version it only matches the FIRST character of the current file

    It doesn’t search and replace characters, which are outside the Basic Multilingual Plane (BMP ). For instance, in an full UTF-8 file ( with a BOM ), if SEARCH = \x{104A5}\x{20AC} and REPLACE = \x{A3}\x{10482}, The present regex engine answers Invalid regular expression ! as for the François's version does the replacement correctly ! ( Of course, your text font must handle these “Over BMP” characters )

    Now, let’s suppose, for instance, the French subject string Un évènement, on a new line, and the simple SEARCH regex \w. After a click on the Find Next button, close the Replace dialog, and keep on searching some word characters, by hitting the F3 key. When you’re, about, at the end of the string, just go searching backwards, by hitting the SHIFT + F3 key. You’ll notice _that it CAN’T go backwards, past the è character !!!. The François's version does works well, in both directions !

    A last example : if you try to mark the matches of the simple SEARCH regex (?<=.)., the present regex engine marks any character, EVERY OTHER time. With the François's version, it correctly find all characters, except for the very first of each line !

    The SEARCH = (.*) and REPLACE = \U\1\E does change any lower-case letter, even accentuated, into its associated upper-case letter !

    François-R Boyer also created a new option SCFIND_REGEXP_LOCALEORDER, to get ranges of characters, in a locale order, NOT in Unicode order. For instance, the regex range [A-B], with the Match case option SET, would match all the following characters AÀÁÂÃÄÅĀĂĄǍǺẠẢẤẦẨẪẬẮẰẲẴẶǼB, in a true UTF-8 file, with a suitable font !

    To end with, the François-R Boyer's version could display the EXACT error messages, instead of the generic message Invalid regular expression. For instance, the regex (\d+ab would report the Unmatched marking parenthesis error message !

    VERY IMPORTANT : The Beta N++ regex code, of François-R Boyer DO NOT work, will all versions of N++, AFTER the 6.9.0 version ! So, just follow the few steps, below :

    Download, first, the .zip archive of Notepad++ v6.9.0, from the link, below :


    Extract all the contents, of this archive, in any folder, in order to get a local N++ installation :-))

    Inside this new folder, rename the SciLexer.dll file as, for instance, SciLexer.690

    Then, to get this Beta N++ regex code ( that has, BTW, NEVER been part of ANY official N++ release ) :

    Download, from the link below, the modified SciLexer.dll file. of François-R Boyer

    http://sourceforge.net/projects/npppythonplugsq/files/Beta N%2B%2B regex code/

    Copy this file, in the installation folder, along with the Notepad++.exe and the SciLexer.690 files

    Download, too, the readme.txt file, for the infos

    Restart Notepad++ and enjoy it !

    Remark :

    Remember that this modified SciLexer.dll file, build on May 2013, is, also, based on the old Scintilla version v2.2.7 !

    Of course, I long for, ( since more than 3 years ! ), that this nice version would be fully integrated with, both, the latest version of N++ and Scintilla. Unfortunately, up to now, NO ONE feels interesting to implement the **new regex code and, as my C++ skills are, unfortunately, rather, near 0, I’m just trying hard to be satisfied with the present bugged N++ regex code :-((

    So, to conclude, in the meanwhile, I keep, in addition to the last N++ version, a local installation of N++ v6.9 , with the François-R Boyer modified version of SciLexer.dll, on my laptop, in order to see the correct search behaviour of most of the regexes and to perform, from time to time, special replacements ;-)

    Best Regards,


  • v1.1 has been released:

    64bit support (thanks to @chcg) Fix config file not being properly reloaded Detect when files get renamed Better error reporting

    Download (32 and 64bit): https://github.com/dail8859/ScintilluaPlusPlus/releases/tag/v1.1

  • Same problem here.
    I use DriveOnWeb instead of Dropbox, disabled all respective shell extensions, problem remained.
    I use 360 Total Security instead of Avast, disabled the anti virus program, problem remains.
    Any ideas what else might interfere with Explorer and LightExplorer plugins?

  • Ron, I just noticed a similar problem today, possibly tied to recently upgrading to Notepad++ v7.3.3, 32-bit program running on Win7 SP1 64-bit. Ctrl+Left and Ctrl+Right skipped almost whole sentences, occasionally terminating spaces but not terminating punctuation. Double-clicking on a word highlighted the same block of text–i.e. pretty much the whole sentence, much more than a single word.

    Some research showed only this thread referencing the problem, & poking around in my settings showed nothing out of the ordinary. I wondered if I’d copied & pasted weird text with special characters, but editing the text didn’t help. Even moving around & selecting text in NPP’s change.log had the same issue.

    I uninstalled Notepad++ & reinstalled & it’s fine now. During uninstall, it asked to wipe out my user settings & I said yes, in case something got corrupted in there; I’m not sure that was necessary but I knew it’d be easy enough to redo settings I changed. Hopefully this fixes it for you too.

    tl;dr uninstall & reinstall Notepad++

  • @Hardeep-Parmar

    Could it be that you run into the elevation problem?
    Meaning the hare was mapped with a different account or elevation level as npp is running?
    With complete path, do you mean unc path like \server\share\file.txt or by using the drive letter
    like z:\folder\file.txt?


  • @Aleksey–Klenin

    sounds you don’t have the latest version, do you?


  • @gstavi

    I have absolute no idea how I could miss your post.
    Checked even the notifications and still don’t see that you
    replied on the original post. Seems there is a race condition if
    two reply at nearly the same time.
    I agree to what you post.


  • @Szász-Fábián-József

    As @gstavi pointed out, the Shortcut Mapper > Macros shows the shortcut for the Macro > Trim Trailing And Save (TT&S). There’s no need to tick a setting box to change save-mode: just use the shortcut appropriate to the command you want.

    Moreover, if you want to usually use TT&S instead of a normal Save, you can do a shortcut swap (like I do): Using the Shortcut Mapper, set the TT&S shortcut to Ctrl+S, then (still in the shortcut mapper) go to Main menu > Save and change its shortcut to Alt+Shift+S (which is what TT&S was). This results in your standard Ctrl+S doing a TT&S, and the alternate shortcut (or the Save button on the toolbar) doing a standard Save (without trim).

    Good luck.

  • Hello @inu20 ,

    I assume you have tried restarting the computer, have you?
    Try removing the N++ plugins one by one and test to see if anything changes.


  • The drag-n-drop is already fixed in the next version. You can grab an updated binary with the latest not-officially-released changes from AppVeyor (x86, x64). Download the binary and put it into your notepad++ folder and launch it. Don’t download the SciLexer .dll since the certificate isn’t signed on it.

  • Use the File / Open… Menu Drag and drop the file into Notepad++ Right-Click in Explorer, Open with Notepad++ Right-Click in Explorer, Open with …

    Setting Notepad as the default Editor for *.txt files:

  • Hi, @vasile-caraus,

    Now, I realized that the regex, given in my previous post, (?i-s)(Word1).*?(Word2)|(?2).*?(?1) could be simplified !

    Indeed, as I explained, we can’t use back-references, which are not defined if the regex engine choose the second alternative ! But, when the boundaries Word1 and Word2 are not, themselves, regexes ( as, for instance \d+, a..z… ) and rather simple strings, we can use the more simple syntax below :


    Secondly, to select any entire line ( with its EOL characters ) containing the two words Word1 and Word2, whatever their order, use the regex, below :


    Best Regards,


    P.S. :

    As we’re rather dealing with exact words, we should use, instead of the two above, the regexes, below :




Internal error.

Oops! Looks like something went wrong!