as far as I see it works in version v6.8.3. It is just not so nice visualized, but moving tabs can be done. Just check that you have UNchecked option Preferences -> General -> Tab Bar -> Lock (no drag and drop).
When the possibility to link a parser_ID to a name of user-defined language was, first, added, in N++ v6.5, on October 2014, I noticed that the other method, using the extension name of user-defined files, didn’t work at all. Of course, I informed Don ( and some other guys too ) about that issue ! Refer to the first part of my post, below :
By the way, you just have to create a new user-defined language with name OpenSCAD, using the extension scad. It’s no use to define the characteristics of your language, to allow your own functionList parser to work :-)
Secondly, I, slightly, changed your regexes for, both, the mainExpr and Expr items :
I suppose that there is, at least, one blank character, after the key words Module and Function
I changed the syntax [\t ], with the simple \h syntax. Indeed, the exact meaning of \h, with the BOOST regex library, used in N++, is [\t \xA0] ( also known as an horizontal blank character )
In expr, I use the \K syntax, which allows the regex engine to forget everything located on the left of this form ! So, the exact name of the module or the function, without any possible leading blank characters, will be displayed in the FunctionList window :-)
Therefore, in the parsers node, add the lines below :
For instance, these regexes allow the detection of these four syntaxes, below :
Thirdly, your regex, used to detect the comments, ((/*.?*)/|(//.?$)), is NOT a valid regular expression ! So, to define the correct regex, could you tell me the different cases of comments, in OpenSCAD language. From the general form of this regex, I presume that :
A comment line begins with a double slash //
A comment block begins, with the form /* and ends with the form */
Am I right about it ?
See you soon !
Some people may think : Why couldn’t he use a lookbehind construction in expr ?
Indeed, the form below, with a positive lookbehind , seemingly, should work nice ?
But, in the BOOST regex library, lookbehinds must represent an UNIQUE FIXED length strings. So, this regex is INVALID, for two reasons :
The two parts of the alternative, (module|function), have a different length ( 6 characters for the string module and 8 characters for the string function )
The form \h+ is NOT a fixed length string, as it stands for one or more horizontal blank character(s) !
Luckily, the \Ksyntax allows the regex engine to match :
First, the part of the regex, located before the \K form
Secondly, the part of the regex, located, after the \K form, which is the final regex matched !
There was a News item and info on the front page for a fair while from memory.
I tend to keep up to date with versions.
People who lag (for any reason, not all bad) need to phone home when they do upgrade; i.e. check the main site before upgrading any software.