Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

title variable should not be interpreted as block element #1685

Closed
nichtich opened this issue Oct 12, 2014 · 4 comments
Closed

title variable should not be interpreted as block element #1685

nichtich opened this issue Oct 12, 2014 · 4 comments

Comments

@nichtich
Copy link
Contributor

The title variable (and similar "inline-value" variables) should never be interpreted as block element. Try this example:


---
title: "6. conference"
...
report

converted with pandoc -s -t latex the output contains:

\title{\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{5}
\itemsep1pt\parskip0pt\parsep0pt
\item
  conference
\end{enumerate}}

instead of \title{6. conference}. I stumbled upon this because 5. xxx in German is used like 6th xxx in English. Similar for unnumbered lists:


---
title: "* is a star"
...
@jgm
Copy link
Owner

jgm commented Oct 13, 2014

I realize that this is confusing, but let me explain why it happens.
Pandoc treats all fields in YAML blocks as potentially containing
block-level content. Clearly this is desirable in general; an abstract,
for example, might contain a list. You can avoid the undesirable
behavior in your case by using backslash escapes, e.g. 6\. conference.

It might be worth considering giving the title field special
treatment, since it does have a special role in some document formats,
and has a place in all of the default templates. However, I'm also
worried about confusing matters by treating some fields differently
from others (so that users have to know which field gets treated in which
way).

Not sure what the best solution is, but it might be worth raising this
for discussion on pandoc-discuss.

+++ Jakob Voss [Oct 12 14 13:54 ]:

The title variable (and similar "inline-value" variables) shoudl not be interpreted as items. Try this example:

---
title: "6. conference"
...
report

converted with pandoc -s -t latex the output contains:

\title{\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\setcounter{enumi}{5}
\itemsep1pt\parskip0pt\parsep0pt
\item
 conference
\end{enumerate}}

instead of \title{6. conference}. I stumbled upon this because 5. xxx in German is used like 6th xxx in English. Similar for unnumbered lists:

---
title: "* is a star"
...

Reply to this email directly or view it on GitHub:
#1685

@nichtich
Copy link
Contributor Author

Ok, it makes sense to treat all metadata fields as Markdown block-level content. Then I'd need an easy way to convert this YAML fields between different formats, especially from/to plain Unicode strings. For instance from

---
title: "6\\. <html> congress"
...

to (plain)

---
title: "6. <html> congress"
...

or (latex)

---
title: "6. \\textless{}html\\textgreater{} congress"
...

Some kind of --yaml-fields flag in pandoc may help to only convert field values in YAML blocks instead of (or in addition to) the sourrinding Markdown text. Another idea is a --yaml-format option to explicitly set the format field values are expected in.

@nichtich nichtich mentioned this issue Oct 26, 2014
Closed
@mpickering
Copy link
Collaborator

I don't understand why you need the conversion to latex for example?

@jgm jgm closed this as completed Mar 5, 2017
@nichtich nichtich mentioned this issue Mar 6, 2017
Closed
@nichtich
Copy link
Contributor Author

nichtich commented Mar 6, 2017

This has partly been solved by introduction of meta-json but there is still a bug (#3492) and a possible feature request (better to be discussed in the mailing list).

jgm added a commit that referenced this issue Mar 6, 2017
@jgm
Markdown writer: Fixed false ordered lists in YAML metadata.
13698e7 
Now we properly escape things that would otherwise start ordered
lists, such as

    ---
    title: 1. inline
    ...

Closes #3492.
Closes #1685.
@jgm jgm mentioned this issue Mar 12, 2017
Closed
@Wandmalfarbe Wandmalfarbe mentioned this issue Jun 29, 2019
Closed
@mfhepp mfhepp mentioned this issue Feb 23, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jgm @nichtich @mpickering