Commands in R markdown (.rmd) documents not sent when nested in HTML tags

[simongrund1]

Following the switch from Nvim-R to R.nvim, I noticed that commands from code chunks in R markdown (.rmd) documents are not being sent to the R console when they are nested within HTML tags (e.g., <div> or <p>). An example .rmd document that reproduces this issue for me:

---
title: "Example .rmd file"
---

```{r}
runif(3) # works

```{r} runif(3) # does not work ```

The issue occurs when placing the cursor within the second chunk and running the code with `<LocalLeader>l`, `<LocalLeader>cc` or similar.

Some additional observations:

1) Running `lua require('r.send').line(false)` in the corresponding lines has the same problem.
2) Processing the document with `<LocalLeader>kn` or similar correctly runs all chunk and produces the correct output.
3) The same issue occurs in Quarto (`.qmd`) documents.

The output that I get from `:InspectTree` is as follows:

(document ; [0, 0] - [13, 0] (minus_metadata ; [0, 0] - [3, 0] (stream ; [1, 0] - [2, 0] (document ; [1, 0] - [2, 0] (block_node ; [1, 0] - [2, 0] (block_mapping ; [1, 0] - [2, 0] (block_mapping_pair ; [1, 0] - [1, 26] key: (flow_node ; [1, 0] - [1, 5] (plain_scalar ; [1, 0] - [1, 5] (string_scalar))) ; [1, 0] - [1, 5] value: (flow_node ; [1, 7] - [1, 26] (double_quote_scalar)))))))) ; [1, 7] - [1, 26] (section ; [3, 0] - [13, 0] (fenced_code_block ; [4, 0] - [7, 0] (fenced_code_block_delimiter) ; [4, 0] - [4, 3] (info_string ; [4, 3] - [4, 6] (language)) ; [4, 4] - [4, 5] (block_continuation) ; [5, 0] - [5, 0] (code_fence_content ; [5, 0] - [6, 0] (program ; [5, 0] - [6, 0] (call ; [5, 0] - [5, 8] function: (identifier) ; [5, 0] - [5, 5] arguments: (arguments ; [5, 5] - [5, 8] argument: (argument ; [5, 6] - [5, 7] value: (float)))) ; [5, 6] - [5, 7] (comment)) ; [5, 9] - [5, 16] (block_continuation)) ; [6, 0] - [6, 0] (fenced_code_block_delimiter)) ; [6, 0] - [6, 3] (html_block ; [8, 0] - [13, 0] (block_continuation) ; [9, 0] - [9, 0] (block_continuation) ; [10, 0] - [10, 0] (block_continuation) ; [11, 0] - [11, 0] (block_continuation)))) ; [12, 0] - [12, 0]

[PMassicotte]

I confirm the issue. As a temporary hack, you can add a space after the <div>.

[simongrund1]

For me, this only works with an empty line after the <div> (not a space). But as a quick workaround, it does the job, and adding the empty line also seems to change the output of :InspectTree to something more reasonable.

[jalvesaq]

Since this is a tree-sitter feature/bug that we can't fix, our only option might be to add this issue to the Known bugs section of R.nvim documentation.

[simongrund1]

This is likely a niche issue, but I couldn't find anything about it. So mentioning it in the documentation would be great, but having a "known issues" section in the Wiki would have worked just as well.

Regarding tree-sitter: Is this a known issue in tree-sitter or is it worth reporting this? If the latter, should it be reported in tree-sitter or the tree-sitter-r parser?

[PMassicotte]

Regarding tree-sitter: Is this a known issue in tree-sitter or is it worth reporting this? If the latter, should it be reported in tree-sitter or the tree-sitter-r parser?

Probably just treesitter. I suspect you have the same issue in a simple .md file.

[PMassicotte]

A wiki known issue is a good idea.

[jalvesaq]

I think it would be tree-sitter-markdown, but tree-sitter developers seem to avoid adding too many conditions to not make tree-sitter slow.

We already have a Known bugs section in the documentation. Creating one in the Wiki would require an effort to keep them in sync unless the documentation section just points to the Wiki.

[simongrund1]

From what I gather, tree-sitter-markdown follows the CommonMark specification, which treats anything that follows an HTML tag as verbatim until an empty line is found. So the behavior probably is "as intended" and not worth reporting. Having a note about this somewhere (the doc is fine) would be helpful, because for R users it probably isn't clear that this is expected behavior.

Thanks to you both, I think this issue can be closed.

[jalvesaq]

Thanks for finding this information! I'll copy it to the Known bugs section.