Skip to content

wrong comment display (when sent by email) #32

Open

Description

@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.

Activity

  1. danielchatfield commented on Nov 17, 2014

    @danielchatfield
    Contributor

    Can you paste the raw email text.

  2. ousia commented on Nov 17, 2014

    @ousia
    Author

    @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
    
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions