@guy038 said: Oh, my God : I forgot to test with If you are interested in such things, you’ll find some very curious results using proportional fonts. When Vertical Edge Settings: Background mode is checked, the highlighting for overlong lines is based on counting characters; when it is not checked, the edge position is (or positions are) based on the width of a space in the default font. (You can see the difference by having a file with sufficiently long lines open, setting a proportional font, then opening Preferences to the Margin/Border/Edge panel, setting a single vertical edge, and toggling Background mode.) The Notepad++ Split Lines command bases its division on the width of a capital “P” in the default font multiplied by the (last) edge column, and hence doesn’t match either. Scintilla sets edge markers based on columns (counting in background mode, using the width of a space character otherwise), so there isn’t a lot Notepad++ can do about that. Scintilla does splitting based on pixel widths; there might be a fair argument for Notepad++ doing its own splitting instead of using Scintilla’s when splitting is based on an “edge” with Background mode checked. Except for the visible line ending oddity, splitting by view width (that is, when there is no edge) works as one would expect. Why Notepad++ uses the width of a capital “P” to get the width to which to split lines when Scintilla uses the width of a space to draw the edge line, I can’t guess.

Tabs v spaces As Peter said, the most important part is consistency. Mixing tabs and spaces together makes no one happy. I will throw out a couple arguments for tabs here: Indentation of code, markup language, et. cetera is meant to show the structure of whatever. Tabs are a logical, structural element. Spaces are physical. Different users may want different sizes of indentation. If i want 4 character indentation and my coworker wants 2, tabs can be set to show our preferred width. Seems for the most part that spaces are winning out though.

Hi, @thomas-knoefel and All, For these Search Results : Search "Fi" (27 010 hits in 646 file(s)) [1 153 file(s) searched], I got, successively, using your valuable instructions : 1 m 13 s 78, then 1 m 10 s 85 and finally 1 m 11 s 06 when LoadThreads="auto" 1 m 25 s 78 and 1 m 26 s 39 when LoadThreads="0" 1 m 09 s 54 and 1 m 09 s 55 when LoadThreads="8" So, the two tests with LoadThreads="8" seem very slightly better !? Note that : From Laptop documentation, my processor is an Intel® Core™ i7-1165G7 2.80 Ghz (up to 4.7 GHz with Intel® Turbo Boost Technology ) 12 MB L3 cache, 4 cores 8 logical processors From informations système, I saw for Processeur : 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 2803 MHz, 4 cœur(s), 8 processeur(s) logique(s) Total installed RAM : 32 Gb This explain why I wanted to test with 8 threads. But, may be this assumption is not pertinent ! ? Best Regards, guy038

@ThatsYar_ , Can you share your ?-menu’s Debug Info? Does the same problem occur if you turn off all plugins (using -noPlugin command line option)? Is it for all files that need admin? Or just in one directory? Or just the one file?

@Steven-Guillemet said: Hopefully this will let Notepad++ ditch its current method Until that patch has effectively 100% deployment, Notepad++ should not change its implementation, otherwise it breaks something that currently works for anyone who hasn’t applied that fix. (If there’s a way to make the two methods coexist peacefully, or if there’s a way the installer can test the version and use the appropriate alternative, then that’s great. But if not, then breaking a feature to support bleeding edge is a bad idea)

That’s a clever little experiment! I never really thought about using regular expressions to represent mathematical patterns like multiples of 3, but it makes sense when you look at the binary sequence. Definitely a fun way to explore just how powerful regex can be beyond ordinary text searching.

@vivek-viv , Unfortunately, there are an unknown number of “programming languages” or “data file languages” in the world, and no text editor can syntax-highlight 100% of them out-of-the box. Apex is not available in the syntax-highlighter library that Notepad++ uses, and until it is, it will never be in the upper portion of the Language list. To get it added: A feature request would have to be put into Lexilla, and then the Lexilla team, or external volunteer, would have to code up that lexer, and they would have to accept it, bundle it with the library; then Notepad++ could update to use a version with that, and then and only then, Notepad++ could be updated to enable and list the Apex language in the default menu. I’m not saying it’s impossible… just that it’s not likely to be fast. If Apex were similar enough to another language, then, in theory, the Apex language could be mapped to use the that existing language’s lexer, but given its own list of keywords. However, Notepad++ has the User Defined Language (“UDL”) feature, which allows you to define a keyword-based syntax highlighting – so you can put in various lists of keywords, operators, folding-keywords, and delimiter pairs, and get it to do a reasonable job of highlighting simple syntax in your language. The User Defined Language page, and all the UDL > pages in the manual’s table of contents below it, describe how to use the UDL system. There’s also a community-contributed User Defined Language Collection, where people can share UDL definitions that they’ve made, or find ones to use for themselves. I don’t see Apex there… but if you created one, you could share it there, so that other Apex users I did a quick search, and if this is the Apex you are talking about, then it looks similar to YAML (builtin) – so maybe trying to use the YAML lexer might be an initial workaround. And google search AI tells me that the HAML uses a similar structure – there is a UDL in the Collection for HAML, so you might be able to use that as a reference for how to get something like what you want for Apex. No guarantees, but it’s a starting point…

JsonTools v8.6 is now available for download (it’s not up on the Plugins Admin yet, pending my PR to NppPluginList). Major changes: Fixed potential for Notepad++ to hang or crash due to: RemesPath queries with a for loop over an empty array Maliciously crafted schemasToFnamePatterns.json config file RemesPath queries that generate too-deep JSON (which previously could have caused stack overflow) List of 16 most recently used unique RemesPath queries (stored in config file, accessible by menu command) New control in JSON to CSV form, allowing columns to be listed in the order that they occurred in the first record, rather than in alphabetical order

@PeterJones Good info on StyleID, thanks.

Regex is definitely the way to go for this kind of filename cleanup in Notepad++. It’s great how a simple search-and-replace can handle a whole list of filenames at once instead of renaming each one manually. Just make sure to test it on a few files first to avoid any unexpected changes.