• Sorry, it should be 2.5GB.

  • I code 100% in UTF-8

  • @Scott-Sumner

    Thank you so much! I actually already have an AutoHotKey script running all the time, but I had never used it for scripting, I just had some simple key remappings. It never occurred to me to solve this via a script. Looking at your code, I wrote the following for AutoHotKey:

    #If WinActive("ahk_exe notepad++.exe") ^f:: if WinExist("Find") if WinActive("Find") WinActivate, ahk_class Notepad++ else WinActivate, Find else if WinExist("Replace") ControlClick x35 y35, Replace ; click on "Find" else SendInput, ^f return ^h:: if WinExist("Replace") if WinActive("Replace") WinActivate, ahk_class Notepad++ else WinActivate, Replace else if WinExist("Find") ControlClick x70 y35, Find ; click on "Replace" else SendInput, ^h return #If

    It works great, exactly like I want. It solved my problem; plus it enables me to toggle focus between text and search dialog successively each time I press Ctrl+F or Ctrl+H; plus I can switch between Search and Replace with shortcuts when the dialog is active, something I couldn’t do before. It could be extended to include the “Find in Files” and “Mark” cases, if desired.

    I hadn’t heard of AutoIt before. Apparently AutoHotKey forked from it. I guess I should look into it as well to see which is better if I do serious scripting in the future; AutoHotKey was good enough for the simple things I needed so far.

    @AdrianHHH

    That happened to me as well! I think when you are typing your own string, up arrow should do nothing, and if you press down arrow by mistake, up arrow should bring back the text you were writing. Unfortunately it is not possible to implement that behavior via a script, Notepad++ must do that; but it is certainly possible to disable up and down arrows completely while in the search window via AutoHotkey (or presumably AutoIt) if you never need them. (Or one could make the up and down arrows do nothing, and Ctrl+up and down act like the arrow buttons for the times you actually need them.) I don’t know if it is worth installing AutoHotkey or AutoIt over, if you are not otherwise using them though; but I will consider adding such a line to my script.

  • another set indicator jumps in.

    Probably the xml tag highlighting.

  • Hello, Manorma Gautam,

    Not very difficult !

    From what you said, I deduced some points :

    You want to keep the lines, which contain, either, the string vprn OR vpls

    These two words begin by the two lowercase letters vp

    These two words are always located at beginning of lines

    All the lines, which do not contain these two words, must be deleted

    So, follow the few steps, below :

    Move back to the very beginning of your file ( Ctrl + Origin )

    Open the Replace dialog (Ctrl + H )

    In the Find what zone, type in (?-is)^(?!vp).+\R

    Leave the Repalce with zone EMPTY

    Uncheck, preferably, the Wrap around option

    Select the Regular expression search mode

    Click on the Replace All button

    Et voilà !

    NOTES :

    The first part of the regex are in-line modifiers (?-is) to force the regex engine to consider the search :

    In a non-insensitive way ( in the case you, previously, unchecked the March case option

    With the dot symbol matching standard characters, exclusively, in the case you, previously, checked the . matches newline** option

    The middle part ^(?!vp) looks, from beginning of each line, for a negative look-ahead ( a condition that must be true in order to satisfy the overall match but which is not part of the final regex. So, it verifies, for each line, if the exact string vp does NOT occur, at beginning of lines. If it’s the case :

    The last part, of this regex, .+\R matches any non-null range of standard characters, from beginning of line, followed by any kind of EOL characters. That is to say any complete line, which does NOT begin with vp

    All these complete lines are, of course, deleted, as the replacement part has been left EMPTY

    REMARK : The important thing, to note, is that look-arounds ( look-behinds and look-aheads ) do NOT move the regex engine position of search. So, after evaluating the negative look-ahead (?!vp) , the regex engine position is, still, just before the first character of each line ! Therefore, the part .+ does match all the standard characters of each line !

    Best Regards,

    guy038

  • Thanks, cmeriaux. I will try downgrading to version 7.1 when I am next in the office.

  • Hello, 古旮,

    To begin with, as this post is quite long, just have a drink ! , …and let’s go :

    Ah yes, I just realized that, if we use my long example line :

    12345 word 99099 spring, off-spring, of,....................................., spring, of, ring, off-spring, off, 99099

    Then, after hitting many times on the Replace button, I almost got the expected result : only the word spring, right after the tabulation character, should have been deleted. So, after moving the caret, some lines before, and performing this S/R again, it was OK !

    By the way, as before the \K syntax, there’s, only one tabulation character ( case of fixed length string ! ), my previous regex may, also, be written :

    SEARCH (?-s)((?<=\t)|, )(.+?)(?=, (?:.+, )?\2(, |\R))|(?<=\t),[ ]

    REPLACE Let EMPTY

    Like you, I think that it’s a bit weird that it can select the right match but cannot delete that selection !?? Unfortunately, sometimes when hitting the Replace button, it’s even worse as it may forget some matches or select wrong matches !
    It’s quite difficult to tell you, in what exact cases, this behaviour occurs. But I noticed it when the last character, of the look-behind and the first character, of the main regex, refer to the same set of characters !

    So, to my mind, we do need to improve the present regular S/R regex engine, by using the François-R Boyer version. Of course, when the Boost regex library, similar to PCRE (Perl Compatible Regular Expressions ), was implemented in N++, on March 2012, some improvements, between the N++ version 6.0 and version 6.4.2, were done and some bugs were fixed by, both, Dave BrotherStone and François-R Boyer ( as the Zero length match call-tip message,… )

    However, although the non-official François's version, simply, relies on the BOOST library, he was able to fix major issues, relative to look-behinds and backward assertions, and succeeded to manage all UNICODE characters, as well as NUL characters, in replacement !

    Here are, below, a non exhaustive list of issues with the current regex engine,_ which do not occur, with 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. On the opposite, if SEARCH = (?<=a)ba*, we obtain 4 matches, but, it misses the string ba, at positions 10 and 11 :-(( With the improved version of François-R Boyer, 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 does 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 !

    Remark :

    Of course, for that specific S/R, you need a font, that can display the Osmanya characters, and which is affected as the default style font, in the Style Configurator… dialogue ! To that purpose, download the Andagii font at :

    http://www.i18nguy.com/unicode/unicode-font.html

    and have a look to Osmanya characters at :

    http://www.unicode.org/charts/PDF/U10480.pdf

    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 !

    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 !

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

    Search is performed in true 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{007F}

    Of course, the LOCALE order and ERROR messages new features will NOT be accessible, still, in current Notepad++ user interface !

    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, download, first, the .zip or .7z archive of Notepad++ v6.9.0, from the link, below :

    https://notepad-plus-plus.org/download/v6.9.html

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

    Inside this new folder, rename The SciLexer.dll file as, for instance, SciLexer.xxx

    Then, to get this Beta N++ regex code ( that has 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.xxx files

    Download, too, the readme.txt file

    Enjoy it !

    REMARK :

    Remember that this modified SciLexer.dll, build on May 2013, is based on Scintilla v2.2.7 !

    Of course, I long for, ( since more than 3 years ! ), that this 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 François-R Boyer's code and, as my C++ skills are, unfortunately, rather, near 0, you and me, just, have to content ourselves with using the present bugged N++ regex code :-((

    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 gsee the correct search behaviour of some regexes or to perform, from time to time, special replacements ;-)

    Best Regards,

    guy038

    P.S. :

    You may verify, that using the François-R Boyer's version, with the second formulation, of my regex, below ( without the \K syntax ) :

    SEARCH (?-s)((?<=\t)|, )(.+?)(?=, (?:.+, )?\2(, |\R))|(?<=\t),[ ]

    REPLACE Let EMPTY

    The replacement-suppression of all the duplicate words, after the tabulation character, as well as any string comma + space, located after the tabulation, are quite effective :-))

    Unfortunately, if your regex contains the \K syntax, it will NOT be good, even with the François-R Boyer's version :-((

  • there will be another good solution, that works:

    Find What: ^(\w+\s+\w+\s*)(.*)\n\1
    Replace With: \1\2,

  • So after digging into this, a solution did materialize. I’ll share it in case someone else may need it some day…

    The message NPPM_GETLANGUAGENAME can be sent to Npp to request the language name string for a value of the LangType enumeration. This enumeration ends with the value L_EXTERNAL which corresponds to the first external lexer. By iterating from L_EXTERNAL to the limit of external lexers (+15), the (non-localized) name of each external lexer is retrieved and compared to the desired lexer’s name - on finding a match the LangType (or langId) is known. If the supplied LangType value exceeds the range of defined lexers, the string “Normal text” is returned as the language name.

    NPPM_GETLANGUAGENAME was added to Npp in version 5.9.3

  • Quote from the Notepad++ website:

    Note that the most of plugins (including Plugin Manager) are not yet available in x64

  • The Line Warp option fixed the problem for me, thanks for the help!

  • Fair enough. However I’ve resolved it. Somewhere’s in the last few versions an option has been added to set files to Read only. I’ve never used this option before but yet during the update to 7.2.2 one of the files I use often had the flag set to read-only. That’s why my macro replacement program never worked. Once I cleared the flag my macro replacements are working fine again.

    Thanks for the reply.

  • Do you mean how to change Window’s PATH variable from pointing to Python27 to Python35? That’s a Windows question, not a Notepad++ question, and one that your original post implied you knew how to do. And 30seconds on your favorite search engine will tell you: search for “change path WindowsN” (where N is 7, 8, or 10, as appropriate for your machine).

    If you mean how to change the path in the command snippet I showed, instead of typing c:\path\to\python3.exe, you would type the actual path to your installation of python3. I cannot know where that is on your computer (though c:\python35\python.exe is my first guess)

    If you mean something else, you’ll have to be more explicit. Because, once again, you haven’t said how you previously ran python27 from NPP, and other than a copy/paste of my text, haven’t shown what you’ve tried to get python35 to work.

Internal error.

Oops! Looks like something went wrong!