Support diacritics (accents, ...)

[t-bltg]

• handle diacritics in a consistent manner, using escape sequences from https://en.wikibooks.org/wiki/LaTeX/Special_Characters#Escaped_codes.

julia> using Latexify
julia> latexify("éçà")
L"$\textrm{\'{e}}\textrm{\c{c}}\textrm{\`{a}}$"

• support QuoteNode in latexraw (e.g. when parsing "Plots.jl" as expr, corner case);
• add latexify docstring for help?> latexify;
• add failing expr error message when parsing fails;
• added a parse keyword to _latexraw, since Meta.parse can fail (especially parsing string containing diacritric markers - strings are normalized), and dispatch on Val{true/false} to Meta.parse or not.

Fix #182.
Goes with JuliaPlots/Plots.jl#4262.

[codecov]

Codecov Report

Merging #223 (bf1f534) into master (8b860d3) will decrease coverage by 0.66%.
The diff coverage is 65.11%.

@@            Coverage Diff             @@
##           master     #223      +/-   ##
==========================================
- Coverage   63.84%   63.18%   -0.67%     
==========================================
  Files          23       23              
  Lines         838      861      +23     
==========================================
+ Hits          535      544       +9     
- Misses        303      317      +14     

Impacted Files	Coverage Δ
src/latexify_function.jl	74.19% <ø> (ø)
src/unicode2latex.jl	69.49% <53.33%> (-20.26%)	⬇️
src/latexraw.jl	91.04% <87.50%> (+0.41%)	⬆️
src/macros.jl	100.00% <100.00%> (ø)
src/utils.jl	25.27% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8b860d3...bf1f534. Read the comment docs.

[gustaphe]

Hi! Thank you for the contribution, this looks like a good idea, but I haven't done a proper review yet.

However, I feel the need to comment on your workflow. You seem to be force-pushing a lot. That's a pretty extreme measure, and makes it difficult to follow your history. Please make successive commits rather than amending a single commit and force-pushing it. I'm certain most repos will agree with this.

[t-bltg]

Hi! Thank you for the contribution, this looks like a good idea, but I haven't done a proper review yet.

Thanks, I think this can be reviewed in a few moments.

You seem to be force-pushing a lot. That's a pretty extreme measure, and makes it difficult to follow your history.

Pushing a lot of commits is certainly a bad idea too. I can rebase this PR though, to make things clearer.

[gustaphe]

I would certainly prefer several commits over a constantly changing history. If your want to cause fewer commits, consider simply pushing less often.

[t-bltg]

Rebased for clarity. The last commit is optional and can be removed if required.

[t-bltg]

@gustaphe, would it be possible to review (and merge this PR / bump ver iff approved) so that it does not block JuliaPlots/Plots.jl#4262 ?

[gustaphe]

I disagree with the choice of making all of these \textrm. If a character in math mode is supposed to be romanized, then that should be a property of the variable it signifies, not its spelling. To me it's better to get an Command \" invalid in math mode error than have it silently put some characters in roman.

[t-bltg]

Thanks for the detailed review: I've tried to answer all the comments.

I disagree with the choice of making all of these \textrm. If a character in math mode is supposed to be romanized, then that should be a property of the variable it signifies, not its spelling. To me it's better to get an Command " invalid in math mode error than have it silently put some characters in roman.

I'm not sure I'm following you here: the point of latexify is to render an equation isn't it ? The only way (if I'm not misunderstanding, and without loading extra packages) to have latex compile accentuated characters in equations is to use \textrm ?

[korsbo]

This is a very well-constructed PR with good code quality and with tests. Thank you!

As to the above discussion about \textrm, I prefer this approach to having the LaTeX compiler throw. I see your point @gustaphe, that form can convey meaning and that silently changing this form might cause subtly incorrect output. But the pragmatist in me thinks that Latexify.jl is probably more used in less formal settings where just producing a reasonable output trumps this consideration of form. I think the balancing act is between opting for correctness for someone writing a paper and opting for stability for some package that relies on latexify to produce LaTeX that compiles. I have no way of knowing this for sure, but I think that the latter scenario is far more common, so I'm inclined to tilt in that direction.

[gustaphe]

That may be right. My objection is exemplified in this hypothetical: say I define a type

struct TextSub
var::String
sub::String
end

@latexrecipe function f(x::TextSub)
    return Expr(:latexifymerge, 
        x.var, 
        "_\textrm{", 
        x.sub, 
        "}"
    )
end

(Possible misspellings, I'm on my phone traveling)

This is how I would use anything where I expected romanized text, and so anything where I would expect ä to print correctly. But if some characters are always surrounded by textrm, this becomes difficult to do.

There is precedent for using kwargs to introduce formatting commands on demand, could that be the solution here?

That said, maybe this is an inconsequential objection. I'll survive.

[t-bltg]

I fail to understand how your example shows a valid point since it doesn't compile: latexifymerge returns an equation, so escape sequences are invalid in this tex mode.

using Latexify

struct TextSub
  var::String
  sub::String
end

@latexrecipe f(x::TextSub) = return Expr(:latexifymerge, x.var, raw"_\textrm{", x.sub, "}")

main() = begin
  fn = tempname()
  write(
    fn, """
    \\documentclass{standalone}
    \\begin{document}
      $(latexify(:($(TextSub("é", "ç")) + $(TextSub("c", "123")))))
    \\end{document}
    """
  )
  run(`latexmk -quiet -pdf $fn`)
  return
end

main()

with PR

Rc files read:
  NONE
Latexmk: Run number 1 of rule 'pdflatex'
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
Latexmk: Getting log file 'jl_qMW3dH.log'
  0.701773 seconds (3.62 k allocations: 267.109 KiB)

without PR

Rc files read:
  NONE
Latexmk: Run number 1 of rule 'pdflatex'
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
Latexmk: Getting log file 'jl_WXLw8J.log'
Collected error summary (may duplicate other messages):
  pdflatex: Command for 'pdflatex' gave return code 1
      Refer to 'jl_WXLw8J.log' for details
Latexmk: If appropriate, the -f option can be used to get latexmk
  to try to force complete processing.
ERROR: failed process: Process(`latexmk -quiet -pdf /tmp/jl_WXLw8J`, ProcessExited(12)) [12]

I understand your concerns about textrm, but I would argue that this is a design issue of Latexify rather than a problem with this PR.

[t-bltg]

@korsbo or @gustaphe, if no more objections, would it be possible to go forward on this PR ?

[t-bltg]

Thanks ! Don't hesitate to ping me if any issue pops up related to this PR.