Support for RTypst by jalvesaq · Pull Request #575 · R-nvim/R.nvim

jalvesaq · 2026-05-10T00:04:44Z

No description provided.

jalvesaq · 2026-05-10T00:09:35Z

Support for Typst was added to knitr on GitHub on Mar 22, 2026. It's not available in the last released version of knitr.

jalvesaq · 2026-05-10T11:00:09Z

My approach in this pull request was to set the filetype of a .Rtyp file as typst and then enable R.nvim features for the Typst filetype. Would it be better to set a new filetype, Rtyp, and rename ftplugin/typst_rnvim.lua as ftplugin/rtyp_rnvim.lua?

PMassicotte · 2026-05-10T11:00:48Z

    return chunks
 end

+--- Get code chunks from an RTypst (.Rtyp) document by scanning ```{r} and ```  markers.


Can we not use

R.nvim/lua/r/chunk.lua

Lines 97 to 154 in 2d0cd15

local get_rmd_code_chunks = function(bufnr)

local root = require("r.utils").get_root_node()

if not root then return nil end

local query = vim.treesitter.query.parse(

"markdown",

[[

(fenced_code_block)

@fenced_code_block

]]

)

bufnr = bufnr or vim.api.nvim_get_current_buf()

local code_chunks = {}

for id, node, _ in query:iter_captures(root, bufnr, 0, -1) do

local capture_name = query.captures[id]

if capture_name == "fenced_code_block" then

-- Loop through all children of the node and print their type and text

local lang

local info_string_params = {}

local comment_params = {}

local content_text = ""

local start_row, _, end_row, _ = node:range()

for child in node:iter_children() do

if child:type() == "info_string" then

local info_string = vim.treesitter.get_node_text(child, bufnr)

lang, info_string_params = M.parse_info_string_params(info_string)

end

if child:type() == "code_fence_content" then

content_text = vim.treesitter.get_node_text(child, bufnr)

-- Get the parameters specified in the code chunk with #|

comment_params =

M.parse_comment_params(vim.treesitter.get_node_text(node, bufnr))

end

end

-- Create the chunk object with the extracted information

local chunk = Chunk:new(

content_text,

start_row + 1,

end_row,

info_string_params,

comment_params,

lang,

node

)

table.insert(code_chunks, chunk)

end

end

return code_chunks

end

I think rtyps uses the same structure?

I think

local params_str = lines[i]:match("^```{r}$")

Will not capture params in r chunks, like {r echo=FALSE} or {python}

It was easier for me to use regular expressions, but if you could rewrite the function using tree-sitter, it would be great.

PMassicotte · 2026-05-10T11:04:49Z

I think we could just do that in config.lua

vim.treesitter.language.register("markdown", { "quarto", "rmd", "rtyp" })

Then we could just reuse get_rmd_code_chunks + parse_info_string_params + parse_comment_params all. My preliminary understanding is that we already have all the tooling to parse rtyp code chunks.

What do you think?

PMassicotte · 2026-05-10T11:06:10Z

My approach in this pull request was to set the filetype of a .Rtyp file as typst and then enable R.nvim features for the Typst filetype. Would it be better to set a new filetype, Rtyp, and rename ftplugin/typst_rnvim.lua as ftplugin/rtyp_rnvim.lua?

Yes, I think this is the right approach.

jalvesaq · 2026-05-10T11:08:54Z

vim.treesitter.language.register("markdown", { "quarto", "rmd", "rtyp" })

It would not work. Typst is very different from Markdown. It uses = instead of # for titles, and uses # as a prefix for functions in a similar way to LaTeX, which uses \.

jalvesaq · 2026-05-10T11:32:12Z

Yes, I think this is the right approach.

This was my first thought. But then I realized that if the file is a Typst file, we can send the R code to R Console, but we will not be able to process the R code when rendering the PDF because knitr converts a .Rtyp file into a .typ file. If the file extension is already .typ, it would not work because it would overwrite itself.

jalvesaq · 2026-05-10T11:32:33Z

I'll be able to continue working on this only at night...

PMassicotte · 2026-05-10T12:08:20Z

This is what I got so far with TS.

If ok with you, I can push my changes.

PMassicotte · 2026-05-10T12:08:48Z

Note: r_ls should be activated for that filetype.

fix(ftplugin): use pcall for treesitter query set to handle errors refactor(chunk.lua): remove custom RTypst code chunk parsing feat(cursor.lua): add typst support for moving to next code chunk fix(lsp/init.lua): correct iteration over attached_buffers feat(maps.lua): add typst support for RSendChunk and related mappings feat(send.lua): add typst support for sending lines and chunks

PMassicotte · 2026-05-10T12:13:56Z

PS. I have not tested knitting, I do not have the dev version of knitr installed.

PMassicotte · 2026-05-10T12:17:41Z

I will push this, let me know if it works for you, otherwise we can just delete the commit if anything :)

PMassicotte · 2026-05-10T12:46:21Z

I am currently using Markdown parser to get the chunks code, inline params and chunks parameters, The Markdown grammar is resilient enough to work with typst filetype.

I started to implement a typst specific TS extraction code, but we have to do some manually regex job to get the inline parameters in chunks like:

```{r, eval=TRUE}
plot(
  x,
  type = "b",
  main = "Random Normal Values",
  xlab = "Index",
  ylab = "Value"
)
```

What I have done if more a general refactor on how we get the code chunks based on the file type. At the moment, it works with just using Markdown parser, but maybe I could push the current refactor later in another PR.

jalvesaq · 2026-05-10T23:28:00Z

If ok with you, I can push my changes.

Yes, it was OK. I think you have already pushed...

jalvesaq · 2026-05-10T23:47:26Z

I'm getting this message when trying to send a line from a chunk of R code:

Not inside a supported code chunk.

PMassicotte · 2026-05-11T11:03:37Z

I'm getting this message when trying to send a line from a chunk of R code:

Not inside a supported code chunk.

Back to the office, I will have a look.

jalvesaq · 2026-05-11T11:30:20Z

I've just found that the filetype typst does have the lang node if the block is:

```r
x <- rnorm(100)
```

But not if it is:

```{r}
x <- rnorm(100)
```

PMassicotte · 2026-05-11T13:29:34Z

I have some meetings this morning, I think I forgot to push a change yesterday. Will do that soon.

jalvesaq · 2026-05-11T13:36:56Z

There is no hurry, and I will only have spare time next weekend.

- Broaden tree-sitter injection regex to match chunks with parameters (e.g., `{r, echo=FALSE}`, `{python}`) instead of exact `{r}` only - Use row-based offset (1,0,0,0) to skip the header line regardless of its length, instead of hardcoding column offsets - Add dedicated `get_rtypst_code_chunks` using typst tree-sitter parser instead of forcing markdown parser on typst buffers - Include "typst" in send.lua selection() filetype check

Selene linter does not support LuaJIT goto/label syntax. Rewrite get_rtypst_code_chunks to use nested if-else instead.

The previous `pattern` key with Lua pattern matching did not work with Neovim's `vim.filetype.match()`. Switch to `extension` which correctly maps .Rtyp to typst filetype. Also removes the unnecessary conf override autocmd since the extension approach takes priority.

- Fix injection offset from 1 0 0 0 to 1 -3 0 0 to account for blob node starting at column 3 (after ``` delimiter), resolving wrong highlighting on first 3 characters of each code line - Build typst injection queries dynamically from chunk_langs config, including aliases (e.g., {webr} highlighted as R) - Register chunk_lang aliases via vim.treesitter.language.register() so Quarto/Rmd injection resolution maps aliases to canonical parsers (e.g., "webr" → "r" parser) - Add typst to r_filetypes in lsp/init.lua to fix "Index out of bounds" crash when editing .Rtyp files alongside Quarto files - Add typst to get_lang() dispatch in lsp/init.lua and utils.lua for proper language detection in LSP operations

The blob node's end_row is the last content line, not the closing ``` fence. This caused get_chunk_section_at_cursor to treat the last content line as "chunk_end", silently skipping it when pressing Enter. Use the parent raw_blck node's end_row instead, which includes the closing fence — matching how Rmd uses the full fenced_code_block range.

Lua's `and`/`or` only captures the first return value of range(), so the previous `node:parent() and node:parent():range()` captured start_row instead of end_row. Fix by destructuring all four return values. Also add +1 to convert 0-indexed exclusive end to 1-indexed cursor row, matching how the Rmd chunk detection works. - Fixes "Not inside a supported code chunk" for Python/SQL/Bash chunks - Fixes last content line treated as "chunk_end" instead of "chunk_body"

The refactoring to pcall(get_parser, bufnr, "markdown") broke .R file support because it never initializes the R parser. get_root_node() calls get_parser(bufnr) without a language argument, which initializes the parser for the buffer's actual filetype. Typst files are unaffected since they dispatch to get_rtypst_code_chunks before reaching this path.

Replace the typst-specific branch in get_rmd_code_chunks with a generic get_ts_code_chunks helper plus per-format extractor functions. The Rmd path resolves its root via get_root_node() so .R files still initialize the R parser correctly.

@jiangyun-fun

…age support Brings in Yun Jiang's (@jiangyun-fun) RTypst fixes: dynamic typst injection queries from chunk_langs, chunk_lang alias registration, extension-based .Rtyp filetype detection, and typst support in the LSP/send paths. chunk.lua is kept from our generic-helper refactor (e7f0968), which supersedes #576's standalone get_rtypst_code_chunks while preserving the same .R-parser fix. Co-Authored-By: Yun Jiang <jiangyunacw@gmail.com>

Add a check to warn users if the treesitter parser for the current filetype is not installed.

PMassicotte · 2026-05-14T13:43:39Z

I think this should work now. We might want to have knitr version updated on CRAN before merging in main?

jalvesaq · 2026-05-15T23:42:30Z

Thank you, @PMassicotte and @jiangyun-fun! Everything seems to be Good. Just two notes:

We have to run stylua to format the files:

stylua ftplugin/
stylua lua/

The command \kr will not work for Typst, only for RTypst, and the command \kp should result in different commands being sent to R depending on the file being .typ or .Rtyp. Something like this:

diff --git a/ftplugin/typst_rnvim.lua b/ftplugin/typst_rnvim.lua
index af08276..db59dfe 100644
--- a/ftplugin/typst_rnvim.lua
+++ b/ftplugin/typst_rnvim.lua
@@ -44,7 +53,9 @@ local function build_typst_injections()
     return table.concat(parts, "\n\n")
 end
 
-pcall(vim.treesitter.query.set, "typst", "injections", build_typst_injections())
+if vim.api.nvim_buf_get_name(0):lower():find("%.[Rr][Tt][Yy][Pp]$") then
+    pcall(vim.treesitter.query.set, "typst", "injections", build_typst_injections())
+end
 
 require("r.config").real_setup()
 require("r.rmd").setup()
diff --git a/lua/r/maps.lua b/lua/r/maps.lua
index db6af20..7302531 100644
--- a/lua/r/maps.lua
+++ b/lua/r/maps.lua
@@ -210,7 +210,9 @@ local control = function(file_type)
     create_maps("nvi", "ROBCloseLists",     "r-", "<Cmd>lua require('r.browser').open_close_lists('C')")
 
     if file_type == "typst" then
-        create_maps("nvi", "RMakeRmd",  "kr", "<Cmd>lua require('r.typst').make('default')")
+        if vim.api.nvim_buf_get_name(0):lower():find("%.[Rr][Tt][Yy][Pp]$") then
+            create_maps("nvi", "RMakeRmd",  "kr", "<Cmd>lua require('r.typst').make('default')")
+        end
         create_maps("nvi", "RMakePDFK", "kp", "<Cmd>lua require('r.typst').make('pdf')")
         return
     end
diff --git a/lua/r/typst.lua b/lua/r/typst.lua
index c8becaa..9f1705c 100644
--- a/lua/r/typst.lua
+++ b/lua/r/typst.lua
@@ -4,7 +4,11 @@ M.make = function(outform)
     vim.cmd("update")
     local send = require("r.send").cmd
     if outform == "pdf" then
-        send('knitr::knit2pdf("' .. vim.api.nvim_buf_get_name(0) .. '")')
+        if vim.api.nvim_buf_get_name(0):lower():find("%.[Rr][Tt][Yy][Pp]$") then
+            send('knitr::knit2pdf("' .. vim.api.nvim_buf_get_name(0) .. '")')
+        else
+            send([[system("typst compile ']] .. vim.api.nvim_buf_get_name(0) .. [['")]])
+        end
     else
         send('knitr::knit("' .. vim.api.nvim_buf_get_name(0) .. '")')
     end

jalvesaq · 2026-05-15T23:51:02Z

We might want to have knitr version updated on CRAN before merging in main?

On the one hand, I think it's wiser to wait. On the other hand, we may have to rebase the branch and possibly resolve conflicts if it takes too long for a new version of knitr to be released.

PMassicotte · 2026-05-16T11:23:15Z

Very good comments.

I am not sure what is going on with stylua, why my formatter has not picked it up. I will add a pre-hook to check that.

…ne return fix(typst_rnvim.lua): ensure typst injections only apply to typst files Co-Authored-By: Jakson Alves de Aquino <jalvesaq@gmail.com>

PMassicotte · 2026-05-16T11:26:54Z

@jalvesaq I added your excellent suggestions and added you as co-author of the commit.

jalvesaq · 2026-05-16T11:35:59Z

Thank you, @PMassicotte!

@gueyenono, could you try the branch from this pull request?

gueyenono · 2026-05-26T01:27:55Z

Thank you, @PMassicotte!

@gueyenono, could you try the branch from this pull request?

My apologies. I never saw the notification for this message.
I quickly installed the branch version and everything seems to work fine. It just turns out that R code chunks are all green, so no code highlighting there. The highlighting for Typst works well though.

jalvesaq · 2026-05-26T10:15:55Z

The highlighting of R code is expected to work if the file extension is .Rtyp (case insensitive). I've just simplified the pattern used to recognize RTypst, but it was a cosmetic change and shouldn't improve the file type recognition.

What is the extension of your RTypst files?

gueyenono · 2026-05-26T13:31:10Z

My file extension is "Rtyp", but I also use Nix. So I'm checking if the issue is not with my configuration.

gueyenono · 2026-05-26T14:55:21Z

Actually I found the issue. I created my code chunk with {r} instead of r. It all works perfectly now. Thank you.

jalvesaq · 2026-05-26T15:22:27Z

The header of the code chunk should be {r} for .Rtyp files (which will be converted into .typ by knitr). The header should be r for .typ files.

Did you try <LocalLeader>kp to generate the PDF from the .Rtyp file? It should work with:

```{r}
x <- 100
```

The value of `x` is `r x`.

but not with:

```r
x <- 100
```

The value of `x` is `r x`.

PMassicotte · 2026-05-26T15:46:34Z

Actually I found the issue. I created my code chunk with {r} instead of r. It all works perfectly now. Thank you.

I am also on NixOS and both work on my side. Not sure what can cause this issue on your side.

gueyenono · 2026-05-26T15:52:33Z

You are right. With r as the chunk header, the code in the chunk gets the proper highlighing, but it does execute in the compiled PDF. Also, I did not know that knitr also supported actual typ files!

jalvesaq · 2026-05-26T16:16:28Z

You are right. With r as the chunk header, the code in the chunk gets the proper highlighing, but it does execute in the compiled PDF.

I guess you meant "doesn't execute"...

I did not know that knitr also supported actual typ files!

The development version of knitr supports Typst if the extension is .Rtyp and the block header is {r}, not r.

What about this: "It just turns out that R code chunks are all green"? Did you manage to get R code highlighted in RTypst files?

gueyenono · 2026-05-26T16:50:42Z

You are right. With r as the chunk header, the code in the chunk gets the proper highlighing, but it does execute in the compiled PDF.

I guess you meant "doesn't execute"...

I did not know that knitr also supported actual typ files!

The development version of knitr supports Typst if the extension is .Rtyp and the block header is {r}, not r.

What about this: "It just turns out that R code chunks are all green"? Did you manage to get R code highlighted in RTypst files?

Yes, I meant it "doesn't" execute
Okay, that's what you meant.
Actually, my issue was the way I added chunk options:

#```{r plot, out.width="80%"}

#My code is here.

#```
The fact that there was no comma between r and `plot` (the chunk label) was the reason why the whole chunk was green. It still ran okay, but there was no highlight. Adding the comma fixes it.

jalvesaq · 2026-05-27T13:11:40Z

The fact that there was no comma between r and plot (the chunk label) was the reason why the whole chunk was green. It still ran okay, but there was no highlight.

I fixed the pattern used to recognize the language of the block, and it now works with a space after the language name, but not with a TAB character.

jalvesaq · 2026-05-27T14:02:55Z

We are listing more tree-sitter parsers in the section Installation of dependencies than are needed by everyone. The parsers for markdown and markdown_inline are installed by default. So, perhaps we don't need to list them as dependencies. The recommendation could be:

   Tree-sitter parsers for `r`, `csv`, and:
         - `yaml` for RMarkdown (`.Rmd`), Quarto (`.qmd`), Rnoweb (`.Rnw`) or
           RTypst (`.Rtyp`) documents.
         - `latex` and `rnoweb` for Rnoweb documents.
         - `typst` for Rtypst documents.
      You can install them using any tree-sitter parser manager (e.g., the
      `nvim-treesitter` or `tree-sitter-manager` plugins) or manually.
      https://github.com/nvim-treesitter/nvim-treesitter
      https://github.com/romus204/tree-sitter-manager.nvim

Perhaps even regarding csv it could be:

         - `csv` for viewing matrices and data frames.

Support for RTypst

4a0e644

jalvesaq force-pushed the Rtypst branch from 38eae87 to 4a0e644 Compare May 10, 2026 00:12

PMassicotte reviewed May 10, 2026

View reviewed changes

Enable insertion of chunks with M-r

bf66301

jiangyun-fun added 7 commits May 13, 2026 20:02

fix: replace goto/label with nested if for selene compatibility

5fdee5e

Selene linter does not support LuaJIT goto/label syntax. Rewrite get_rtypst_code_chunks to use nested if-else instead.

fix: remove duplicate comment in typst chunk detection

689b580

jiangyun-fun and others added 7 commits May 14, 2026 18:17

fix(config.lua): handle missing treesitter parser gracefully

8745796

Add a check to warn users if the treesitter parser for the current filetype is not installed.

style(config.lua): reformat wrap_inline and wrap_file functions

571b09c

docs(README.md, R.nvim.txt): add documentation RTypst documents

4ed9a29

docs: correct capitalization of 'Rtypst' in documentation

89b7457

refactor(ast.lua): simplify conditional statements by using single-li…

38761dd

…ne return fix(typst_rnvim.lua): ensure typst injections only apply to typst files Co-Authored-By: Jakson Alves de Aquino <jalvesaq@gmail.com>

PMassicotte marked this pull request as ready for review May 16, 2026 11:26

PMassicotte mentioned this pull request May 16, 2026

ci(ci.yml): add stylua job to check Lua code formatting #577

Merged

Simplify search pattern

88276d8

Fix matching pattern

ad5fdc3

	local get_rmd_code_chunks = function(bufnr)
	local root = require("r.utils").get_root_node()
	if not root then return nil end

	local query = vim.treesitter.query.parse(
	"markdown",
	[[
	(fenced_code_block)
	@fenced_code_block
	]]
	)

	bufnr = bufnr or vim.api.nvim_get_current_buf()
	local code_chunks = {}

	for id, node, _ in query:iter_captures(root, bufnr, 0, -1) do
	local capture_name = query.captures[id]

	if capture_name == "fenced_code_block" then
	-- Loop through all children of the node and print their type and text
	local lang
	local info_string_params = {}
	local comment_params = {}
	local content_text = ""
	local start_row, _, end_row, _ = node:range()

	for child in node:iter_children() do
	if child:type() == "info_string" then
	local info_string = vim.treesitter.get_node_text(child, bufnr)
	lang, info_string_params = M.parse_info_string_params(info_string)
	end

	if child:type() == "code_fence_content" then
	content_text = vim.treesitter.get_node_text(child, bufnr)

	-- Get the parameters specified in the code chunk with #\|
	comment_params =
	M.parse_comment_params(vim.treesitter.get_node_text(node, bufnr))
	end
	end

	-- Create the chunk object with the extracted information
	local chunk = Chunk:new(
	content_text,
	start_row + 1,
	end_row,
	info_string_params,
	comment_params,
	lang,
	node
	)

	table.insert(code_chunks, chunk)
	end
	end

	return code_chunks
	end

Conversation

jalvesaq commented May 10, 2026

Uh oh!

jalvesaq commented May 10, 2026

Uh oh!

jalvesaq commented May 10, 2026

Uh oh!

PMassicotte May 10, 2026

Choose a reason for hiding this comment

Uh oh!

jalvesaq May 10, 2026

Choose a reason for hiding this comment

Uh oh!

PMassicotte commented May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PMassicotte commented May 10, 2026

Uh oh!

jalvesaq commented May 10, 2026

Uh oh!

jalvesaq commented May 10, 2026

Uh oh!

jalvesaq commented May 10, 2026

Uh oh!

PMassicotte commented May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PMassicotte commented May 10, 2026

Uh oh!

PMassicotte commented May 10, 2026

Uh oh!

PMassicotte commented May 10, 2026

Uh oh!

PMassicotte commented May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jalvesaq commented May 10, 2026

Uh oh!

jalvesaq commented May 10, 2026

Uh oh!

PMassicotte commented May 11, 2026

Uh oh!

jalvesaq commented May 11, 2026

Uh oh!

PMassicotte commented May 11, 2026

Uh oh!

jalvesaq commented May 11, 2026

Uh oh!

PMassicotte commented May 14, 2026

Uh oh!

jalvesaq commented May 15, 2026

Uh oh!

jalvesaq commented May 15, 2026

Uh oh!

PMassicotte commented May 16, 2026

Uh oh!

PMassicotte commented May 16, 2026

Uh oh!

jalvesaq commented May 16, 2026

Uh oh!

gueyenono commented May 26, 2026

Uh oh!

jalvesaq commented May 26, 2026

Uh oh!

gueyenono commented May 26, 2026

Uh oh!

gueyenono commented May 26, 2026

Uh oh!

jalvesaq commented May 26, 2026

Uh oh!

PMassicotte commented May 26, 2026

Uh oh!

gueyenono commented May 26, 2026

Uh oh!

jalvesaq commented May 26, 2026

Uh oh!

gueyenono commented May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jalvesaq commented May 27, 2026

PMassicotte commented May 10, 2026 •

edited

Loading

PMassicotte commented May 10, 2026 •

edited

Loading

PMassicotte commented May 10, 2026 •

edited

Loading

gueyenono commented May 26, 2026 •

edited

Loading