Can't figure out a proper way to make this custom UDL work
So I have this user defined language for Minecraft commands:
To make it work properly like this, I had to do quite a few hacks, the main one being this:
Since “tag” is a keyword and I can’t check for “tag=” on another keyword because it doesn’t work, so I had to shove all of those inside operators
There’s also these random ghost folds that appear for no reason (on lines 2, 20, 27, 30, etc.) whenever “Folding In Code Style 1: Middle” exists, and the keywords don’t work properly without it, seems like a bug?
And sometimes when I’m typing a random line of code gets colored as if it was a comment also for no reason, sometimes not even the line I’m typing, and goes back to normal after I click the language dropdown and change the file to the language it already is (to reload), pretty sure that’s also a bug.
I want to keep it looking almost exactly as it already does now, but in a less hacky and glitchy way. Is that possible or the system just is this limited?
Here’s my userlanguage file if needed
Sorry about the long delay; I couldn’t reply when I first read this, and then it fell off my radar. But since no one else has replied yet, I will:
Unfortunately, the UDL system is great for simple syntax, but when you start getting complicated like you want, it’s not sufficient.
There is a way to add regex-based highlighting on top of the normal UDL or lexer highlighting, using the PythonScript plugin and the script
EnhanceAnyLexer.pythat @Ekopalypse shares in his github repo. So you could replace your special needs “operators” and change them to regex in the EnhanceAnyLexer script: something like
r'(x|y|z|X|Y|Z|distance|dx|dy|dz|scores|tag|team|limit|level|gamemode)='… or, if you’d really like “any word characters followed by an equals with no space”, it could be simplified to
The folding-in-code usually works right, but with large source files, I have sometimes seen glitchy or phantom behavior. Unfortunately, the developers have hundreds of open UDL issues, and none of them have been looked at in years, so I think the UDL has seen all the development it’s going to get unless one of the developers is inspired to take it on (and none have to date).
@PeterJones Thanks a lot for the clarification. I think the proposed solution is a bit too complex for me (and the operators didn’t cause me issues), and you’ve sadly confirmed that most bugs I’m experiencing are unfixable, so I might leave it the language as it is.
It is a bit of a pity that it is like this, but it’s not too bad and at least now I know it’s not my fault, so thanks again