Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Escaping $ to interpolate variables in L"..." #27

Closed
jebej opened this issue Nov 25, 2018 · 12 comments · Fixed by #40
Closed

Escaping $ to interpolate variables in L"..." #27

jebej opened this issue Nov 25, 2018 · 12 comments · Fixed by #40

Comments

@jebej
Copy link

jebej commented Nov 25, 2018

Would it make sense (or would it be even possible) to allow "escaping" $, either with a double $$ or something else, to allow interpolation in L"..." strings? It would be convenient instead of having to fall back to using latexstring and needing to escape every $ and \.

@stevengj
Copy link
Member

stevengj commented Nov 26, 2018

It's certainly technically possible, but you'd need to find something that doesn't conflict with LaTeX.

I guess we could use \$, no, that is used for literal dollar signs in LaTeX equations.

@BeastyBlacksmith
Copy link

BeastyBlacksmith commented Oct 31, 2019

Well, you can use $ for interpolate and \ for escaping and writing \$ (in the final LaTeX string) would then be needed to be written as \\\$ (like escaping in the shell). But the L string was intended such, that you don't need to escape \ since it is so common in latex.
So maybe # would be better suited as escape character, then \$ would needed to be written as \#$.

@stillyslalom
Copy link
Contributor

Another option would be extending @sprintf to allow its first argument to be a LaTeXString, with % as the interpolation/formatting character as usual. Compare:

latexstring("an equation: \$ $(round(c[1], digits=3)) + $(round(c[2], digits=3)) \\alpha^2 \$")

vs

@sprintf(L"an equation: $ %0.3f + %0.3f \alpha^2 $", c...)

@stillyslalom
Copy link
Contributor

@sprintf needs a static format string (ref. JuliaLang/julia#29278), so the above syntax wouldn't work. It works as expected with Formatting.format, though:

julia> s1 = L"an equation: $ {:.3f} + {:.3f} \alpha^2 $"
L"an equation: $ {:.3f} + {:.3f} \alpha^2 $"

julia> format(s1, 1, 2)
"an equation: \$ 1.000 + 2.000 \\alpha^2 \$"

@stevengj
Copy link
Member

stevengj commented Jul 8, 2020

You can always just use an ordinary string and backslash-escape any backslashes and dollar signs…

@stillyslalom
Copy link
Contributor

Of course, but I'd prefer to use LaTeXStrings, which are cleaner and more convenient than the backslash-escape alternative. This sort of behavior comes up all the time when creating plot labels/titles/annotations which include calculated coefficients.

@stevengj
Copy link
Member

We could use %$, since that is a comment in LaTeX and is unlikely to appear in normal text, but it is a bit ugly. Any other ideas?

@Moelf
Copy link

Moelf commented Aug 24, 2020

fonsp/Pluto.jl#313

I hit the symptom of this in Pluto when trying to interpolate in md""",

@stillyslalom
Copy link
Contributor

@Moelf I think this is an issue on Markdown's end. You can work around your issue by directly accessing the string field:

julia> using Markdown, LaTeXStrings

julia> ls = L"y = mx + b";

julia> md"$(ls.s)"
"\$y = mx + b\$"

@Moelf
Copy link

Moelf commented Aug 24, 2020

@stillyslalom I don't know what customize the behavior when interpolated in string, but IF it is customizable (and be different from what print does on the type), then it should be customized in LaTeXString not in Markdown right?

@stillyslalom
Copy link
Contributor

@Moelf To avoid the dependence of Markdown.jl (which is a stdlib package) upon LaTeXStrings.jl (which is not), it would need to be implemented here (or in a shim package), but that's entirely distinct from the issue at hand. It's probably best to open a new issue.

@Moelf
Copy link

Moelf commented Aug 25, 2020

I think I mis-read what this issue is about, oops, sry about the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants