Markdown writer ignores backtick_code_blocks?

Markdown writer ignores backtick_code_blocks?

[Allen Downey]

[-- Attachment #1.1: Type: text/plain, Size: 1071 bytes --]

Hi All.  I am using pandoc 2.11 with the following test input:

```
Paragraph

\begin{verbatim}
Code block
Code block
\end{verbatim}

Paragraph
```

Then I translate to Markdown with the following commands:

```
pandoc test.tex -t markdown > test1.md
pandoc test.tex -t markdown+fenced_code_blocks > test2.md
pandoc test.tex -t markdown+backtick_code_blocks > test3.md
```

The result of all three is the same:

```
Paragraph

    Code block
    Code block

Paragraph
```

The code block is indented, which implies that the reader recognizes it as 
a code block.  But the writer seems to ignore the extensions.

Am I doing something wrong here?

Thanks!
Allen

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/3001f072-a5fb-450a-9f8c-ba901a31b3c1n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1860 bytes --]

Re: Markdown writer ignores backtick_code_blocks?

[John MacFarlane]

The + notation enables an extension.  That just makes it an
OPTION for the writer.  In this case it doesn't do anything,
since fenced_code_blocks and backtick_code_blocks are
already enabled for markdown by default.

Having these enabled tells the writer that it CAN use either
tildes or backticks for a code block (as well as indentation,
which is a core Markdown feature and thus has no extension).
But it doesn't tell it which form to use.  The writer will
prefer indented code blocks when there are no attributes
specified (mainly because it has to choose one form, and
this is the most compatible form).

What you'd need would be -indented_code_blocks, but as
I said, that's not an extension because it's a core feature.

This issue comes up a lot and there's an issue for it in the
tracker:
https://github.com/jgm/pandoc/issues/5280

It would be good to give people more control over the priorities
used for the different syntax possibilities in markdown output,
but I haven't figured out what the best way to do it would be.
In addition to code blocks, similar issues arise for

- bullet types (+, -, or *)
- list indentation (4-space or less)?
- headings (setext or atx)
- tables (prefer pipe tables or simple?)
- links (prefer reference or inline?)

In the case of headings we have the --markdown-headings option.
For links we have --reference-links (which also affects some
other formats). But I don't know if I want to go down the path of
introducing six more command-line options.



Allen Downey <allendowney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> Hi All.  I am using pandoc 2.11 with the following test input:
>
> ```
> Paragraph
>
> \begin{verbatim}
> Code block
> Code block
> \end{verbatim}
>
> Paragraph
> ```
>
> Then I translate to Markdown with the following commands:
>
> ```
> pandoc test.tex -t markdown > test1.md
> pandoc test.tex -t markdown+fenced_code_blocks > test2.md
> pandoc test.tex -t markdown+backtick_code_blocks > test3.md
> ```
>
> The result of all three is the same:
>
> ```
> Paragraph
>
>     Code block
>     Code block
>
> Paragraph
> ```
>
> The code block is indented, which implies that the reader recognizes it as 
> a code block.  But the writer seems to ignore the extensions.
>
> Am I doing something wrong here?
>
> Thanks!
> Allen
>
> -- 
> You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/3001f072-a5fb-450a-9f8c-ba901a31b3c1n%40googlegroups.com.

RE: Markdown writer ignores backtick_code_blocks?

[Zev Spitz]

