shortcode argument ">" causes failure of shortcode run

[kernie]

I have:

• searched the issue tracker for similar issues
• installed the latest version of Quarto CLI
• formatted my issue following the Bug Reports guide

Bug description

I developed an extension that forwards quantities to Latex package siunitx like {{< qty 1 \becquerel >}}. siunitx allows also additional chars like < or >, the latter of which causes to fail the shortcode execution.

It works however, if I escape the char like \>.

I can imagine that > somehow triggers a regex that is used to recognize the end of the shortcode sequence, but I think >}} is sufficiently different from that, so I created this issue.

Steps to reproduce

The quarto doc:

---
title: "Test shortcode"
format: pdf
shortcodes: 
  - print_arg.lua
---

{{< print_arg > 10 \becquerel >}}

My lua shortcode in the file print_arg.lua:

return {
  ['print_arg'] = function(args, kwargs, meta) 
    quarto.log.output(args)
    return pandoc.utils.stringify(args)
  end
}

Actual behavior

The log.output for < is:
List {[1] "<", [2] "10", [3] "\becquerel"}

The log.output for > is: nothing. The stringify text doesn't appear.

Escaping helps:
The log.output for \> is:
List {[1] ">", [2] "10", [3] "\becquerel"}

Expected behavior

The arguments of the shortcode should be correctly parsed...

Your environment

• OS: MacOS Tahoe 26.2

Quarto check output

This is one of the recent 1.9 prereleases.

Quarto 99.9.9
[✓] Checking environment information...
Quarto cache location: /Users/becker/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
Pandoc version 3.6.3: OK
Dart Sass version 1.87.0: OK
Deno version 2.4.5: OK
Typst version 0.13.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
Version: 99.9.9
commit: 06697fa
Path: /Users/becker/quarto-dev/quarto-cli/package/dist/bin

[✓] Checking tools....................OK
TinyTeX: v2025.12
Chromium: (not installed)

[✓] Checking LaTeX....................OK
Using: TinyTex
Path: /Users/becker/Library/TinyTeX/bin/universal-darwin
Version: 2025

[✓] Checking Chrome Headless....................OK
Chrome: (not detected)

[✓] Checking basic markdown render....OK

[✓] Checking R installation...........OK
Version: 4.5.2
Path: /opt/homebrew/Cellar/r/4.5.2/lib/R
LibPaths:
- /opt/homebrew/Cellar/r/4.5.2/lib/R/library
knitr: 1.50
rmarkdown: (None)

  The rmarkdown package is not available in this R installation.
  Install with install.packages("rmarkdown")

[✓] Checking Python 3 installation....OK
Version: 3.14.0
Path: /opt/homebrew/opt/python@3.14/bin/python3.14
Jupyter: (None)

  Jupyter is not available in this Python installation.
  Install with python3 -m pip install jupyter

  There is an unactivated Python environment in .venv. Did you forget to activate it?

[✓] Checking Julia installation...

[mcanouil]

I would say you are playing with fire here.
Why not use quotes around the arguments?

[kernie]

Any workaround is OK (for me, for my team mates I would prefer it working without workaraound).

Just wanted to give the Quarto team the opportunity to decide whether this is intended/expected behavior.

[mcanouil]

I would argue that characters such as \ not enclosed in quotes should not be used either.
Not using quotes is mostly for convenience for regular alphanumeric strings, but imagine you want >}} to be part of the shortcode argument, I wouldn't expect anyone to write {{< print_arg >}} >}} but more likely {{< print_arg '>}}' >}} to ensure the argument is treated as one.

Note that even the quarto-markdown project (under-development) can't parse this either.

❯ echo '{{< print_arg > 10 \becquerel >}}'  | cargo run --release -p quarto-markdown-pandoc --
    Finished `release` profile [optimized] target(s) in 0.26s
     Running `target/release/quarto-markdown-pandoc`
Error: Parse error
   ╭─[<stdin>:1:15]
   │
 1 │ {{< print_arg > 10ecquerel >}}
   │               ┬  
   │               ╰── unexpected character or token here
───╯

Error: Parse error
   ╭─[<stdin>:1:20]
   │
 1 │ {{< print_arg > 10ecquerel >}}
   │                    ┬  
   │                    ╰── unexpected character or token here
───╯

versus quoted strings (output not 100% correct but no parsing errors):

❯ echo '{{< print_arg ">" 10 "\becquerel" >}}'  | cargo run --release -p quarto-markdown-pandoc --
    Finished `release` profile [optimized] target(s) in 0.18s
     Running `target/release/quarto-markdown-pandoc`
[ Para [Span ( "" , ["quarto-shortcode__"] , [("data-is-shortcode", "1")] ) [Span ( "" , ["quarto-shortcode__-param"] , [("data-raw", "print_arg"), ("data-value", "print_arg"), ("data-is-shortcode", "1")] ) [], Span ( "" , ["quarto-shortcode__-param"] , [("data-raw", ""), ("data-value", ""), ("data-is-shortcode", "1")] ) [], Span ( "" , ["quarto-shortcode__-param"] , [("data-raw", "10"), ("data-value", "10"), ("data-is-shortcode", "1")] ) [], Span ( "" , ["quarto-shortcode__-param"] , [("data-raw", ""), ("data-value", ""), ("data-is-shortcode", "1")] ) []]] ]%  

To be clear, I'm not behind the design choices made in Quarto. In my opinion, using quotes is not a workaround, it is the correct usage in this case.