UDL - User Defined Languages has some very silly limits
-
It looks like UDL is due for a complete clean-up. Here are some suggestions, from most important to least important, according to my opinion and current needs.
- Consistency between fields
Keywords accept special characters such as: \n for newline, \t for tab
Delimiter close (or comment style close) allow ((EOL))
Folding in code (style 2) does not allow any of that!
For example, I am defining a language that has two types of IF:
the first:
IF TRUE THEN
DO STUFF
ENDIF
the second:
IF TRUE THEN DO STUFF
there is no ENDIF in this form, and it’s all one line. So to define the code folding open I tried: “THEN\n”. It didn’t work!! Using the same exact syntax in Keywords does successfully detect the word and highlight it only when needed.
This should be fixed so ALL input boxes accept input EXACTLY THE SAME WAY!
-
Confusing Shenanigans
Taken directly from the official (albeit temporary) doc site: http://udl20.weebly.com/numbers.html
Sum up:
Prefix1 and Suffix2 accept numbers only
Prefix2 accepts numbers and Extras1
Suffix1 accepts numbers and Extras2
There is no mistake in this snippet of text.
Prefix TWO accepts stuff from extras ONE
Suffix ONE accepts stuff from extras TWO
I can’t make this stuff up. It’s the most unintuitive set-up possible. -
Arbitrary Limits
You can have 8 groups of keywords. Why? Because!
Let me suggest a better alternative. Start with 3 groups, and have a big button in the corner to Add another one. The user would be able to add (and remove) as many groups as they like! Also, an easy way to re-order the groups would be very welcome.
Same goes for literally every part of the UDL system. Instead of having exactly one set of operators (of each type), or exactly 8 delimiters, or exactly 2 number definitions, you could make each part of this modular/dynamic so it can have exactly as many as the user actually needs.
I truly hope this doesn’t fall on deaf ears. Who maintains the UDL system?
- Consistency between fields
-
I’ve just discovered something terrible. Numbers don’t get detected unless they’re COMPLETELY separate. That means:
array[200] no number detected
array[20, 30] no number detected
array[ 20, 30] no numbers detected
array[ 20 , 30 ] both numbers detected and coloredWTF?!
-
Just write your own lexer, way simpler and efficient ;)
-
How do I do that?
-
@NeatNit-Gralporit
For number detection of your example, you need to defineOperators 1
as:[ ] ,
-
Hi NeatNit,
To detect the numbers you can try the method Claudia-Frank mentioned in my topic. It worked for me!
https://notepad-plus-plus.org/community/topic/11187/need-help-defining-udl -
I have just discovered the exact same problem. It’s all very well defining special operators but when the operators are already defined, it doesn’t work for numbers. The problem is that the number identifier in NotePad++ expects whitespace before and after; when other items are used the detection fails. I have many files that have numbers delimited by commas and brackets and colons and a multitude of other characters, and NP++ misses them all. A better method of detecting a number would probably be whitespace or non-alpha characters as delimiters, so ,4152, [11:22:33], *115454, and [0xffff] would all be detected correctly.
-
@NeatNit-Gralporit The fact UDL doesn’t meet your needs doesn’t mean that it has “silly limit”.
Notepad++ source code can be accessed by everyone, so if there are any part doesn’t match your needs, you are welcome to submit the pull request of your modification :
https://github.com/notepad-plus-plus/notepad-plus-plusKeep one thing in mind that a lot of people work hard for contributing to this project/product, that you’re using with no charge. We don’t ask you to be grateful, we ask you only having a decent attitude when you do your feature request or bug report. I don’t think it’s too much to ask for it.
-
I have a similar issue, I want to pain any 6 digit number in a specific color, and any phone number ###-###-#### in another color. Any idea how to do that?
-
@WildCactuar said:
I have a similar issue
It still would have been better to start a new topic for your question than to re-vivify a 4-year-old topic that’s only vaguely related. However, since my comments would apply to any customization/add-on of the UDL highlighting capability, not just your one specific use, it’s still on-topic for this thread.
AFAIK, UDL isn’t equipped for distinguishing between real numbers and number-like things (like phone or SSN or similar).
However, @ekopalypse has published his PythonScript-plugin-based EnhanceUDLLexer.py or the more-generic EnhanceAnyBuiltinLexer.py, which can be used to add regex-based highlighting to any UDL or any builtin lexer (I don’t know whether the latter also works on UDL, or whether you have to use the former for UDL – but Eko could chime in).
-
Correct, the EnhanceUDLLexer.py is optimized for UDLs whereas
EnhanceAnyBuiltinLexer.py should be used for builtin lexers.@WildCactuar - if you are using a recent npp version, like npp 7.7 onwards then
pythonscript plugin can only be used if you are using a 32bit version. 64bit is broken.
If it is only about to get the telephone numbers highlighted, then you might think of using
a regular expression like\d{3}-\d{3}-\d{4}
and using mark feature from find dialog.
Record a macro if you want to reuse it more often.