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.

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

markdown_github list issues #1137

Closed
laktak opened this issue Feb 3, 2014 · 13 comments
Closed

markdown_github list issues #1137

laktak opened this issue Feb 3, 2014 · 13 comments
Labels

Comments

@laktak
Copy link

laktak commented Feb 3, 2014

I am trying to define an itemsep in the latex template.

The output however will always contain

\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
  AA
\item
  BB
\end{itemize}

which overwrites my template (AFAIK - I'm no latex expert).

Is it possible to modify the itemsep1pt value?

@jgm
Copy link
Owner

jgm commented Feb 3, 2014

You could try redefining the \itemsep1pt macro in your
header. Haven't tried this, though.

+++ Christian Zangl [Feb 03 14 02:38 ]:

I am trying to define an itemsep in the latex template.

The output however will always contain

\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
  AA
\item
  BB
\end{itemize}

which overwrites my template (AFAIK - I'm no latex expert).

Is it possible to modify the itemsep1pt value?


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

@jgm
Copy link
Owner

jgm commented Feb 3, 2014

Note also: there is a distinction in markdown btw "tight" and
"loose" lists. If you put blank lines between your list items
you'll get a loose list, without the itemsep.

+++ Christian Zangl [Feb 03 14 02:38 ]:

I am trying to define an itemsep in the latex template.

The output however will always contain

\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
  AA
\item
  BB
\end{itemize}

which overwrites my template (AFAIK - I'm no latex expert).

Is it possible to modify the itemsep1pt value?


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

@laktak
Copy link
Author

laktak commented Feb 3, 2014

You could try redefining the \itemsep1pt macro in your header. Haven't tried this, though.

Could you give me a hint on how I can do that?

I am trying to remove the spacing between the lines so that it resembles the GFM used here.

E.g.

  • AA
  • BB
  • CC

In the pandoc pdf output it looks more like this:

  • AA
  • BB
  • CC

Is there another variable that's controls this (besides \itemsep1pt\parskip0pt\parsep0pt)?

@jgm
Copy link
Owner

jgm commented Feb 3, 2014

If you don't put blank lines between your list items, they should appear tightly packed together in PDF output. Here's a screenshot of what I get from

- AA
- BB
- CC

2014-02-03-130114_176x228_scrot

@laktak
Copy link
Author

laktak commented Feb 4, 2014

That's strange because I get a different output using pandoc.exe -f markdown_github -s sample.md -o sample.pdf

pandoc -v says pandoc 1.12.3

I've pushed the input/output here: https://gist.github.com/laktak/8799487

Do I need a special TeX/LaTeX? I am using this one: http://miktex.org

@jgm
Copy link
Owner

jgm commented Feb 4, 2014

Aha - it happens with -f markdown_github but not -f markdown.
And I think I see why -- with markdown_github, pandoc is inserting a LineBreak element after each list item:

% pandoc -f markdown_github -t native               
- one
- two

[BulletList
 [[Plain [Str "one",LineBreak]]
 ,[Plain [Str "two"]]]]

This is evidently because of the hard_line_breaks extension, though obviously this is a bug.

@laktak
Copy link
Author

laktak commented Feb 4, 2014

Ah, OK. A fix would be greatly appreciated :)

Is this also the cause for the other issue in the sample?

FooBar

  • AA

    Test

vs.

  • AA

Test

@jgm
Copy link
Owner

jgm commented Feb 4, 2014

No, the other issue has to do with the fact that pandoc (even with
markdown_github) requires a 4-space indent for nested lists.

+++ Christian Zangl [Feb 04 14 11:08 ]:

Ah, OK. A fix would be greatly appreciated :)

Is this also the cause for the other issue in the sample?

FooBar

  • AA

    Test

vs.

  • AA

Test


Reply to this email directly or view it on GitHub:
#1137 (comment)

@laktak
Copy link
Author

laktak commented Feb 5, 2014

It would be great if you could fix both issues. I'd offer to help but my knowledge of Haskell is ~0.

@jgm
Copy link
Owner

jgm commented Feb 5, 2014

The list indentation issue is not likely to be fixed in the near
term. Every markdown implementation seems to handle this slightly
differently (and usually not very consistently). So you may just
have to make sure you obey the "four-space rule" when writing your
github content.

+++ Christian Zangl [Feb 05 14 07:04 ]:

It would be great if you could fix both issues. I'd offer to help but
my knowledge of Haskell is ~0.


Reply to this email directly or [1]view it on GitHub.
[3044__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNzE0NTQ4MSwi
ZGF0YSI6eyJpZCI6MjQ3OTk3NjN9fQ==--51047eddb5bfece18bf6c213fecc6330bd904
d55.gif]

References

  1. markdown_github list issues #1137 (comment)

@laktak
Copy link
Author

laktak commented Feb 6, 2014

Well the content is already written so I guess I have to write a preprocessor to fix this ... however I'd welcome a common markdown standard too.

@jgm
Copy link
Owner

jgm commented Feb 6, 2014

+++ Christian Zangl [Feb 06 14 01:17 ]:

Well the content is already written so I guess I have to write a
preprocessor to fix this ... however I'd welcome a common markdown
standard too.

Working on that!

@aguynamedloren
Copy link

+1 seeing this as well with GFM. I can just hack around it in the meantime.

Thanks for all your awesome work on pandoc, @jgm!

@jgm jgm added the bug label Jun 20, 2014
@jgm jgm closed this as completed in 56c410e Jun 20, 2014
myrdd referenced this issue in RequestPolicyContinued/RequestPolicyContinued.github.io Jul 2, 2015
jgm added a commit that referenced this issue Aug 19, 2017
Closes #3511.

Previously pandoc used the four-space rule: continuation paragraphs,
sublists, and other block level content had to be indented 4
spaces.  Now the indentation required is determined by the
first line of the list item:  to be included in the list item,
blocks must be indented to the level of the first non-space
content after the list marker. Exception: if are 5 or more spaces
after the list marker, then the content is interpreted as an
indented code block, and continuation paragraphs must be indented
two spaces beyond the end of the list marker.  See the CommonMark
spec for more details and examples.

Documents that adhere to the four-space rule should, in most cases,
be parsed the same way by the new rules.  Here are some examples
of texts that will be parsed differently:

    - a
      - b

will be parsed as a list item with a sublist; under the four-space
rule, it would be a list with two items.

    - a

          code

Here we have an indented code block under the list item, even though it
is only indented six spaces from the margin, because it is four spaces
past the point where a continuation paragraph could begin.  With the
four-space rule, this would be a regular paragraph rather than a code
block.

    - a

            code

Here the code block will start with two spaces, whereas under
the four-space rule, it would start with `code`.  With the four-space
rule, indented code under a list item always must be indented eight
spaces from the margin, while the new rules require only that it
be indented four spaces from the beginning of the first non-space
text after the list marker (here, `a`).

This change was motivated by a slew of bug reports from people
who expected lists to work differently (#3125, #2367, #2575, #2210,
 #1990, #1137, #744, #172, #137, #128) and by the growing prevalance
of CommonMark (now used by GitHub, for example).

Users who want to use the old rules can select the `four_space_rule`
extension.

* Added `four_space_rule` extension.
* Added `Ext_four_space_rule` to `Extensions`.
* `Parsing` now exports `gobbleAtMostSpaces`, and the type
  of `gobbleSpaces` has been changed so that a `ReaderOptions`
  parameter is not needed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants