@Freon-Sandoz said in Unexpected match when searching files for an end-quote character (non-ASCII):

I can reproduce the file contents and the unexpected behavior

I was able to do that, too… and now I see what is happening. The character you are calling an end quote is not the Right Double Quotation Mark, U+201D but the Double Prime, U+2033.

Windows-1252 (and Windows-1254) contains the right double quotation mark at 0x94. However, it does not contain the double prime. The entry boxes on the file dialog are always in Unicode. (That’s how it works pretty much everywhere in modern Windows.) But if the file is in ANSI, the file search is done in ANSI, so Notepad++ asks Windows to translate the string you gave it into ANSI. Seeing that there is no double prime character in your current code page, Windows “helpfully” translates it to something that looks a lot like it… the ASCII double quote.

Further confusing the issue is that Notepad++ never loads a file in any code page other than your system code page (which you said is 1252) or Unicode. So when you open the file in Windows-1254, Notepad++ is actually converting it from 1254 to UTF-8 and editing that way. That’s why the search behaved as expected in 1254: it wasn’t really 1254 in, it was in UTF-8.

Bottom line… this behavior actually is “expected”… but not by any normal human being. About the only thing you can do about it is to work in Unicode wherever possible when you are using non-ASCII characters.

It might be possible for Notepad++ to change its search so that it warned you when you tried to search an ANSI document for characters that aren’t possible in that document. I haven’t looked into it in depth; I would guess there must be a call to WideCharToMultiByte somewhere, and it could be passed the WC_NO_BEST_FIT_CHARS flag and the lpUsedDefaultChar output pointer to detect such shenanigans so the program could tell the user about it instead of potentially claiming to find something that isn’t there.

@donho ,

Thanks for doing that. It’s good to be able to grab older versions, for historical purposes / comparisons, and for people who are trying to use Notepad++ on machines that still have ancient OS installed and cannot be upgraded (like a bunch of early 2000s electronic-measurement equipment that I used to use)

FYI:
I just updated RC4 binaries with the fix:
https://github.com/notepad-plus-plus/notepad-plus-plus/commit/9b558895e744601842ffdaff4679467863b9722d

Sorry for the inconvenience.

Yes—Notepad++ doesn’t automatically strip HTML, but copying through plain-text mode (like Notepad or Reader View) removes all tags. To retain <p> and <br>, avoid pasting via plain text—either paste directly into Blogger’s HTML view and clean unwanted code manually, or use an HTML cleaner tool to keep only specific tags instead of stripping everything.

@Claudia-Frank

Some seven years later: exactly my query too. Many thanks. 😊😊

JsonTools v8.5 is now available on the plugin manager for Notepad++ 8.9.3. The main change is that ANSI-encoded documents containing non-ASCII characters can now be parsed correctly.

Update: @Ertan-Küçükoglu didn’t post the link here, but had made https://github.com/ScintillaOrg/lexilla/issues/321 to request this feature from Lexilla. Lexilla just merged a PR to add SCE_PAS_MULTILINESTRING styleID=15. Since Lexilla v5.4.8 was just released last week, it’s likely going to be a few weeks to a couple months before v5.4.9 is released to include that feature. But once it is, and once Notepad++ imports the updated Lexilla, then that new style can be added to the Pascal/Delphi definitions in stylers/themes. So hopefully, this will be added to Notepad++ within the next few months.

(Keep an eye on Notepad++'s Issue #16807 to see when it gets added to the codebase; whatever release happens after that Issue is closed will be the first Notepad++ release to incude the multi-line string highlighting.)

@PeterJones Hi, I managed to complete your code so that all color formats work. If you want, I can send you the code.!Sem títulddddo.jpg

see update in this announcement: new github repo with archived versions of Notepad++ at https://github.com/notepad-plus-plus/old-releases

@Mark-Olson You are right, thanx Mark.

@Robk-Blue said in Tidy2 or other HTM L plugins:

It looks like Tidy2 is a 32 bit plugin and I can’t find a x64 version. Is it able to be used still? Any other options?

Yeah, Tidy2 hasn’t been updated in more than a decade – it’s essentially abandoned. And as far as I can tell, no one here has grabbed the source code, recompiled for 64-bit, and published it anywhere (that has happened on some other plugins that used to be only 32-bit, if someone here was interested enough in that plugin to do it for themselves and share it with others)

XML Tools is able to make XML look pretty, and usually works on HTML files as well.

Other than that, it’s possible to pass the current file to your favorite external command-line code-prettifier (tidy.exe, if you installed HTML Tidy utility on your computer yourself), using either the Run > Run to create a User-defined command, or using a plugin like Pork2Sausage or NppExec.

See also the FAQ: How do I use Notepad++ to Compile my Source Code (or Convert My Text)?, which has a section on Converting text (which is what things like tidy.exe are doing), and explains how to use the plugins mentioned in the previous paragraph to accomplish conversion tasks.