Bounty 200$ - VSCode haxe-jsx extention

Job Postings
, ,
21

xml-haxe

Ah, this made me want to try right away if i can match an incomplete tag without breaking the string parsing, and so far it works. The use case in the gif above used to break the syntax highlighting on my previous work, but I just fixed it by improving the grammar :slight_smile:

2 Likes
22

So, this is what I came up with: (captures are self-explanatory, read comments in screenshots)

01
011084×308 26.6 KB

56
561024×396 28 KB

08
08888×302 19.7 KB

15
151842×116 17.8 KB

07
071988×1008 216 KB

08
081454×970 80.7 KB

In summary:

  • XML strings can be matched if the strings starts (in its first line) with an opening tag.
  • There are some cases (for indentation mostly) where we want to start the xml on the next line. Then we need to be explicit and precede the string with @xml meta to treat the string as XML
  • String interpolation is mostly treated in the same way as haxe standard strings depending on the type of quotes we are using
  • Incomplete XML content in strings never breaks syntax highlighting of the rest of the file, but incomplete string interpolation does (just like normal haxe strings)
  • The idea of using an @xml meta before the string is to try to be as agnostic as possible, while using valid haxe syntax. Plus this meta could be used by frameworks in macro code
  • The jsx() call is handled because it is the default way to write jsx-like code in haxe-react and would make it much nicer for people using haxe-react with vscode. We could decide to remove this part and stick with a 100% agnostic solution, but I believe that would just create more friction to newcomers while non-haxe-react developers really probably don’t care if jsx() is triggering xml syntax highlighting.

Interested in your opinion on these, but all of the above works!

4 Likes
23

Congrats, this is awesome! :slight_smile:

Any particular reason for the 2nd rule though? If we skipped that, you wouldn’t need special treatment for jsx and it would work with hxx too.

24

That’s very nice! What about ‘go to definition’ from markup?

25

@back2dos The second rule is mostly a limitation because I didn’t find any way of matching the xml preceded with line breaks. I agree that it would be great if we could remove it, but didn’t find a way to do so yet. There are a bunch of things I want to try before saying it’s not possible though!

@alex_dja Go to definition from markup is out of the scope of my work here and I personally don’t plan to do anything about it, however go to definition works from ${identifier} and $identifier like in regular haxe strings.

26

Or… what about this much simpler approach (that I just made work as well):

13
131672×1670 307 KB

You will notice with that approach a slight difference: text is still displayed in green, like “text in string”, but that’s ok I guess.

(this wouldn’t require ANY framework specific stuff nor @xml meta)

27

It’s rather awesome, but I have mixed feelings about always colorising.

I suppose it’s harmless to add @xml even if nothing uses it? Then maybe we stick to a list of @xml or fsx( or hxx( and leave normal strings uncolored?

28

In my latest proposal, I am skipping xml syntax coloring on double quoted strings to still give the option to developers to discard xml syntax coloring if they really don’t want it, just like they may use double quotes to skip haxe string literals as well. That could be a compromise which doesn’t require to hardcode any framework identifier?

1 Like
29

Ah yes, didn’t notice that - though allowing text around the XML sound like a bad idea as it’s invalid for any sort of XMLish.

30

Nothing stops a developer to use the syntax coloring to make snippets of XML code that could be integrated in a bigger XML content etc… making the snippet itself valid in the use case. I am not making any assumptions here, and it may not even be possible to skip the syntax coloring of xml depending on this rule anyway so… :frowning:

31

Right that seems like a good compromise anyway.

If that was part of the official plugin, would there be a way (excepted using double quotes) to disable this behaviour (some people are really opinionated)? I’m fine with instructions to go manually patching the syntax file :smiley:

@nadako do you think this is something we could get accepted?

32

I guess it’s always possible to patch the syntax file afterwards, even if that’s also a bit hacky.

In the same fashion, I guess it would also be possible to run a script to patch existing syntax file locally to add xml string parsing, but I’d rather have it integrated by default if most users are fine with it.

33

Yeah, I think we can accept this, if it’s not too invasive (ideally - a single “include” of a separate tmLanguage file), so we can remove it if/once vscode gets some way to patch/replace tmLanguages by an extension, and if you pledge to support it (replying to/fixing issues on github) :slight_smile:

34

@nadako You can find the work on this fork of haxe-TmLanguage.

For now I opted for the option of putting everything xml-related at the end of the haxe syntax file, and insert a single include in the strings: part of haxe grammar. So, it’s in the same file but very easy to remove.

If you think using a separate grammar file (with its own scope name etc…) is better, then I can try that (but not sure about all the implications, in that case, do we need to declare a new grammar file in vshaxe’s package.json?)

35

And obviously, if there are any bugs on this I will be happy to fix them!

36

Some news on VSCode side:

This has already been discussed in various issues and on various occasions. The outcome is that VS Code won’t do anything special for embedded languages and that it’s the sole responsibility of the embedder, e.g. html must know that it embeds js and it must handle it.

Related issue: Implementation suggestion for embedded language functionality · Issue #43538 · microsoft/vscode · GitHub

In other words, if we do want to highlight XML syntax in Haxe, there are no other option than adding the syntax in Haxe grammar and VSCode doesn’t plan to change this anytime soon.

@nadako I will give a try to putting everything XML-related in a separate file included by Haxe grammar. If that works I will make a new PR with the result.

2 Likes
37

Hi, guys! What about Go to definition from jsx function?
@nadako, please give some advise how this feature might be implemented.

38

I think it should be possible if you’re do precise bookkeeping of generated expression positions. @back2dos might have more knowledge about that. If there are issues we can fix regarding it - please report :slight_smile:

39

Hi guys,

I did not follow the topic from the beginning so I’m a bit lost about the current state of this evolution.

I’ve seen this and this but it’s a bit confused about the current situation of all this.

Are we about to get haxe jsx syntax highlighting in vs code or is it currently stuck?

40

You can replace the extention haxe language file with this one https://github.com/jeremyfa/haxe-TmLanguage/blob/xml-string-single-quotes/haxe.tmLanguage. Unfortunately it wasn’t included in the nadako extention:(( By the way why?