[Bug] Error when adding more lines to a webr code block initialized with only 1 line.

[alexCardazzi]

Here is an example of some code I am using:

---
title: webR in Quarto HTML Documents
format: html
engine: knitr
filters:
  - webr
---

This is a webr-enabled code cell in a Quarto HTML document.

```{webr-r}
print("hello")
```

When I render, all is well and the print() code executes. However, when I add a second line of code (e.g. print("goodbye")), the code breaks. The error is as follows:

Error: :1:15: unexpected input
1: print("hello")

[coatless]

@alexCardazzi I can't re-create the error you are running into. Please include the document verbatim with the spacing between the two print statements.

I think there might be some random return character being inserted. What is your operating system, locale, and web browser?

You can see examples of multi-line returns working here:

https://quarto-webr.thecoatlessprofessor.com/tests/qwebr-test-output-classes.html

https://quarto-webr.thecoatlessprofessor.com/examples/website/example-page.html

P.S. Please avoid using quotes on code cells. Instead, please use an extra code block with a backtick, e.g. we modified the above issue with:

````md
content here
````

[alexCardazzi]

---
title: webR in Quarto HTML Documents
format: html
engine: knitr
filters:
  - webr
---

This is a webr-enabled code cell in a Quarto HTML document.

```{webr-r}
print("hello")
```

```{webr-r}
print("hello")
print("goodbye")
```

Multi-line returns work in the second, but not first, code block in the example above. The first code block will execute as expected with just the first line, but if I were to add print("goodbye") as a second line in the first block, it will return the error above. This does not happen in the second block. See attached images.

I am using Chrome 119, Quarto 1.4.502 (though this happened with previous versions too), and your latest release of quarto-webr.

> sessionInfo()
R version 4.2.1 (2022-06-23 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19045)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.utf8  LC_CTYPE=English_United States.utf8   
[3] LC_MONETARY=English_United States.utf8 LC_NUMERIC=C                          
[5] LC_TIME=English_United States.utf8    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] compiler_4.2.1  tools_4.2.1     rstudioapi_0.14 knitr_1.40      xfun_0.39      

Thanks for looking into this.

[coatless]

@alexCardazzi I'm still unable to re-create this. I think for some odd reason Windows might be inserting an odd character. Is there any way I could get a copy and paste of what you are adding into the above code cell? It seems like this is a whitespace issue either with a locale or specific to Windows.

One way to approach it in Chrome would be to open the Web Developer toolbar using either:

1. Right-click a page and select "Inspect Element"; or
2. View > Developer > Developer tools

Type the new line, add the print("goodbye") line, and, then select the content immediately after print("hello") with the Developer tools. For example:

You can see an example of "Inspecting" the element with:

https://developer.chrome.com/docs/devtools/open/#shortcuts

Apologies for not have a better way of doing this; however, the issue is more on run-time than it is on the document being rendered.

[alexCardazzi]

@coatless

Immediately inside, the difference is small and there does not seem to be any weird character.

I can provide you the actual html if you want, in case it's an issue with a parent-element.

[coatless]

@alexCardazzi Hmm... I did not expect that.

Let's try one more thing. Based on the screenshots, I'm not seeing the error text under the first cell. Could you try running the code in the first cell to see if the error appears? Then, could I get the HTML dump for the editor?

Out of pure curiosity, do you have any kind of extensions enabled that would modify an input field? (Something like Grammarly, Google Translate, or something else?)

Thinking about my options here:

1. Trim whitespace before attempting to run.
2. Replace all line endings with \n before running.
3. ??

[alexCardazzi]

@coatless Sorry for the delay...

Here are two more screenshots.

In addition, here is the html:
webr_ex.txt

I am not sure what's going on, but it happens in the RStudio Viewer too. I'm not sure if that's basically Google Chrome, but I figured I'd mention it.

---

Edit: I just tried to open that file and the output is not looking like the screenshots... I wonder what's going on with that.

[ute]

I have experienced the same strange behaviour. It seems to show up when the original code in a cell has less than two lines.

Even comments would do the job to avoid that error.

[coatless]

@ute ewk! On this one, I'm not sure what's going on. We're fundamentally pulling information from editor as-is. Is it a local encoding issue creeping in? I'm truly at a loss for words for what's happening as I can't safeguard without knowing the character; but, I can't seem to reproduce to get the character...

Would you be okay with attaching a zip of the above files (including the rendered output)?

Also, do you know if this was happening more or less frequently with 0.3.9 or ono 0.4.0-dev.5?

Sidenote to myself: Maybe bump the Monaco Editor dependency again?

[coatless]

@ute So, I bumped the version of MonacoEditor being used in the extension up to 0.45.0.

Alas, the release notes over there are not verbose when it comes to a bug fix; but, maybe the editor retrieval was improved...

https://github.com/microsoft/monaco-editor/blob/698e0ecafd27c6759d74aa98b983e73f25e2baae/CHANGELOG.md

[ute]

The new MonacoEditor version does not seem to help, unfortunately 😞. But since it is easy to work around the problem by always having at least two lines of prefilled content, this is not a pressing issue 😃
reprex-emptywebr.zip

I am on a Windows 11 machine, LCID 1033. However, this machine may be have been set up as Danish originally.

[coatless]

@ute thank you so so much. I was able to reprex it on my end under parallels

No promise on when I can identify what's up; but, this is a huge huge huge step forward.

[ute]

ah, so it is not the locale.
I just tried with your old CodeMirror versions 0.0.4 and 0.1.0. These work.

Seems that the second line gets turned into something weird when there initially only was one line

But still, as long as the whole works is not submitted, ctrl-enter works:

[coatless]

@ute well, the mystery was quickly revealed: LF vs. CLRF line endings.

The patch should come soon.

Thank you so much for the reprex!

[ute]

👍 Yeah, I also found that one. Just tried a hack in qwebr-compute-engine.js, l. 179 added:

// Monaco seems to append returns \r to code when there initially is only one line
 // here is a hackish workaround
 codeToRun = codeToRun.replace(/(\r)/gm, "\n");

but I was wondering if this affects different operating systems differently?

On that occasion, I found that output length is unpredictable - try cat("firstly\nsecondly") in a code cell...

[ute]

Wow, you are fast 👍
So no more unnecessary comments in code cells for students 😄

[coatless]

@ute it really helps to have a reprex and someone to test. Plus, it's the weekend! 😄

[coatless]

@ute I split the cat() portion into a new issue ticket. That's a separate issue needing a bit more debugging effort.

In the interim, this seems to work well.

cat("firstly", "secondly", sep ="\n")

For more, let's aim to discuss in #133.

[ute]

Yes, its the weekend 😄 - sorry for the cat("1\n2") thing. It was not meant as an issue

[coatless]

@ute no worries; it helps align running code using an installed copy of R with the web version. So, the more the merrier!