Hi,
I would like to test your plugin but, unfortunately, I run windows arm-64 and this plugin only runs on x86. Do you think it’s possible to release an ARM version ?
Thank you.

A very old thread I know, but this may help someone else.

I was trying to use Pretty Print to format some MSOffice XML (from a PPT template that had been renamed as a zip). My initial attempts didn’t work “Nothing happened”. I eventually solved the problem when I realised that it wouldn’t work on files still stored in the zip. Notepad++ could read the files and displayed them as 2 looooog lines so I assumed (wrongly) that I could Preetify, edit and write back. In retrospect I should have realised that this was never going to work as the “file” I was working on was a temporary copy.

Solution: Extract the file from the zip (as opposed to view the file in the zip without extracting properly) , Preetify (which worked of course), edit, save, copy back into the zip overwriting the original.

An interesting corollary: Using the Windows Explorer zip functionality to open and view the contents (as opposed to extracting them) which uses a rather long temporary folder prefix - Pretty Print didn’t work.
Using 7Zip which uses a much shorter temporary folder prefix - Pretty Print did work. Obviously, I was still working in a temporary copy which wouldn’t get saved back.

@mpheath. Thank you so much. You found a simple and very effective solution. It works 100 percent. Now I see the desired cursor instead of the black square. Thanks again.

@guy038 said in Columns++ version 1.3: All Unicode, all the time:

Note that the \p{Hex_Digit} regex is erroneous ! The right one is \p{xdigit}, at least, within Columns++

What’s going on there is that I followed the structure of Boost::regex character classes:

Character Classes that are Always Supported

Character classes that are supported by Unicode Regular Expressions

which are mainly the POSIX character classes plus Unicode General Categories interpreted as character classes. Also, note that in Boost::regex, character classes and character properties are the same thing. I didn’t make any attempt to change that. I believe this is different both from Unicode regular expressions and from PCRE.

(I did add a couple new character classes unique to Columns++: [:defined:] and [:invalid:], and aliases \i, \o and \y for [:invalid:], [:ASCII:] and [:defined:]. Also, Columns++ does not support [:Cs:]/[:Surrogate:] since Unicode in Scintilla can only be UTF-8, which cannot contain surrogates — though it can contain invalid byte sequences which appear to encode surrogates, as in WTF-8; Scintilla treats these as invalid UTF-8 bytes, and so does Columns++.)

Hex_Digit isn’t one of the Boost::regex character classes, and I never defined it. Defining it to be equivalent to xdigit would be trivial; re-defining xdigit to include non-ASCII characters is a bit more complicated:

I’ve found out a small anomaly concerning hexadecimal characters :

If I use the native Notepad++ search to match any hexadecimal character, with the regex [[:xdigit:]], against my Total_Chars.txt file, it returns 44 matches

If I use the Columns++ search to match any hexadecimal character, with the regex [[:xdigit:]], against my Total_Chars.txt file, it returns 22 matches

I suppose that the N++ answer is the right one. Indeed, in the https://www.unicode.org/reports/tr18/#Compatibility_Properties article , ( Annexe C about UNICODE REGULAR EXPRESSIONS ), it is said :

Hex_Digit contains 0-9 A-F fullwidth and halfwidth, upper and lowercase

Yes, it would seem the standard is to include those non-ASCII characters as hex digits. Further, the comments at your link under lower and upper are troublesome, as Columns++ treats them as aliases for Ll and Lu. Word and word boundaries are probably faulty as well.

I followed the Boost::regex principle that to extend the traditional POSIX mappings, the only Unicode property that is used to determine membership in a character class is the General Category.

I hard-coded (that is, they are written explicitly rather than being derived from Unicode tables) the POSIX mappings for ASCII characters, since that’s the only place they are really well-defined; plus there is a hard-coded exception for the non-ASCII character U+0085, the Next Line control character, because it should be part of \v, which is implemented in Boost::regex as [[:v:]]. I don’t see any reason [[:xdigit:]] can’t be extended with similar hard-coded logic; I just didn’t know until now that I should do it.

The other parts, though: whatever they are saying is supposed to be included in [:lower:] and [:upper:] besides letters, and whatever they are talking about in regard to word characters and boundaries… that might be problematic. I have a condensed set of tables built from a few Unicode files, instead of trying to import the ghastly large and complex ICU. Those tables include the General Category, but if that is not enough to determine membership in a character class… reorganizing them to include whatever additional information I need (it’s not yet clear to me what that will be) is not likely to be simple.

Thank you for your observation. Indeed, there are flaws. It is not yet clear to me if and how it will be practical to address them, though I can probably fix the [:xdigit:] behavior without much difficulty.