[-- Attachment #1: Type: text/html, Size: 8933 bytes --]

Re: Markdown writer ignores backtick_code_blocks?

[Daniel Staal]

On 1/24/21 1:07 PM, John MacFarlane wrote:
> It would be good to give people more control over the priorities
> used for the different syntax possibilities in markdown output,
> but I haven't figured out what the best way to do it would be.
> In addition to code blocks, similar issues arise for
> 
> - bullet types (+, -, or *)
> - list indentation (4-space or less)?
> - headings (setext or atx)
> - tables (prefer pipe tables or simple?)
> - links (prefer reference or inline?)
> 
> In the case of headings we have the --markdown-headings option.
> For links we have --reference-links (which also affects some
> other formats). But I don't know if I want to go down the path of
> introducing six more command-line options.

Someone else suggested Lua filters - which sounds like overkill to me 
and more work for users than needed.

My suggestion would be a preferences/defaults file, with options. 
Create one command-line option to specify a different preference file 
than the normal (if someone wants to override), but otherwise look in a 
defined location set and read an .ini file or similar.  If you want to 
be fancy allow includes so that one file can reference another and 
override parts of it, but that's really just a flourish on top.

Daniel T. Staal

-- 
---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------

Re: Markdown writer ignores backtick_code_blocks?

[Allen Downey]

[-- Attachment #1.1: Type: text/plain, Size: 2447 bytes --]

I agree that it would be nice to be able to do this from the command line, 
but in the meantime I will look into doing it with filters.  Thank you!

On Monday, January 25, 2021 at 10:54:41 AM UTC-5 DSt...-Jdbf3xiKgS8@public.gmane.org wrote:

> On 1/24/21 1:07 PM, John MacFarlane wrote:
> > It would be good to give people more control over the priorities
> > used for the different syntax possibilities in markdown output,
> > but I haven't figured out what the best way to do it would be.
> > In addition to code blocks, similar issues arise for
> > 
> > - bullet types (+, -, or *)
> > - list indentation (4-space or less)?
> > - headings (setext or atx)
> > - tables (prefer pipe tables or simple?)
> > - links (prefer reference or inline?)
> > 
> > In the case of headings we have the --markdown-headings option.
> > For links we have --reference-links (which also affects some
> > other formats). But I don't know if I want to go down the path of
> > introducing six more command-line options.
>
> Someone else suggested Lua filters - which sounds like overkill to me 
> and more work for users than needed.
>
> My suggestion would be a preferences/defaults file, with options. 
> Create one command-line option to specify a different preference file 
> than the normal (if someone wants to override), but otherwise look in a 
> defined location set and read an .ini file or similar. If you want to 
> be fancy allow includes so that one file can reference another and 
> override parts of it, but that's really just a flourish on top.
>
> Daniel T. Staal
>
> -- 
> ---------------------------------------------------------------
> This email copyright the author. Unless otherwise noted, you
> are expressly allowed to retransmit, quote, or otherwise use
> the contents for non-commercial purposes. This copyright will
> expire 5 years after the author's death, or in 30 years,
> whichever is longer, unless such a period is in excess of
> local copyright law.
> ---------------------------------------------------------------
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/245f2a01-c525-405a-8681-f453f7240f08n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3134 bytes --]

Re: Markdown writer ignores backtick_code_blocks?

[BPJ]

[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]

Agree, except that I think a YAML file is better than an ini file, both
because pandoc already uses YAML files for a number of things and because
it is OS-neutral.

-- 
Better --help|less than helpless

Den mån 25 jan. 2021 16:55Daniel Staal <DStaal-Jdbf3xiKgS8@public.gmane.org> skrev:

> On 1/24/21 1:07 PM, John MacFarlane wrote:
> > It would be good to give people more control over the priorities
> > used for the different syntax possibilities in markdown output,
> > but I haven't figured out what the best way to do it would be.
> > In addition to code blocks, similar issues arise for
> >
> > - bullet types (+, -, or *)
> > - list indentation (4-space or less)?
> > - headings (setext or atx)
> > - tables (prefer pipe tables or simple?)
> > - links (prefer reference or inline?)
> >
> > In the case of headings we have the --markdown-headings option.
> > For links we have --reference-links (which also affects some
> > other formats). But I don't know if I want to go down the path of
> > introducing six more command-line options.
>
> Someone else suggested Lua filters - which sounds like overkill to me
> and more work for users than needed.
>
> My suggestion would be a preferences/defaults file, with options.
> Create one command-line option to specify a different preference file
> than the normal (if someone wants to override), but otherwise look in a
> defined location set and read an .ini file or similar.  If you want to
> be fancy allow includes so that one file can reference another and
> override parts of it, but that's really just a flourish on top.
>
> Daniel T. Staal
>
> --
> ---------------------------------------------------------------
> This email copyright the author.  Unless otherwise noted, you
> are expressly allowed to retransmit, quote, or otherwise use
> the contents for non-commercial purposes.  This copyright will
> expire 5 years after the author's death, or in 30 years,
> whichever is longer, unless such a period is in excess of
> local copyright law.
> ---------------------------------------------------------------
>
> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pandoc-discuss/f7183b34-f20e-2024-34dc-8803de6298e5%40usa.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CADAJKhCTHtpvmJWpHaZe5hrZMb39Vdzd0kMkSnEOvsjjB9DobA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 3996 bytes --]

Re: Markdown writer ignores backtick_code_blocks?

[Daniel Staal]

On 1/25/21 11:47 AM, BPJ wrote:
> Agree, except that I think a YAML file is better than an ini file, both 
> because pandoc already uses YAML files for a number of things and 
> because it is OS-neutral.

Good point.  Main reason I said .ini was to give an example - that it 
should be simple and human-readable.  But YAML meets that as well, and 
the parser's already in the codebase.

Daniel T. Staal

-- 
---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------