@htl JavaScript comments are being parsed incorrectly

[paulbthub]

Inside a cell that defines a function as @htl code, inside a <script> block, an unmatched parenthesis/bracket/curlybracket behind a // JavaScript comment marker should -- surely? -- be completely ignored. However, it's being detected and parsed in a way that breaks Pluto's bracket-pair highlighting feature for every bracket-pair that the comment lies inside of.

In a presumably related issue:

Similarly, inside a cell that defines a function as @htl code, inside a <script> block, if the JavaScript comment marker // is used to comment out a line that contains eg $anything, the cell will throw an 'UndefVarError: anything not defined' error if anything doesn't exist. Corresponding syntax errors are also thrown by other $-expressions. Again, my understanding would be that commenting out a line should stop the cell from evaluating and/or caring about any of these $-expressions. (moved as requested below)

[fonsp]

Can you edit your post to delete the second issue here and post it to HypertextLiteral.jl instead?

[paulbthub]

Can you edit your post to delete the second issue here and post it to HypertextLiteral.jl instead?

Sure, no problem. Moved as requested.

[clarkevans]

In HypertextLiteral #15, @paulbthub represents that he doesn't want to use string interpolation. Therefore, he probably has no need to be using @htl. Perhaps when he uses html non-standard string literal instead, his challenges regarding syntax highlighting will also be resolved.

[paulbthub]

In HypertextLiteral #15, @paulbthub represents that he doesn't want to use string interpolation. Therefore, he probably has no need to be using @htl. Perhaps when he uses html non-standard string literal instead, his challenges regarding syntax highlighting will also be resolved.

Hi again -- and thanks for the suggestion.
(Fwiw, it wasn't quite a simple as changing @htl("...") to @html"...", but changing --

ClickCounter(text="Click") = @htl("""...""")

to

function ClickCounter(text="Click") """...""" |> HTML
end

-- seems to do the trick.

Unfortunately, running the same four test conditions (anything, $anything, //anything, //$anything) produced the exact same results as documented in the linked @htl issues thread. In other words, the $ is still breaking through the comment markers.

So I'm happy to not use @htl and to close the issue on the HypertextLiteral page -- but I guess it needs to be reopened here. In fact, now that I have an html version of ClickCounter to play around with, I can see that an unmatched bracket/parenthesis/curly bracket behind a comment marker breaks the bracket-pair highlighting feature in html as well.

That is, both of the issues originally reported above in the @htl context are also being repeated in the exact same way in the |> HTML context.

Should I just close this thread and repost the entire thing again with the new heading 'HTML JavaScript comments are being parsed incorrectly'.

[clarkevans]

Did you try changing it to html"..." as I suggested? The html non-standard string literal lacks string interpolation of $ as you seem to be expecting.

ClickCounter(text="Click") = html"""..."""

Regardless, this issue you're talking about is neither a Pluto issue nor a HypertextLiteral issue. You seem to be confusing 2 contexts: processing in Julia vs processing in JavaScript. Julia processing happens server side, well before the JavaScript comment is processed. In particular, it's not that JavaScript comments are being parsed incorrectly... they simply aren't being parsed by Julia. The behavior you are experiencing is both expected and correct.

[paulbthub]

Did you try changing it to html"..." as I suggested?

Argh, sorry! I somehow completely failed to see/realize that the @ needed to be omitted as well.

And yes, as you anticipated, with the correct syntax, ie ClickCounter(text="Click") = html"""...""", comment markers now work as I would expect. That is, anything and $anything produce the expected 'undefined variable' errors while //anything and //$anything both serve to 'hide' the expressions and cancel the errors.

I notice however that within the html block, the expression $(text) no longer resolves to 'Click' but instead is now being treated as a literal string(?) such that the button is labelled with the expression itself rather than its value. I don't see this behavior when using the |> HTML technique, but it's happening here. Can you advise on the syntax for passing the function's argument values into the html """...""" code?

[clarkevans]

I notice however that within the html block, the expression $(text) no longer resolves to 'Click' but instead is now being treated as a literal string(?) such that the button is labelled with the expression itself rather than its value.

So, the html non-standard literal doesn't do interpolation, which is why $(text) no longer resolves. If you want interpolation of $ to happen relative to HTML context, you'll want to use @htl. In this case, $ interpolation will happen before the content is sent to the browser, and hence before JavaScript's comment markers are considered. Once again, it's not that the comment markers are being parsed incorrectly... it's that the server side Julia program logic doesn't even consider them. In other words, you've described behavior exactly as one would expect it to work, and I don't see any problems with either Pluto or @htl in this regard. The solution is to avoid undefined Julia interpolation references inside a JavaScript comment block.

With regard to bracket syntax highlighting, I don't have enough information to assess this. Complete working examples are always the best way to get helpful feedback.

[paulbthub]

If you want interpolation of $ to happen relative to HTML context

Thank you for your explanations and continuing patience. So the problem -- for me -- is that, for argument passing, I do want interpolation of $ to happen relative to HTML content, whereas to meet my prior expectations of comment behavior, I do not want interpolation of $ to happen relative to HTML content.

Although this appears to create an irreconcilable contradiction, I think it could be achieved if comment stripping was the first operation performed by whatever logic gets first shot at parsing the contents of the cell. However, I accept that this isn't going to happen; I can choose one behavior or the other, but I can't have both.

Anyway, thanks again for all your time and consideration.