You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been playing with inline markup/xml feature of Haxe, but noticed a problem with code completion: no matter what the macro is returning as expr in place of the @:markup meta, code completion will not be affected by it. Instead it will always provide the same @:markup thing (which by the way only work on the first character <):
Code completion inside a ${} isn't working either, even if the macro returns a matching expression (see the macro below).
I would expect that the code completion would reflect what the macro actually returns as expression, so if it returns a string literal expression like in my macro, then the code completion would reflect that string.
As a comparison, this is what I have if, instead of the inline markup, I put directly the same string literal as the one my macro would return. In that situation, everything is working as expected:
Here is the example reproducing the case with a macro that converts any inline markup to the equivalent string literal (single quoted):
To confirm that my macro returns a valid single quoted string literal, I checked the js output, which is correct in referencing the ${name}. Only the code completion is missing.
It would be great if code completion was working in that situation, because that's so far the biggest obstacle against building well integrated react-style/jsx-like libraries for Haxe. Everything else in Haxe is there and well designed already for that, especially taking advantage of macros to process the inline markup 🙏
The text was updated successfully, but these errors were encountered:
So, it seems that some completion can be provided using the right EDisplay() for the right display queries, but this doesn't seem to work when using build macro and seems to only work when using an expression macro, that is, when wrapping the inline XML inside a method like jsx( <your markup />).
Aside from this, EDisplay usage is not documented as far as I know, and the implementation using it in haxe-react (react-next) is quite hard to understand and make sense of. At least I didn't manage to understand it enough so that I can provide satisfying code completion (only managed to provide some rudimentary Hover/Definition display completion). Anything wrapped in ${...} doesn`t provide any code completion like I would have when wrapping the xml in a single-quoted string.
All-in-all, I don't really know how to make it work right now with the elements I have. As a workaround I'll manage with inline markup inside a single-quoted string, but this issue remain.
I have been playing with inline markup/xml feature of Haxe, but noticed a problem with code completion: no matter what the macro is returning as expr in place of the
@:markup
meta, code completion will not be affected by it. Instead it will always provide the same@:markup
thing (which by the way only work on the first character<
):Code completion inside a
${}
isn't working either, even if the macro returns a matching expression (see the macro below).I would expect that the code completion would reflect what the macro actually returns as expression, so if it returns a string literal expression like in my macro, then the code completion would reflect that string.
As a comparison, this is what I have if, instead of the inline markup, I put directly the same string literal as the one my macro would return. In that situation, everything is working as expected:
Here is the example reproducing the case with a macro that converts any inline markup to the equivalent string literal (single quoted):
The class processed by the macro
The macro
To confirm that my macro returns a valid single quoted string literal, I checked the js output, which is correct in referencing the
${name}
. Only the code completion is missing.It would be great if code completion was working in that situation, because that's so far the biggest obstacle against building well integrated react-style/jsx-like libraries for Haxe. Everything else in Haxe is there and well designed already for that, especially taking advantage of macros to process the inline markup 🙏
The text was updated successfully, but these errors were encountered: