HackerTrans
TopNewTrendsCommentsPastAskShowJobs

fiddlosopher

no profile record

comments

fiddlosopher
·5 mesi fa·discuss
The web app can be found at https://pandoc.org/app . This has almost the full power of the command-line app, subject to the limitations imposed by the WASM sandbox. Thus:

- the app cannot fetch resources using HTTP

- JSON filters are not supported, as they involve external programs

- Lua filters are supported, but only if they don't try to do system IO operations or run external programs

- Output to PDF is supported only via Typst (using the WASM version of Typst).
fiddlosopher
·6 mesi fa·discuss
Pandoc does know how to expand LaTeX macros. For example, given the LaTeX

  \newcommand{\pair}[2]{\langle #1, #2\rangle}
  $$\pair{a^2}{\frac{\pi}{2}}$$
pandoc will give you the Typst

  $ chevron.l a^2 \, pi / 2 chevron.r $
which is correct. Tylax, on the other hand, seems to have problems with this example, producing

  $ angle.l^()frac(pi,)angle.r  $
which does not compile with typst. Going the other direction, pandoc also understands typst scripting. For example, from

  #let count = 8
  #let nums = range(1, count + 1)
  #let fib(n) = (
    if n <= 2 { 1 }
    else { fib(n - 1) + fib(n - 2) }
  )

  The first #count numbers of the sequence are:

  #align(center, table(
    columns: count,
    ..nums.map(n => $F_#n$),
    ..nums.map(n => str(fib(n))),
  ))
pandoc produces this LaTeX:

  The first 8 numbers of the sequence are:

  {\def\LTcaptype{none} % do not increment counter
  \begin{longtable}[]{@{}llllllll@{}}
  \toprule\noalign{}
  \endhead
  \bottomrule\noalign{}
  \endlastfoot
  \(F_{1}\) & \(F_{2}\) & \(F_{3}\) & \(F_{4}\) & \(F_{5}\) & \(F_{6}\) &
  \(F_{7}\) & \(F_{8}\) \\
  1 & 1 & 2 & 3 & 5 & 8 & 13 & 21 \\
  \end{longtable}
  }
With the same input, Tylax produces:

  The first 8 numbers of the sequence are:

  \begin{center}

  \begin{tabular}{|c|}
  \hline
  \hline
  \end{tabular}\end{center}
which is just an empty table.
fiddlosopher
·4 anni fa·discuss
The motivation for this choice is not "convenient parsing" but deeper considerations of language design. As explained at https://github.com/jgm/djot#rationale , this choice follows from two desiderata: (1) "The syntax should compose uniformly, in the following sense: if a sequence of lines has a certain meaning outside a list item or block quote, it should have the same meaning inside it." (2) "The syntax should be friendly to hard-wrapping: hard-wrapping a paragraph should not lead to different interpretations, e.g. when a number followed by a period ends up at the beginning of a line." The document explains the compromise we made in commonmark to avoid the need for blank lines. Djot tries to be more principled.
fiddlosopher
·14 anni fa·discuss
I, too, would be strongly against "automatic return-based linebreaks." Given that markdown has constructions for lists and code blocks, one very rarely needs a hard line break anyway. Currently markdown works fine both for people who hard-wrap and people who soft-wrap. Let's keep it that way.
fiddlosopher
·14 anni fa·discuss
[lunamark](https://github.com/jgm/lunamark/tree/master/lunamark) is another PEG-based implementation.