@Coises I didn’t experiment with adding or subtracting any plugins (other than having already added Search++) in the portable version yet. but I did just open the portable again, this time via command line and -multiInst, per @Alan-Kilborn’s suggestion (thanks, Alan), while my installed version was already open. I then retried my regex, but this time got anomalous results, such as: this u’dos I am that this ’Round and ’round that I then undid all replacements, and redid them, with all results correct the second time around. Quit the portable copy, then reopened it (as -multiInst) again, then redid the regex, with anomalies: this ’Cos I am that this ’Round and-’-ound that Quit the portable copy again, then reopened it (as -multiInst) again, then redid the regex again, with slightly different anomalies: this ’Cos I am that this -’-ound and ’round that Talk about bizarre. But it seems we can rule out conflicts from the other plugins I use in my installed version, unless there’s some way for them (or something else) to cross-contaminate the process in active memory due to the installed version still being open. […shuts down both portable and installed versions; reopens portable version; retries regex…] Nope. Still had anomalous results: this ’Cos I am that this -’-ound and ’round that I’m out of guesses. It’s hit or miss whether or where or how it happens.

v0.0.1.2-dev Add the "eolFilled": "1" attribute to the JSON (expected values: not supplied, "","0","1"). This will allow lexers that support the SCI_STYLESETEOLFILLED style to fill the styling to the end of the window instead of the end of the text. [image: 1786029765137-e40ab72a-6d2e-40b0-978d-e0fe127a46b2-image.jpeg] "6 SCE_MARKDOWN_HEADER1" : { "fgColor": "FFFFFF", "bgColor": "8F8F8F", "fontStyle": "1", "eolFilled": "1" }, "7 SCE_MARKDOWN_HEADER2" : { "fgColor": "CCffff", "bgColor": "7F7F7F", "fontStyle": "1", "eolFilled": "1" }, "8 SCE_MARKDOWN_HEADER3" : { "fgColor": "CCbbbb", "bgColor": "6F6F6F", "fontStyle": "1", "eolFilled": "1" }, "9 SCE_MARKDOWN_HEADER4" : { "fgColor": "CC7777", "bgColor": "5F5F5F", "fontStyle": "1", "eolFilled": "1" }, "10 SCE_MARKDOWN_HEADER5" : { "fgColor": "CC3333", "bgColor": "4F4F4F", "fontStyle": "1", "eolFilled": "1" }, "11 SCE_MARKDOWN_HEADER6" : { "fgColor": "CC0000", "bgColor": "474747", "fontStyle": "1", "eolFilled": "1" },

@Afik-Gilboa said: in windows 11, the plugin reset itself every time i open npp Could you be a little more specific? For one, add your ?-menu’s Debug Info, which will tell us exactly which version of Notepad++ and which version of NppFTP you are using. For another, what do you mean by “reset itself”? Does that mean that all the settings go away? Or that just your profiles go away but not your other settings? Or does that mean the panel positions reset? Or something else happens? I have been running NppFTP (0.29.15) on recent Notepad++ versions on Windows 11 for over a year, and it’s never “reset itself” in any way that I would consider a reset. So without more information, “I cannot replicate.”

@Coises said: Notepad++ won’t let the selection that results from a search split a CRLF line ending. As you can see, it moves the start of the selection from the actual location of the match to after the line ending. I noticed that in a Lua script recently that the Scintilla positionAfter function treats CRLF as a single UTF-8 character. So the CRLF has become what some may call an unbreakable sequence in some situations.