wrong comment display (when sent by email)

[ousia]

I have just realized that GitHub displays wrong the comments that have been sent by email.

One sample would be jgm/pandoc#1765 (comment). I received the email message and only the first paragraph should be displayed as a comment (it contains the required > in the message). The other two paragraphs are the actual reply (they aren’t formatted as comments in the email message).

Another sample is jgm/pandoc#1612 (comment). In that case, the paragraphs after the last shown without expansion are considered comments. The original message has no comments in that paragraphs.

I think this is an important issue. Otherwise it is really hard to make a distinction between what has been replied and which the reply itself is.

[danielchatfield]

Can you paste the raw email text.

[ousia]

@danielchatfield, these are the raw email texts:

+++ Tom Brewe [Nov 15 14 10:34 ]:<br>
&gt;Although I have set `mainlang=german` (or ngerman), the table of contents still renders as *Contents* instead of *Inhaltsverzeichnis*<br>
&gt;Same for figures (*figure* instead of *Abbildung*)<br>
&gt;I am using xelatex as latex engine. Is there anything I am missing?<br>
&gt;Can I overwrite the strings in the template if it doesn&#39;t work natively?<br>
<br>
There is nothing in the template that says &quot;Contents&quot; -- that is<br>
generated by xelatex itself.  This seems to be a LaTeX issue; I am<br>
not sure what is going on.  (I assume you&#39;re using an up-to-date<br>
version of pandoc?)<br>
<br>
Try creating a simple latex file (`pandoc -s -t latex -o my.tex --toc`)<br>
and then compiling it manually with xelatex.  If the latex looks right<br>
to you, and the answer isn&#39;t revealed by xelatex&#39;s error log, then<br>
you might try on tex stack exchange.

On Oct 18, 2014, at 11:58 AM, Pablo Rodr=C3=ADguez <notifications@github.=
com> wrote:
> Given the default header ID names, you could just use "TOC" as the head=
er, although in that case, you may want the TOC section title to be empty=
.
> =

> Your method is simpler, but if the user wants to have the title specifi=
ed in the YAML metadata, it has to be typed again. If the title changes (=
what is often the case when you=E2=80=99re writting a book), it has to be=
 replaced twice. I think this should be avoided.
> =

> A compromise solution would be to repeat the title from YAML metadata w=
ith the following:
> =

> # toc {#toc}
Well, the IDs are not case sensitive as I recall, so that is equivalent t=
o

    # toc

since Pandoc will give it the ID of "#toc". I used #TOC since that's the =
ID pandoc assigns to the section it generates.

Anyway, I think that the compromise sounds good. There could be a YAML va=
riable, perhaps, "toc-title" that sets the title (if present) in the case=
 where you just name the section "toc" or "TOC":

---
toc-title: Contents
...

# toc

# Section 1

[...]

eqivalent to:

# Contents {#toc}

# Section 1

[...]

> If you decided that the generated TOC would replace any Markdown conten=
t in this section, this could actually allow you to manually make a TOC i=
n the source file for plain text readability (which you would have to mai=
ntain) that would get replaced with the hyperlinked one:
> =

> [I must confess I=E2=80=99m not sure I get it.]
> =

> Do you really think that it makes sense to write a table of content tha=
t doesn=E2=80=99t get in the final document?
> =


I worded that a wrong when I said "which you would have to maintain". You=
 wouldn't have to manually edit that section; you would manually run pand=
oc to make a new markdown version where it replaced that section with the=
 new markdown toc text. It's probably not worth it since you'd have to ru=
n pandoc to convert your markdown file to a markdown file and give severa=
l options depending on your preferences in order to not change the style:=


    pandoc -s --toc --to=3Dmarkdown --atx-headers myfile.md -o myfile.md

Currently, Pandoc will insert the generated toc content into a section wi=
th the ID of #toc now, but for markdown format output, it doesn't get put=
 into a section like with HTML. =


For example, the source:

# Section 1

Some stuff.

# Section 2

More stuff.

If you could designate the toc section and that section's content was rep=
laced with the generated toc content, you could output to markdown format=
 and Pandoc would put the toc in that section with the #toc ID, and that =
markdown source could be run back through Pandoc again to get the toc con=
tent updated without duplicating the toc in the resulting output. =


For the example source, ` pandoc --toc -s --to=3Dmarkdown --atx-headers` =
might output:

# toc

-   Section 1
-   Section 2

# Section 1

Some stuff.

# Section 2

More stuff.

Then, if we edit this file and add a section 3:

# Section 3

Yet more stuff.

then outputs with `--toc` would replace the "# toc" section with the upda=
ted content, with the markdown version becoming:

# toc

-   Section 1
-   Section 2
-   Section 3

# Section 1

Some stuff.

# Section 2

More stuff.

# Section 3

Yet more stuff.

rather than duplicating the toc as it would now. =


We could use this as our new source file if we wanted. The benefit here w=
ould be having a readable toc at the top that we wouldn't have to manuall=
y update or remove when we edit the file. In other words, at this point, =
passing the result again through `pandoc --toc -s --to=3Dmarkdown --atx-h=
eaders` repeatedly would result in the same output.

Also, the toc section could also be removed if the --toc option is not us=
ed.

As you mention, you could also have the toc section title set from a YAML=
 variable like, say, "toc-title" as well.

This part was just a little idea that your original post made me think of=
 and now seems like it's not really that useful for the work involved.

-Ryan