On the expression $ .. $

[jxxcarlson]

(1) When we have the new parser, let's see if in latex mode we can parse /$.*$/m as an "inline-latex-expression" or some such. That is, text beginning and ending with $ would be so parsed even if it extended over a line break. This would prevent a common rendering error in Asciidoctor-LaTeX where there is such a line break.

(2) I suggest that the switch / attribute for using $ as a delimiter be :latex: (Then when talking money, one must say \$100).

(3) With :latex: on, there are other conventions to be followed, e.g., (a) \_ for _, (b) \% for %, (c) \& for &. I'll compile a list of these and I welcome help on it!

[mojavelinux]

I definitely want to make the environment as comfortable as possible for those familiar with LaTeX and using LaTeX notations, but I think we need to address this carefully so that we can honor AsciiDoc compatibility in a very predictable way. I think if we use a proper inline parser, we'll have a lot more context and therefore able to handle these cases much more intelligently. In other words, we should be able to infer the author's intent a lot better and do the right thing. But we want to be careful about making AsciiDoc documents with :latex: enabled something other than AsciiDoc.

[jxxcarlson]

(reply in Asciidoc)

Agreed. I would suggest the following. First, let’s define valid Asciidoc-LaTeX text as valid Asciidoc text with the addition of four constructs

• $ LATEX $

• \[ LATEX \]

• chem:[LATEX] -- see note at end

• Environments:

  +

  [env.FOO] —

  ASCIIDOC-LATEX

  ---

  and with the proviso that in Asciidoc text, $ must be written as \$ unless it is meant as a LaTeX delimiter (compare: $..$ for LaTeX and

+

..

for code). Thus outside of these four constructs, there is only one change, from strict Asciidoc, namely the use of \$.

It is important that the body of an environment block can be Asciidoc-LaTeX, not simply Asciidoc or LaTeX. For example:

---

[env.theorem]

If $p$ is prime, then $a^{p-1} \cong 1$ modulo $p$, provided that $p$ does

not divide $a$.

---

NOTE: This means that the body of an environment block should be parsed. This is not currently the case. If this can be done (??), then one could, for example have a normal Asciicdoc list inside an [env.theorem] block ... the beast is now recursive.

Once we have a parser that can distingush between being “inside” or “outside” of LaTeX, I believe that we can proceed as follows:

. HTML back end. Outside of LaTeX, map $ back to $. Inside: pass through or handle environment or inline construct such as `chem:[..]``. We won't have to worry about substitutions messing things up.

. LaTeX backend. Inside of LaTeX, let LaTeX do its thing. Outside of LaTeX one must .. not change $ .. map # to # .. map % to % .. map & to & .. handle ^: there are several contexts, each of which must be treated separately. For example, Asciidoc

+

"a^2^"

meaning a-squared is one thing, whereas "he said that ^ signifies a control character" is another. .. handle _: again, several contexts, e.g.,

"this is emphatic text" + versus "foo_bar is is nonsense."

There may be other characters to handle, and the treatment of #, %, and & may be more complex than just making a substitution ... to be cogitated upon.

A couple of questions:

. Is the definition of Asciidoctor-LaTeX satisfactory -- both as a definition in se and as proposals that preserves the identity and integrity of Asciidoc?

. Is the proposed (very general) way of handling Asciidoctor-LaTeX at the backend both satisfactory and workable?

.About chem:[..] This construct allows one to say chem:[H2O] or chem:[CO2]. See http://www.noteshare.io/section/a-sample-document#_chemistry[chemistry] . These expressions call upon a chemistry tex macro package.

Jim

http://noteshare.io http://noteshare.io/ http://home.noteshareblog.io http://home.noteshareblog.io/

On Jun 5, 2015, at 5:10 PM, Dan Allen [email protected] wrote:

I definitely want to make the environment as comfortable as possible for those familiar with LaTeX and using LaTeX notations, but I think we need to address this carefully so that we can honor AsciiDoc compatibility in a very predictable way. I think if we use a proper inline parser, we'll have a lot more context and therefore able to handle these cases much more intelligently. In other words, we should be able to infer the author's intent a lot better and do the right thing. But we want to be careful about making AsciiDoc documents with :latex: on something other than AsciiDoc.

— Reply to this email directly or view it on GitHub https://github.com/asciidoctor/asciidoctor-latex/issues/35#issuecomment-109441701.