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.

@Javier-Utrilla said in show the current zoom:

something like U | Zoom +10

It’s fine…but why not make the abbreviated encoding MORE descriptive, and the zoom info LESS descriptive. E.g. (just my thinking): U8B |Z+10

@Chec-Pufos ,

Your specs are more vague than you think they are.

Assuming you want to replace any positive integer immediately after that specific I:max= with 987 and any positive integer immediately after that specific I:min= with 654, then it could be done with something like:
FIND = (?-is)(Size\s+{\s*.*\R\s*I:max=)\d+(\s*.*\R\s*I:min=)\d+
REPLACE = ${1}987${2}654
SEARCH MODE = Regular Expression
REPLACE IN FILES

hopefully, you can figure out what to change in order to replace with values other than 987 or 654

highly recommended: always back up your data before trying a regex that someone hands you; always try a new regex on a single file and make sure it behaves as you expect before trying on the full 30 files.

----

Useful References Please Read Before Posting Template for Search/Replace Questions Formatting Forum Posts Notepad++ Online User Manual: Searching/Regex FAQ: Where to find other regular expressions (regex) documentation

@FreeMeow I goon to Notepad++ :P

@ViniwDOrazio

Yes, when working with multi-line matches enclosed by the same pre- and suffix, you should try to match something unique before the prefix.
If the number of lines is fixed, you could also adjust the offset configuration parameter accordingly.

@Min-Liu I would like some time to review the php lexer code as the powershell and python lexer shows better performance with the same text pasted under similar test conditions. Perhaps there is some bad code logic preventing good progression of the styling in the php lexer. This needs some proving in some way to recognize the lexer as bugged and will test in SciTE with similar settings to reproduce the bug.

LuaScript as suggested can help you for now though if the php lexer needs a fix then it should get priority with posting an issue and where it should be posted. This may take some time as the lexer code is complex.

@PeterJones I just tested in SciTE SC1 version 5.5.8 Scintilla:5.5.8 Lexilla:5.4.6 with idle.styling=3 in SciTEGlobal.properties. It pastes the 50,000 lines without freezing into a .php file. Can you possibly confirm this test as this implies the php lexer is OK in SciTE, yet is not OK in Notepad++. If confirmed, then the lexer seems OK and goes back to being a Notepad++ issue. The idle styling was not the only setting in Notepad++ that was changed. The versions of Scintilla/Lexilla match with Notepad++ 8.9.

https://scintilla.org/SciTEDoc.html#property-idle.styling

@PeterJones said in The problem with notepad.runMenuCommand:

Simple and light is often the opposite of universal.

This is often the case, but not always.

@PeterJones said in The problem with notepad.runMenuCommand:

If you solution is “universal enough” for you, fine;

Of course, when there is no ideal option, you have to choose the one that is most suitable for the situation.

@Alan-Kilborn said in The problem with notepad.runMenuCommand:

Good luck achieving all of those all of the time.
Or do you have a “pick any 2” or “pick any 3” type rule? ;-)

Thanks. It happens to everyone at some point ;)
But it must be universal and fast, even if it means making the code complex.

@PeterJones Thanks so much for the quick reply. Installing the release candidate fixed the issue for me. Much appreciated!

@El-Greco-0 ,

The Ctrl+Tab / Ctrl+Shift+Tab is the “Document Switcher” feature. By default, Settings > Preferences > Misc > Document Switcher has ☑ Enable MRU behavior checkmarked, which turns on Most Recently Used (MRU) order for the Ctrl+Tab order. If that is unchecked, then the Ctrl+Tab order is determined by the order of the tabs in the view, so if you turn off that option and use Window > Sort By > Name A to Z, then Ctrl+Tab will follow alphabetical order.

The reason why Ctrl+Tab defaults to MRU, is because it is often (maybe even mostly) used as the quick/simple “swap between this tab and the last tab I used”, rather than cycling through the entire list. Also, there is a separate set of keystrokes, Ctrl+PageDown for next-tab and Ctrl+PageUp for previous-tab, which already follows the order of tabs in the view (so also affected by the Window > Sort By > … sorting), so it’s already easy to navigate between tabs in the view order by another similar means – so again, it makes sense to default the Document Switcher Ctrl+Tab to use Most Recently Used behavior…

@PeterJones I am happy :)