# Multichar variables names in docstring LaTeX
**URL:** https://discourse.julialang.org/t/multichar-variables-names-in-docstring-latex/135555
**Category:** General Usage
**Tags:** question, documentation
**Created:** [February 10, 2026, 3:54pm UTC](https://discourse.julialang.org/t/multichar-variables-names-in-docstring-latex/135555 "2026-02-10T15:54:57Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [February 10, 2026, 3:54pm UTC](https://discourse.julialang.org/t/multichar-variables-names-in-docstring-latex/135555/1 "2026-02-10T15:54:57Z")
What’s the recommended way to include a multi-character function or argument name in the LaTeX/math part of a docstring? `\text`, `\mathrm`, or something else?
MWE:
```julia
@doc """
Test if ``x \\le \\text{abstol}``.
"""
is_done(x, abstol) = abs(x) ≤ abstol
```
---
### Author:  [@Ralph\_Smith](https://discourse.julialang.org/u/Ralph_Smith)
#### Post date: [February 10, 2026, 8:35pm UTC](https://discourse.julialang.org/t/multichar-variables-names-in-docstring-latex/135555/2 "2026-02-10T20:35:35Z")
The LaTeX Companion states that `\mathit` is appropriate for such “full-word variable names” and the like, whereas `\mathrm` is good for operators and `\text` for “normal text” inside mathematical constructs. If you generate a PDF with Documenter you can see whether this advice fits your taste.
---
### Author:  [@kellertuer](https://discourse.julialang.org/u/kellertuer)
#### Post date: [February 11, 2026, 1:13am UTC](https://discourse.julialang.org/t/multichar-variables-names-in-docstring-latex/135555/3 "2026-02-11T01:13:28Z")
I am not sure what the recommended way is, but I read your string as: The first part is math, the second (the `abstol`) is code, so I would write it like exactly that mix, e.g.
```julia
@doc """
Test if ``x ≤ `` `abstol`.
"""
```
(I think it should even work without the space between math and code)
If you feel that this is too much of a mix, one could also maybe write
```julia
@doc """
Test if ``x ≤ ε_{\\mathrm{abs}} ``, where ``ε_{\\mathrm{abs}}`` is the `abstol` keyword.
"""
```
though that is a bit longer, it makes the split between math and code names a bit clearer.
What I find a bit hard is to find a good balance between “renders nice in docs” and “is readable on REPL”, so I use UTF8 characters for example.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [February 11, 2026, 8:01am UTC](https://discourse.julialang.org/t/multichar-variables-names-in-docstring-latex/135555/4 "2026-02-11T08:01:06Z")
> [@kellertuer](#):
>
> What I find a bit hard is to find a good balance between “renders nice in docs” and “is readable on REPL”, so I use UTF8 characters for example.
It would be great if REPL printing could just elide `\text` etc, eg within the entry point [`Markdown.plain(::IO, ::LaTeX)`](https://github.com/JuliaLang/julia/blob/defde64779afcabad6d62c140fa2a06651e4ac8e/stdlib/Markdown/src/render/plain.jl#L105), but I guess that would require parsing LaTeX, at least to a certain extent. Cf
>
>
> Right now, if a docstring contains LaTeX math, it renders nicely in HTML, but in… the REPL help system, the raw TeX source is shown.
>
> Couldn't the translation describe in \`latex\_symbols\` from \`stdlib/REPL/src/latex\_symbols.jl\` be applied to Markdown docstrings, too?
>
> This would require accessing that code from \`stdlib/Markdown\`, which then would have to access \`REPL\`, or else that translation code would have to be factored out into a separate place. I believe one would want to perform some more transformations, too (e.g. map \`\\mathbb{Z}\` to \`\\bbZ\`).
>
> It might also not look great in all cases, so perhaps an option for docstring authors to somehow opt-out of this translation for certain docstrings might be necessary?
---
### Author:  [@kellertuer](https://discourse.julialang.org/u/kellertuer)
#### Post date: [February 11, 2026, 8:09am UTC](https://discourse.julialang.org/t/multichar-variables-names-in-docstring-latex/135555/5 "2026-02-11T08:09:34Z")
That would indeed be great and resolve most of balancing I currently try. Thanks for linking that Issue!