Add Basic Features to Customize Syntax High Lighting

[Jaffe2718]

Basic implementation of syntax highlighting with custom color settings

[Jaffe2718]

Testing 1.1.0-rc1

[Ayfri]

That's neat! Maybe you should add specific syntax coloration for NBTs. For example, I changed namespaces color to green, but it's also showing up for NBT keys:

[Ayfri]

It would be great also to add specific color syntax for reference literals and tagged literals (like minecraft:test and #minecraft:test respectively). Also respecting paths in values (minecraft:test/test), and maybe NBT/States (minecraft:stone{value:1}, minecraft:stone[value=1]).

[Jaffe2718]

That's neat! Maybe you should add specific syntax coloration for NBTs. For example, I changed namespaces color to green, but it's also showing up for NBT keys:

I've noticed this before. But since IntelliJ's syntax parser is based on the JFlex syntax and regular expressions don't support look-ahead matching, I haven't found a suitable way to differentiate between NAMESPACE and NBT_KEY at this point, so I can't currently implement this feature. For example: There is a command give @s minecraft:command_block{owner:jaffe2718,date:"2023/09/08"} It's easy to understand that:

 minecraft:    # <namespace>
 owner:         # <nbt_key>
 date:            # <nbt_key>

So the look-ahead pattern of regular expressions handles this issue: (?<=[,{])[a-zA-Z_][a-zA-Z_0-9]*: -> <nbt_key> The matching result is owner: and date:. Unfortunately, patterns like (? <=[,{]) is not supported in JFlex and will fail to compile. Maybe we can report this issue to the developers of JFlex and wait for update.

And this:

It would be great also to add specific color syntax for reference literals and tagged literals (like minecraft:test and #minecraft:test respectively). Also respecting paths in values (minecraft:test/test), and maybe NBT/States (minecraft:stone{value:1}, minecraft:stone[value=1]).

I can hard to agree with this idea, because these arguments are composite types of data, not indivisible atomic data. For example, #minecraft:test can be seen as a structure of the type <symbol><namespace><element>. Also #minecraft:stone{value:1} can be seen as <symbol><namespace><element><nbt>, and <nbt> is also composite data with <nbt_key>:<nbt_data>. For the convenience of syntactic structure parsing and code-completion functionality, the arguments inside the command must be parsed to indivisible atomic arguments. I think my plugin allows users to read the structure of the NBT more clearly, and uniformly marking the NBT with yellow highlighting like Minecraft Vanilla's command input bar is rather bad.

[Ayfri]

Okay, I see, then I agree with you. JFlex is a really hard library to use, I've tried before to create a plugin for a language that has a very particular syntax (Overwatch Scripts), but I didn't succeed after many days of trying. I'm even impressed by the fact that you've done it with Minecraft functions!

Then another request I might ask is that if it is possible to have different syntax coloring for subcommands and elements? I don't think that it's possible with your current code, but it may help a lot the readability if both tokens were colored differently.

Or also if you could create a separate color for ^ and ~ inside number-like tokens, it's something I tried to do when trying the new update you sent.

I'm maybe asking too much, and say it if it's the case, it's just that I'm someone who likes to have a looooot of features in my IDE, and I have thousands of ideas at any second on how to improve something, and I'm giving some to people whenever I can.

[Jaffe2718]

Anyway, thank you for your suggestion.

I will keep this milestone and keep an eye on JFlex updates. If JFlex updates regular expression lookahead matching, I will update this feature.

From this perspective, the task of basically implementing custom syntax highlighting has been completed. For further optimization progress, please visit #4 .