ANN: pandoc 1.19.1, and plans for 2.0

ANN: pandoc 1.19.1, and plans for 2.0

[John MacFarlane]

I've just released pandoc 1.19.1 in the usual places:

Hackage (source & API docs):
https://hackage.haskell.org/package/pandoc

GitHub (binary packages & changelog):
https://github.com/jgm/pandoc/releases/tag/1.19.1

The main reason for the release (so soon after 1.19)
is to fix a serious regression in the HTML reader
affecting tables.  I recommend that anyone who is
using 1.19 upgrade to 1.19.1.

There are a few other minor improvements as well.

An update on plans for pandoc 2.0
---------------------------------

Jesse Rosenthal and I have been working on a restructuring
of the pandoc API.  This will be pandoc 2.0.

Let me explain the point of the change.  Currently pandoc
has some writers that are "pure" (they can't do IO) and
others that are not.  (In Haskell, it's built into the type
of a function whether it can do IO.)  For example, the
HTML writer is pure, while the docx writer does IO.
All of the readers are pure.

In some contexts, there are big advantages to purity.  For
example, if you're using pandoc in a web application and you
use a pure function, you can have confidence that it isn't
going to write to or read from your file system.  And pure
readers and writers are easy to parallelize and to
test deterministically.

But purity can also make things difficult.  For example,
LaTeX documents can include other files using \include
or \input or \usepackage.  Pandoc's LaTeX reader is pure,
so it can't just open these files and parse them.
Instead we have to use a hack, preprocessing the file
and doing these transclusions before passing the contents
to the LaTeX reader.

Ideally, we could choose to run each reader or writer
in "pure" or in "IO" mode, as our application requires.
Running in "pure" mode imposes certain limitations: for
example, includes can't be processed (unless we supply
a virtual directory up front).  But it also has certain
advantages, as noted above.

In pandoc 2.0 you'll be able to use each reader or writer
either as a pure function (with runPure) or in IO (with
runIO).  That's the main architectural change.

Those who use pandoc as a library will have to make some
minor changes in how they call pandoc's functions.

Those who use the command line program will see improvements
in things like include file processing and better warnings.

Anyway, that's a preview of what's to come.  I'm hoping
that maybe this will be the next release of pandoc, but if
another bad regression emerges I may need to do another
release in the 1.x series.

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Thomas J. Duck]

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


Thanks, John.  Will there be any changes affecting filters with pandoc 2.0?

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/3d118c6a-a9e7-40fc-acf0-d6f434226903%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Matthew Pickering]

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

How are you planning to implement this? I remember trying something like
this a few years ago and so will be glad to see the change make it into
pandoc!

On 10 Dec 2016 15:55, "John MacFarlane" <jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> wrote:

> I've just released pandoc 1.19.1 in the usual places:
>
> Hackage (source & API docs):
> https://hackage.haskell.org/package/pandoc
>
> GitHub (binary packages & changelog):
> https://github.com/jgm/pandoc/releases/tag/1.19.1
>
> The main reason for the release (so soon after 1.19)
> is to fix a serious regression in the HTML reader
> affecting tables.  I recommend that anyone who is
> using 1.19 upgrade to 1.19.1.
>
> There are a few other minor improvements as well.
>
> An update on plans for pandoc 2.0
> ---------------------------------
>
> Jesse Rosenthal and I have been working on a restructuring
> of the pandoc API.  This will be pandoc 2.0.
>
> Let me explain the point of the change.  Currently pandoc
> has some writers that are "pure" (they can't do IO) and
> others that are not.  (In Haskell, it's built into the type
> of a function whether it can do IO.)  For example, the
> HTML writer is pure, while the docx writer does IO.
> All of the readers are pure.
>
> In some contexts, there are big advantages to purity.  For
> example, if you're using pandoc in a web application and you
> use a pure function, you can have confidence that it isn't
> going to write to or read from your file system.  And pure
> readers and writers are easy to parallelize and to
> test deterministically.
>
> But purity can also make things difficult.  For example,
> LaTeX documents can include other files using \include
> or \input or \usepackage.  Pandoc's LaTeX reader is pure,
> so it can't just open these files and parse them.
> Instead we have to use a hack, preprocessing the file
> and doing these transclusions before passing the contents
> to the LaTeX reader.
>
> Ideally, we could choose to run each reader or writer
> in "pure" or in "IO" mode, as our application requires.
> Running in "pure" mode imposes certain limitations: for
> example, includes can't be processed (unless we supply
> a virtual directory up front).  But it also has certain
> advantages, as noted above.
>
> In pandoc 2.0 you'll be able to use each reader or writer
> either as a pure function (with runPure) or in IO (with
> runIO).  That's the main architectural change.
>
> Those who use pandoc as a library will have to make some
> minor changes in how they call pandoc's functions.
>
> Those who use the command line program will see improvements
> in things like include file processing and better warnings.
>
> Anyway, that's a preview of what's to come.  I'm hoping
> that maybe this will be the next release of pandoc, but if
> another bad regression emerges I may need to do another
> release in the 1.x series.
>
> --
> 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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/pandoc-discuss/20161210145524.GA43275%40Johns-MBP.home.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CALuQ0m-O2EEg-4fhMrXvwHXtVAwjSKVRfbgL%2BiPmd82zB6u01Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Thomas J. Duck]

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

Let me clarify.  I mean "Will the API changes in pandoc 2.0 affect filters?"

On Saturday, December 10, 2016 at 11:05:51 AM UTC-4, Thomas J. Duck wrote:
>
>
> Thanks, John.  Will there be any changes affecting filters with pandoc 2.0?
>

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/1c5c8d04-e1c7-42a0-ac23-8b99ca8ddaa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[John MacFarlane]

All readers and writers in a PandocMonad typeclass,
with PandocIO and PandocPure instances.

You can have a look at the typeclass branch if you want to
see more.

+++ Matthew Pickering [Dec 10 16 16:06 ]:
>   How are you planning to implement this? I remember trying something
>   like this a few years ago and so will be glad to see the change make it
>   into pandoc!
>
>   On 10 Dec 2016 15:55, "John MacFarlane" <[1]jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> wrote:
>
>     I've just released pandoc 1.19.1 in the usual places:
>     Hackage (source & API docs):
>     [2]https://hackage.haskell.org/package/pandoc
>     GitHub (binary packages & changelog):
>     [3]https://github.com/jgm/pandoc/releases/tag/1.19.1
>     The main reason for the release (so soon after 1.19)
>     is to fix a serious regression in the HTML reader
>     affecting tables.  I recommend that anyone who is
>     using 1.19 upgrade to 1.19.1.
>     There are a few other minor improvements as well.
>     An update on plans for pandoc 2.0
>     ---------------------------------
>     Jesse Rosenthal and I have been working on a restructuring
>     of the pandoc API.  This will be pandoc 2.0.
>     Let me explain the point of the change.  Currently pandoc
>     has some writers that are "pure" (they can't do IO) and
>     others that are not.  (In Haskell, it's built into the type
>     of a function whether it can do IO.)  For example, the
>     HTML writer is pure, while the docx writer does IO.
>     All of the readers are pure.
>     In some contexts, there are big advantages to purity.  For
>     example, if you're using pandoc in a web application and you
>     use a pure function, you can have confidence that it isn't
>     going to write to or read from your file system.  And pure
>     readers and writers are easy to parallelize and to
>     test deterministically.
>     But purity can also make things difficult.  For example,
>     LaTeX documents can include other files using \include
>     or \input or \usepackage.  Pandoc's LaTeX reader is pure,
>     so it can't just open these files and parse them.
>     Instead we have to use a hack, preprocessing the file
>     and doing these transclusions before passing the contents
>     to the LaTeX reader.
>     Ideally, we could choose to run each reader or writer
>     in "pure" or in "IO" mode, as our application requires.
>     Running in "pure" mode imposes certain limitations: for
>     example, includes can't be processed (unless we supply
>     a virtual directory up front).  But it also has certain
>     advantages, as noted above.
>     In pandoc 2.0 you'll be able to use each reader or writer
>     either as a pure function (with runPure) or in IO (with
>     runIO).  That's the main architectural change.
>     Those who use pandoc as a library will have to make some
>     minor changes in how they call pandoc's functions.
>     Those who use the command line program will see improvements
>     in things like include file processing and better warnings.
>     Anyway, that's a preview of what's to come.  I'm hoping
>     that maybe this will be the next release of pandoc, but if
>     another bad regression emerges I may need to do another
>     release in the 1.x series.
>     --
>     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 [4]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>     To post to this group, send email to
>     [5]pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>     To view this discussion on the web visit
>     [6]https://groups.google.com/d/msgid/pandoc-discuss/20161210145
>     524.GA43275%40Johns-MBP.home.
>     For more options, visit [7]https://groups.google.com/d/optout.
>
>   --
>   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 [8]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>   To post to this group, send email to
>   [9]pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>   To view this discussion on the web visit
>   [10]https://groups.google.com/d/msgid/pandoc-discuss/CALuQ0m-O2EEg-4fhM
>   rXvwHXtVAwjSKVRfbgL%2BiPmd82zB6u01Q%40mail.gmail.com.
>   For more options, visit [11]https://groups.google.com/d/optout.
>
>References
>
>   1. mailto:jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org
>   2. https://hackage.haskell.org/package/pandoc
>   3. https://github.com/jgm/pandoc/releases/tag/1.19.1
>   4. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>   5. mailto:pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>   6. https://groups.google.com/d/msgid/pandoc-discuss/20161210145524.GA43275-l/d5Ua9yGnxXsXJlQylH7w@public.gmane.org
>   7. https://groups.google.com/d/optout
>   8. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>   9. mailto:pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>  10. https://groups.google.com/d/msgid/pandoc-discuss/CALuQ0m-O2EEg-4fhMrXvwHXtVAwjSKVRfbgL+iPmd82zB6u01Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org?utm_medium=email&utm_source=footer
>  11. https://groups.google.com/d/optout

Re: ANN: pandoc 1.19.1, and plans for 2.0

[John MacFarlane]

Too early to say, but so far nothing is contemplated that
would affect filters.


+++ Thomas J. Duck [Dec 10 16 08:16 ]:
>   Let me clarify.  I mean "Will the API changes in pandoc 2.0 affect
>   filters?"
>   On Saturday, December 10, 2016 at 11:05:51 AM UTC-4, Thomas J. Duck
>   wrote:
>
>   Thanks, John.  Will there be any changes affecting filters with pandoc
>   2.0?
>
>   --
>   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 [1]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>   To post to this group, send email to
>   [2]pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>   To view this discussion on the web visit
>   [3]https://groups.google.com/d/msgid/pandoc-discuss/1c5c8d04-e1c7-42a0-
>   ac23-8b99ca8ddaa7%40googlegroups.com.
>   For more options, visit [4]https://groups.google.com/d/optout.
>
>References
>
>   1. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>   2. mailto:pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>   3. https://groups.google.com/d/msgid/pandoc-discuss/1c5c8d04-e1c7-42a0-ac23-8b99ca8ddaa7-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org?utm_medium=email&utm_source=footer
>   4. https://groups.google.com/d/optout

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Kolen Cheung]

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



For those who are interested:

It started from Archictectural change: Make all writers useable without IO 
· Issue #2930 · jgm/pandoc <https://github.com/jgm/pandoc/issues/2930>.

Then there’s jgm/pandoc at free <https://github.com/jgm/pandoc/tree/free> 
branch.

Later, they decided to use the jgm/pandoc at typeclass 
<https://github.com/jgm/pandoc/tree/typeclass> branch implementation 
instead.

On Saturday, December 10, 2016 at 7:06:26 AM UTC-8, Matthew Pickering wrote:

How are you planning to implement this? I remember trying something like 
> this a few years ago and so will be glad to see the change make it into 
> pandoc! 
>
> On 10 Dec 2016 15:55, "John MacFarlane" <j...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org <javascript:>> 
> wrote:
>
>> I've just released pandoc 1.19.1 in the usual places:
>>
>> Hackage (source & API docs):
>> https://hackage.haskell.org/package/pandoc
>>
>> GitHub (binary packages & changelog):
>> https://github.com/jgm/pandoc/releases/tag/1.19.1
>>
>> The main reason for the release (so soon after 1.19)
>> is to fix a serious regression in the HTML reader
>> affecting tables.  I recommend that anyone who is
>> using 1.19 upgrade to 1.19.1.
>>
>> There are a few other minor improvements as well.
>>
>> An update on plans for pandoc 2.0
>> ---------------------------------
>>
>> Jesse Rosenthal and I have been working on a restructuring
>> of the pandoc API.  This will be pandoc 2.0.
>>
>> Let me explain the point of the change.  Currently pandoc
>> has some writers that are "pure" (they can't do IO) and
>> others that are not.  (In Haskell, it's built into the type
>> of a function whether it can do IO.)  For example, the
>> HTML writer is pure, while the docx writer does IO.
>> All of the readers are pure.
>>
>> In some contexts, there are big advantages to purity.  For
>> example, if you're using pandoc in a web application and you
>> use a pure function, you can have confidence that it isn't
>> going to write to or read from your file system.  And pure
>> readers and writers are easy to parallelize and to
>> test deterministically.
>>
>> But purity can also make things difficult.  For example,
>> LaTeX documents can include other files using \include
>> or \input or \usepackage.  Pandoc's LaTeX reader is pure,
>> so it can't just open these files and parse them.
>> Instead we have to use a hack, preprocessing the file
>> and doing these transclusions before passing the contents
>> to the LaTeX reader.
>>
>> Ideally, we could choose to run each reader or writer
>> in "pure" or in "IO" mode, as our application requires.
>> Running in "pure" mode imposes certain limitations: for
>> example, includes can't be processed (unless we supply
>> a virtual directory up front).  But it also has certain
>> advantages, as noted above.
>>
>> In pandoc 2.0 you'll be able to use each reader or writer
>> either as a pure function (with runPure) or in IO (with
>> runIO).  That's the main architectural change.
>>
>> Those who use pandoc as a library will have to make some
>> minor changes in how they call pandoc's functions.
>>
>> Those who use the command line program will see improvements
>> in things like include file processing and better warnings.
>>
>> Anyway, that's a preview of what's to come.  I'm hoping
>> that maybe this will be the next release of pandoc, but if
>> another bad regression emerges I may need to do another
>> release in the 1.x series.
>>
>> -- 
>> 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-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>.
>> To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org 
>> <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pandoc-discuss/20161210145524.GA43275%40Johns-MBP.home
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> ​

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/b78af870-feeb-4bc7-a07b-3e69fac9aed5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Kolen Cheung]

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



By the way, what happened to jgm/pandoc2: Test bed for experimenting with 
new architecture for pandoc <https://github.com/jgm/pandoc2>?

On Saturday, December 10, 2016 at 6:55:41 AM UTC-8, John MacFarlane wrote:

I've just released pandoc 1.19.1 in the usual places: 
>
> Hackage (source & API docs): 
> https://hackage.haskell.org/package/pandoc 
>
> GitHub (binary packages & changelog): 
> https://github.com/jgm/pandoc/releases/tag/1.19.1 
>
> The main reason for the release (so soon after 1.19) 
> is to fix a serious regression in the HTML reader 
> affecting tables.  I recommend that anyone who is 
> using 1.19 upgrade to 1.19.1. 
>
> There are a few other minor improvements as well. 
>
> An update on plans for pandoc 2.0 
> --------------------------------- 
>
> Jesse Rosenthal and I have been working on a restructuring 
> of the pandoc API.  This will be pandoc 2.0. 
>
> Let me explain the point of the change.  Currently pandoc 
> has some writers that are "pure" (they can't do IO) and 
> others that are not.  (In Haskell, it's built into the type 
> of a function whether it can do IO.)  For example, the 
> HTML writer is pure, while the docx writer does IO. 
> All of the readers are pure. 
>
> In some contexts, there are big advantages to purity.  For 
> example, if you're using pandoc in a web application and you 
> use a pure function, you can have confidence that it isn't 
> going to write to or read from your file system.  And pure 
> readers and writers are easy to parallelize and to 
> test deterministically. 
>
> But purity can also make things difficult.  For example, 
> LaTeX documents can include other files using \include 
> or \input or \usepackage.  Pandoc's LaTeX reader is pure, 
> so it can't just open these files and parse them. 
> Instead we have to use a hack, preprocessing the file 
> and doing these transclusions before passing the contents 
> to the LaTeX reader. 
>
> Ideally, we could choose to run each reader or writer 
> in "pure" or in "IO" mode, as our application requires. 
> Running in "pure" mode imposes certain limitations: for 
> example, includes can't be processed (unless we supply 
> a virtual directory up front).  But it also has certain 
> advantages, as noted above. 
>
> In pandoc 2.0 you'll be able to use each reader or writer 
> either as a pure function (with runPure) or in IO (with 
> runIO).  That's the main architectural change. 
>
> Those who use pandoc as a library will have to make some 
> minor changes in how they call pandoc's functions. 
>
> Those who use the command line program will see improvements 
> in things like include file processing and better warnings. 
>
> Anyway, that's a preview of what's to come.  I'm hoping 
> that maybe this will be the next release of pandoc, but if 
> another bad regression emerges I may need to do another 
> release in the 1.x series. 
>
> ​

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/2b72b0a4-3d3c-4158-8990-99a40e92cb51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[John MacFarlane]

I used some of those ideas in cheapskate, but that was ages
ago.  That repository probably doesn't have much of use any
more.

+++ Kolen Cheung [Dec 11 16 00:02 ]:
>   By the way, what happened to [1]jgm/pandoc2: Test bed for experimenting
>   with new architecture for pandoc?
>
>   On Saturday, December 10, 2016 at 6:55:41 AM UTC-8, John MacFarlane
>   wrote:
>
>     I've just released pandoc 1.19.1 in the usual places:
>     Hackage (source & API docs):
>     [2]https://hackage.haskell.org/package/pandoc
>     GitHub (binary packages & changelog):
>     [3]https://github.com/jgm/pandoc/releases/tag/1.19.1
>     The main reason for the release (so soon after 1.19)
>     is to fix a serious regression in the HTML reader
>     affecting tables.  I recommend that anyone who is
>     using 1.19 upgrade to 1.19.1.
>     There are a few other minor improvements as well.
>     An update on plans for pandoc 2.0
>     ---------------------------------
>     Jesse Rosenthal and I have been working on a restructuring
>     of the pandoc API.  This will be pandoc 2.0.
>     Let me explain the point of the change.  Currently pandoc
>     has some writers that are "pure" (they can't do IO) and
>     others that are not.  (In Haskell, it's built into the type
>     of a function whether it can do IO.)  For example, the
>     HTML writer is pure, while the docx writer does IO.
>     All of the readers are pure.
>     In some contexts, there are big advantages to purity.  For
>     example, if you're using pandoc in a web application and you
>     use a pure function, you can have confidence that it isn't
>     going to write to or read from your file system.  And pure
>     readers and writers are easy to parallelize and to
>     test deterministically.
>     But purity can also make things difficult.  For example,
>     LaTeX documents can include other files using \include
>     or \input or \usepackage.  Pandoc's LaTeX reader is pure,
>     so it can't just open these files and parse them.
>     Instead we have to use a hack, preprocessing the file
>     and doing these transclusions before passing the contents
>     to the LaTeX reader.
>     Ideally, we could choose to run each reader or writer
>     in "pure" or in "IO" mode, as our application requires.
>     Running in "pure" mode imposes certain limitations: for
>     example, includes can't be processed (unless we supply
>     a virtual directory up front).  But it also has certain
>     advantages, as noted above.
>     In pandoc 2.0 you'll be able to use each reader or writer
>     either as a pure function (with runPure) or in IO (with
>     runIO).  That's the main architectural change.
>     Those who use pandoc as a library will have to make some
>     minor changes in how they call pandoc's functions.
>     Those who use the command line program will see improvements
>     in things like include file processing and better warnings.
>     Anyway, that's a preview of what's to come.  I'm hoping
>     that maybe this will be the next release of pandoc, but if
>     another bad regression emerges I may need to do another
>     release in the 1.x series.
>
>   ​
>
>   --
>   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 [4]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>   To post to this group, send email to
>   [5]pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>   To view this discussion on the web visit
>   [6]https://groups.google.com/d/msgid/pandoc-discuss/2b72b0a4-3d3c-4158-
>   8990-99a40e92cb51%40googlegroups.com.
>   For more options, visit [7]https://groups.google.com/d/optout.
>
>References
>
>   1. https://github.com/jgm/pandoc2
>   2. https://hackage.haskell.org/package/pandoc
>   3. https://github.com/jgm/pandoc/releases/tag/1.19.1
>   4. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>   5. mailto:pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>   6. https://groups.google.com/d/msgid/pandoc-discuss/2b72b0a4-3d3c-4158-8990-99a40e92cb51-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org?utm_medium=email&utm_source=footer
>   7. https://groups.google.com/d/optout

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/20161211150235.GA64656%40Johns-MBP.home.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: pandoc 1.19.1, and plans for 2.0

[John MacFarlane]

Just to clarify, many of the ideas explored there have
already been incorporated into pandoc.

+++ John MacFarlane [Dec 11 16 16:02 ]:
>I used some of those ideas in cheapskate, but that was ages
>ago.  That repository probably doesn't have much of use any
>more.
>
>+++ Kolen Cheung [Dec 11 16 00:02 ]:
>>  By the way, what happened to [1]jgm/pandoc2: Test bed for experimenting
>>  with new architecture for pandoc?

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Jens Petersen]

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

On 10 December 2016 at 23:55, John MacFarlane <jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> wrote:

> I've just released pandoc 1.19.1
>

Thank you! - I update my Fedora pandoc Copr repo to it today for Fedora
23-25.

https://copr.fedorainfracloud.org/coprs/petersen/pandoc/

Cheers, Jens

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAEDGBqKiN%3DPYf%3Do0puKs142BEsg%2BPcCrRaV3eobO9FLa90%2B5vA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

['Chad Walters' via pandoc-discuss]

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

Any thoughts on ETA for 2.0? Will this address both LaTeX \input and 
Multimarkdown transclusion? I'd like to use MMD transclusion to address 
this so I don't have to port our existing markdown to LaTeX or some other 
format.

Thanks!

Chad

On Saturday, December 10, 2016 at 6:55:41 AM UTC-8, John MacFarlane wrote:

> I've just released pandoc 1.19.1 in the usual places: 
>
> Hackage (source & API docs): 
> https://hackage.haskell.org/package/pandoc 
>
> GitHub (binary packages & changelog): 
> https://github.com/jgm/pandoc/releases/tag/1.19.1 
>
> The main reason for the release (so soon after 1.19) 
> is to fix a serious regression in the HTML reader 
> affecting tables.  I recommend that anyone who is 
> using 1.19 upgrade to 1.19.1. 
>
> There are a few other minor improvements as well. 
>
> An update on plans for pandoc 2.0 
> --------------------------------- 
>
> Jesse Rosenthal and I have been working on a restructuring 
> of the pandoc API.  This will be pandoc 2.0. 
>
> Let me explain the point of the change.  Currently pandoc 
> has some writers that are "pure" (they can't do IO) and 
> others that are not.  (In Haskell, it's built into the type 
> of a function whether it can do IO.)  For example, the 
> HTML writer is pure, while the docx writer does IO. 
> All of the readers are pure. 
>
> In some contexts, there are big advantages to purity.  For 
> example, if you're using pandoc in a web application and you 
> use a pure function, you can have confidence that it isn't 
> going to write to or read from your file system.  And pure 
> readers and writers are easy to parallelize and to 
> test deterministically. 
>
> But purity can also make things difficult.  For example, 
> LaTeX documents can include other files using \include 
> or \input or \usepackage.  Pandoc's LaTeX reader is pure, 
> so it can't just open these files and parse them. 
> Instead we have to use a hack, preprocessing the file 
> and doing these transclusions before passing the contents 
> to the LaTeX reader. 
>
> Ideally, we could choose to run each reader or writer 
> in "pure" or in "IO" mode, as our application requires. 
> Running in "pure" mode imposes certain limitations: for 
> example, includes can't be processed (unless we supply 
> a virtual directory up front).  But it also has certain 
> advantages, as noted above. 
>
> In pandoc 2.0 you'll be able to use each reader or writer 
> either as a pure function (with runPure) or in IO (with 
> runIO).  That's the main architectural change. 
>
> Those who use pandoc as a library will have to make some 
> minor changes in how they call pandoc's functions. 
>
> Those who use the command line program will see improvements 
> in things like include file processing and better warnings. 
>
> Anyway, that's a preview of what's to come.  I'm hoping 
> that maybe this will be the next release of pandoc, but if 
> another bad regression emerges I may need to do another 
> release in the 1.x series. 
>
>

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/d56fc047-4d3d-4d8d-bee3-a77c962f2746%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Kolen Cheung]

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



pandoc 2.0 will makes IO much easier. I think it has been mentioned 
somewhere the LaTeX \input|\include commands will be supported. Regarding 
MMD transclusion syntax however, I don’t think it has been seriously 
considered. For example, some other threads here in pandoc-discuss 
suggested the syntax similar to images is used for generic includes in 
markdown, i.e. ![](some.md), etc.

Being a former MMD user, I can understand the support of more MMD syntax is 
welcomed. But MMD’s transclusion syntax is not used anywhere else (I 
believe), and e.g. although Marked also support it, Marked actually defines 
it’s own syntax of include too. Another thing kind of related is from 
panflute’s example, he defined another syntax for include using a filter.

So it seems there’s not a transclusion/include syntax in markdown that has 
already been used and really stands out, and from the point of view of a 
good markdown syntax, it seems the image syntax beats all these examples.

See idea: include files and long tables · Issue #553 · jgm/pandoc 
<https://github.com/jgm/pandoc/issues/553>

On Thursday, February 9, 2017 at 12:24:12 PM UTC-8, Chad Walters wrote:

Any thoughts on ETA for 2.0? Will this address both LaTeX \input and 
> Multimarkdown transclusion? I'd like to use MMD transclusion to address 
> this so I don't have to port our existing markdown to LaTeX or some other 
> format.
>
> Thanks!
>
> Chad
>
> On Saturday, December 10, 2016 at 6:55:41 AM UTC-8, John MacFarlane wrote:
>
>> I've just released pandoc 1.19.1 in the usual places: 
>>
>> Hackage (source & API docs): 
>> https://hackage.haskell.org/package/pandoc 
>>
>> GitHub (binary packages & changelog): 
>> https://github.com/jgm/pandoc/releases/tag/1.19.1 
>>
>> The main reason for the release (so soon after 1.19) 
>> is to fix a serious regression in the HTML reader 
>> affecting tables.  I recommend that anyone who is 
>> using 1.19 upgrade to 1.19.1. 
>>
>> There are a few other minor improvements as well. 
>>
>> An update on plans for pandoc 2.0 
>> --------------------------------- 
>>
>> Jesse Rosenthal and I have been working on a restructuring 
>> of the pandoc API.  This will be pandoc 2.0. 
>>
>> Let me explain the point of the change.  Currently pandoc 
>> has some writers that are "pure" (they can't do IO) and 
>> others that are not.  (In Haskell, it's built into the type 
>> of a function whether it can do IO.)  For example, the 
>> HTML writer is pure, while the docx writer does IO. 
>> All of the readers are pure. 
>>
>> In some contexts, there are big advantages to purity.  For 
>> example, if you're using pandoc in a web application and you 
>> use a pure function, you can have confidence that it isn't 
>> going to write to or read from your file system.  And pure 
>> readers and writers are easy to parallelize and to 
>> test deterministically. 
>>
>> But purity can also make things difficult.  For example, 
>> LaTeX documents can include other files using \include 
>> or \input or \usepackage.  Pandoc's LaTeX reader is pure, 
>> so it can't just open these files and parse them. 
>> Instead we have to use a hack, preprocessing the file 
>> and doing these transclusions before passing the contents 
>> to the LaTeX reader. 
>>
>> Ideally, we could choose to run each reader or writer 
>> in "pure" or in "IO" mode, as our application requires. 
>> Running in "pure" mode imposes certain limitations: for 
>> example, includes can't be processed (unless we supply 
>> a virtual directory up front).  But it also has certain 
>> advantages, as noted above. 
>>
>> In pandoc 2.0 you'll be able to use each reader or writer 
>> either as a pure function (with runPure) or in IO (with 
>> runIO).  That's the main architectural change. 
>>
>> Those who use pandoc as a library will have to make some 
>> minor changes in how they call pandoc's functions. 
>>
>> Those who use the command line program will see improvements 
>> in things like include file processing and better warnings. 
>>
>> Anyway, that's a preview of what's to come.  I'm hoping 
>> that maybe this will be the next release of pandoc, but if 
>> another bad regression emerges I may need to do another 
>> release in the 1.x series. 
>>
>> ​

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/d2913e3a-bb5f-4d2f-a178-d6b94de3a88c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[John MacFarlane]

I hadn't thoght about MMD transclusion, but it could now be
added without too much trouble.  Can you link me to the
documentation for it?

I don't have a specific ETA yet.

+++ 'Chad Walters' via pandoc-discuss [Feb 09 17 12:24 ]:
>   Any thoughts on ETA for 2.0? Will this address both LaTeX \input and
>   Multimarkdown transclusion? I'd like to use MMD transclusion to address
>   this so I don't have to port our existing markdown to LaTeX or some
>   other format.
>   Thanks!
>   Chad
>   On Saturday, December 10, 2016 at 6:55:41 AM UTC-8, John MacFarlane
>   wrote:
>
>     I've just released pandoc 1.19.1 in the usual places:
>     Hackage (source & API docs):
>     [1]https://hackage.haskell.org/package/pandoc
>     GitHub (binary packages & changelog):
>     [2]https://github.com/jgm/pandoc/releases/tag/1.19.1
>     The main reason for the release (so soon after 1.19)
>     is to fix a serious regression in the HTML reader
>     affecting tables.  I recommend that anyone who is
>     using 1.19 upgrade to 1.19.1.
>     There are a few other minor improvements as well.
>     An update on plans for pandoc 2.0
>     ---------------------------------
>     Jesse Rosenthal and I have been working on a restructuring
>     of the pandoc API.  This will be pandoc 2.0.
>     Let me explain the point of the change.  Currently pandoc
>     has some writers that are "pure" (they can't do IO) and
>     others that are not.  (In Haskell, it's built into the type
>     of a function whether it can do IO.)  For example, the
>     HTML writer is pure, while the docx writer does IO.
>     All of the readers are pure.
>     In some contexts, there are big advantages to purity.  For
>     example, if you're using pandoc in a web application and you
>     use a pure function, you can have confidence that it isn't
>     going to write to or read from your file system.  And pure
>     readers and writers are easy to parallelize and to
>     test deterministically.
>     But purity can also make things difficult.  For example,
>     LaTeX documents can include other files using \include
>     or \input or \usepackage.  Pandoc's LaTeX reader is pure,
>     so it can't just open these files and parse them.
>     Instead we have to use a hack, preprocessing the file
>     and doing these transclusions before passing the contents
>     to the LaTeX reader.
>     Ideally, we could choose to run each reader or writer
>     in "pure" or in "IO" mode, as our application requires.
>     Running in "pure" mode imposes certain limitations: for
>     example, includes can't be processed (unless we supply
>     a virtual directory up front).  But it also has certain
>     advantages, as noted above.
>     In pandoc 2.0 you'll be able to use each reader or writer
>     either as a pure function (with runPure) or in IO (with
>     runIO).  That's the main architectural change.
>     Those who use pandoc as a library will have to make some
>     minor changes in how they call pandoc's functions.
>     Those who use the command line program will see improvements
>     in things like include file processing and better warnings.
>     Anyway, that's a preview of what's to come.  I'm hoping
>     that maybe this will be the next release of pandoc, but if
>     another bad regression emerges I may need to do another
>     release in the 1.x series.
>
>   --
>   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 [3]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>   To post to this group, send email to
>   [4]pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>   To view this discussion on the web visit
>   [5]https://groups.google.com/d/msgid/pandoc-discuss/d56fc047-4d3d-4d8d-
>   bee3-a77c962f2746%40googlegroups.com.
>   For more options, visit [6]https://groups.google.com/d/optout.
>
>References
>
>   1. https://hackage.haskell.org/package/pandoc
>   2. https://github.com/jgm/pandoc/releases/tag/1.19.1
>   3. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>   4. mailto:pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>   5. https://groups.google.com/d/msgid/pandoc-discuss/d56fc047-4d3d-4d8d-bee3-a77c962f2746-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org?utm_medium=email&utm_source=footer
>   6. https://groups.google.com/d/optout

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Kolen Cheung]

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

MMD transclusion 
here: http://fletcher.github.io/MultiMarkdown-5/transclusion.html

Some properties:

1. infinite depth: it will resolve recursively indefinitely
2. It can transcluded as both as is (i.e. raw, in the current format), or 
as code. Basically if the transclusion syntax is put inside a CodeBlock, it 
will be transcluded and put in the CodeBlock. So it kinds of violates a 
CodeBlock should be unparsed.
3. wildcard syntax: if the extension is a wildcard, it uses whatever target 
format extension you're using. i.e. the reader need to be aware of the 
output format too. I don't know if the new architecture allow this.

Because of these, may be only partial support of the MMD transclusion 
should be provided.

On Thursday, February 9, 2017 at 1:36:22 PM UTC-8, John MacFarlane wrote:
>
> I hadn't thoght about MMD transclusion, but it could now be 
> added without too much trouble.  Can you link me to the 
> documentation for it? 
>
> I don't have a specific ETA yet. 
>
> +++ 'Chad Walters' via pandoc-discuss [Feb 09 17 12:24 ]: 
> >   Any thoughts on ETA for 2.0? Will this address both LaTeX \input and 
> >   Multimarkdown transclusion? I'd like to use MMD transclusion to 
> address 
> >   this so I don't have to port our existing markdown to LaTeX or some 
> >   other format. 
> >   Thanks! 
> >   Chad 
> >   On Saturday, December 10, 2016 at 6:55:41 AM UTC-8, John MacFarlane 
> >   wrote: 
> > 
> >     I've just released pandoc 1.19.1 in the usual places: 
> >     Hackage (source & API docs): 
> >     [1]https://hackage.haskell.org/package/pandoc 
> >     GitHub (binary packages & changelog): 
> >     [2]https://github.com/jgm/pandoc/releases/tag/1.19.1 
> >     The main reason for the release (so soon after 1.19) 
> >     is to fix a serious regression in the HTML reader 
> >     affecting tables.  I recommend that anyone who is 
> >     using 1.19 upgrade to 1.19.1. 
> >     There are a few other minor improvements as well. 
> >     An update on plans for pandoc 2.0 
> >     --------------------------------- 
> >     Jesse Rosenthal and I have been working on a restructuring 
> >     of the pandoc API.  This will be pandoc 2.0. 
> >     Let me explain the point of the change.  Currently pandoc 
> >     has some writers that are "pure" (they can't do IO) and 
> >     others that are not.  (In Haskell, it's built into the type 
> >     of a function whether it can do IO.)  For example, the 
> >     HTML writer is pure, while the docx writer does IO. 
> >     All of the readers are pure. 
> >     In some contexts, there are big advantages to purity.  For 
> >     example, if you're using pandoc in a web application and you 
> >     use a pure function, you can have confidence that it isn't 
> >     going to write to or read from your file system.  And pure 
> >     readers and writers are easy to parallelize and to 
> >     test deterministically. 
> >     But purity can also make things difficult.  For example, 
> >     LaTeX documents can include other files using \include 
> >     or \input or \usepackage.  Pandoc's LaTeX reader is pure, 
> >     so it can't just open these files and parse them. 
> >     Instead we have to use a hack, preprocessing the file 
> >     and doing these transclusions before passing the contents 
> >     to the LaTeX reader. 
> >     Ideally, we could choose to run each reader or writer 
> >     in "pure" or in "IO" mode, as our application requires. 
> >     Running in "pure" mode imposes certain limitations: for 
> >     example, includes can't be processed (unless we supply 
> >     a virtual directory up front).  But it also has certain 
> >     advantages, as noted above. 
> >     In pandoc 2.0 you'll be able to use each reader or writer 
> >     either as a pure function (with runPure) or in IO (with 
> >     runIO).  That's the main architectural change. 
> >     Those who use pandoc as a library will have to make some 
> >     minor changes in how they call pandoc's functions. 
> >     Those who use the command line program will see improvements 
> >     in things like include file processing and better warnings. 
> >     Anyway, that's a preview of what's to come.  I'm hoping 
> >     that maybe this will be the next release of pandoc, but if 
> >     another bad regression emerges I may need to do another 
> >     release in the 1.x series. 
> > 
> >   -- 
> >   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 [3]pandoc-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. 
> >   To post to this group, send email to 
> >   [4]pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. 
> >   To view this discussion on the web visit 
> >   [5]
> https://groups.google.com/d/msgid/pandoc-discuss/d56fc047-4d3d-4d8d- 
> >   bee3-a77c962f2746%40googlegroups.com. 
> >   For more options, visit [6]https://groups.google.com/d/optout. 
> > 
> >References 
> > 
> >   1. https://hackage.haskell.org/package/pandoc 
> >   2. https://github.com/jgm/pandoc/releases/tag/1.19.1 
> >   3. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:> 
> >   4. mailto:pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:> 
> >   5. 
> https://groups.google.com/d/msgid/pandoc-discuss/d56fc047-4d3d-4d8d-bee3-a77c962f2746-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org?utm_medium=email&utm_source=footer 
> >   6. https://groups.google.com/d/optout 
>
>

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/5651bde6-d8f2-4c8f-bedf-cfa8ad7d056a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

['Chad Walters' via pandoc-discuss]

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

My main interest in MMD was because it was a markdown variant defined a 
transclusion syntax. If there is some other markdown variety that also 
supports transclusion. I would be happy to use that.

That said, if 2.0 makes it possible to do LaTeX \include then it should be 
possible to do MMD transclusion or some reasonably useful subset of it 
fairly easily. For my purposes, raw inclusion without these other features 
is good enough, although nested inclusion might be desirable.

Thanks,

Chad

 

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/90722fef-913e-458a-8fe6-7fb57c246065%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Kolen Cheung]

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

From the reference I quote earlier on, it is very likely pandoc will have its own file inclusion syntax, possbily using the image syntax.

I once try to use mmd syntax in pandoc with a lot of toggling of extensions and custom preprocessor, but in the end found that native pandoc is cleaner and easier. YMMV

Re: ANN: pandoc 1.19.1, and plans for 2.0

[BP Jonsson]

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

It seems to me that a custom attribute on code blocks would be a better way
of transcluding code, the transcluded file contents being appended to
whatever content the code block already has.

Also since pandoc supports multiple input formats a way to specify which
format a non-code transclude is would be in order.

/bpj


Den 9 feb 2017 23:16 skrev "Kolen Cheung" <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

> MMD transclusion here: http://fletcher.github.io/MultiMarkdown-5/
> transclusion.html
>
> Some properties:
>
> 1. infinite depth: it will resolve recursively indefinitely
> 2. It can transcluded as both as is (i.e. raw, in the current format), or
> as code. Basically if the transclusion syntax is put inside a CodeBlock, it
> will be transcluded and put in the CodeBlock. So it kinds of violates a
> CodeBlock should be unparsed.
> 3. wildcard syntax: if the extension is a wildcard, it uses whatever
> target format extension you're using. i.e. the reader need to be aware of
> the output format too. I don't know if the new architecture allow this.
>
> Because of these, may be only partial support of the MMD transclusion
> should be provided.
>
> On Thursday, February 9, 2017 at 1:36:22 PM UTC-8, John MacFarlane wrote:
>>
>> I hadn't thoght about MMD transclusion, but it could now be
>> added without too much trouble.  Can you link me to the
>> documentation for it?
>>
>> I don't have a specific ETA yet.
>>
>> +++ 'Chad Walters' via pandoc-discuss [Feb 09 17 12:24 ]:
>> >   Any thoughts on ETA for 2.0? Will this address both LaTeX \input and
>> >   Multimarkdown transclusion? I'd like to use MMD transclusion to
>> address
>> >   this so I don't have to port our existing markdown to LaTeX or some
>> >   other format.
>> >   Thanks!
>> >   Chad
>> >   On Saturday, December 10, 2016 at 6:55:41 AM UTC-8, John MacFarlane
>> >   wrote:
>> >
>> >     I've just released pandoc 1.19.1 in the usual places:
>> >     Hackage (source & API docs):
>> >     [1]https://hackage.haskell.org/package/pandoc
>> >     GitHub (binary packages & changelog):
>> >     [2]https://github.com/jgm/pandoc/releases/tag/1.19.1
>> >     The main reason for the release (so soon after 1.19)
>> >     is to fix a serious regression in the HTML reader
>> >     affecting tables.  I recommend that anyone who is
>> >     using 1.19 upgrade to 1.19.1.
>> >     There are a few other minor improvements as well.
>> >     An update on plans for pandoc 2.0
>> >     ---------------------------------
>> >     Jesse Rosenthal and I have been working on a restructuring
>> >     of the pandoc API.  This will be pandoc 2.0.
>> >     Let me explain the point of the change.  Currently pandoc
>> >     has some writers that are "pure" (they can't do IO) and
>> >     others that are not.  (In Haskell, it's built into the type
>> >     of a function whether it can do IO.)  For example, the
>> >     HTML writer is pure, while the docx writer does IO.
>> >     All of the readers are pure.
>> >     In some contexts, there are big advantages to purity.  For
>> >     example, if you're using pandoc in a web application and you
>> >     use a pure function, you can have confidence that it isn't
>> >     going to write to or read from your file system.  And pure
>> >     readers and writers are easy to parallelize and to
>> >     test deterministically.
>> >     But purity can also make things difficult.  For example,
>> >     LaTeX documents can include other files using \include
>> >     or \input or \usepackage.  Pandoc's LaTeX reader is pure,
>> >     so it can't just open these files and parse them.
>> >     Instead we have to use a hack, preprocessing the file
>> >     and doing these transclusions before passing the contents
>> >     to the LaTeX reader.
>> >     Ideally, we could choose to run each reader or writer
>> >     in "pure" or in "IO" mode, as our application requires.
>> >     Running in "pure" mode imposes certain limitations: for
>> >     example, includes can't be processed (unless we supply
>> >     a virtual directory up front).  But it also has certain
>> >     advantages, as noted above.
>> >     In pandoc 2.0 you'll be able to use each reader or writer
>> >     either as a pure function (with runPure) or in IO (with
>> >     runIO).  That's the main architectural change.
>> >     Those who use pandoc as a library will have to make some
>> >     minor changes in how they call pandoc's functions.
>> >     Those who use the command line program will see improvements
>> >     in things like include file processing and better warnings.
>> >     Anyway, that's a preview of what's to come.  I'm hoping
>> >     that maybe this will be the next release of pandoc, but if
>> >     another bad regression emerges I may need to do another
>> >     release in the 1.x series.
>> >
>> >   --
>> >   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 [3]pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> >   To post to this group, send email to
>> >   [4]pandoc-...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> >   To view this discussion on the web visit
>> >   [5]https://groups.google.com/d/msgid/pandoc-discuss/d56fc047
>> -4d3d-4d8d-
>> >   bee3-a77c962f2746%40googlegroups.com.
>> >   For more options, visit [6]https://groups.google.com/d/optout.
>> >
>> >References
>> >
>> >   1. https://hackage.haskell.org/package/pandoc
>> >   2. https://github.com/jgm/pandoc/releases/tag/1.19.1
>> >   3. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>> >   4. mailto:pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>> >   5. https://groups.google.com/d/msgid/pandoc-discuss/d56fc047-4d
>> 3d-4d8d-bee3-a77c962f2746-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org?utm_medium=email&
>> utm_source=footer
>> >   6. https://groups.google.com/d/optout
>>
>> --
> 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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/pandoc-discuss/5651bde6-d8f2-4c8f-bedf-cfa8ad7d056a%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/pandoc-discuss/5651bde6-d8f2-4c8f-bedf-cfa8ad7d056a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAFC_yuQANMYQ1YKnvjk-Pvd50%2B5aQnSVbksPfZb%2B%2B%3DvALJ0R9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[John MacFarlane]

I don't like the mmd system at all.  (I had to look at the
source to really understand how it works.)

The transclusion command can occur literally anywhere.
That means that if you happen to have, say, a code block
that contains something in doubled braces, you'll get
transclusion. And there's no way to turn it off via
escaping.

If you're going to have a system that works like that,
you might as well just preprocess the input to pandoc
using a regex substitution or cpp or something.

Still, we could probably support this for mmd compatibility.

I don't currently have plans for a native pandoc
transclusion syntax (based on image syntax or anything
else), but I'll think more about it.  For code blocks, using
a filter with a specially marked attribute is the way to go.

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Kolen Cheung]

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

Yes, basically MMD's transclusion is a preprocessor. Marked (a markdown previewer on Mac) works very similarly, and support both MMD and Marked syntax.

That kind of transclusion works best as a preprocessor. I think there's another thread here that mention another tool to include files that's also a preprocessor. Replicating something like that in the markdown reader does not make sense. (limited support of it might make sense though. i.e. same syntax but different implementation.)

Some more comment on MMD: there's a lot of bad things about MMD e.g. MMD syntax to include raw LaTeX is very bad. MMD's design is kind of like gluing a lot of nice syntax together by duct tape. It works, but its limitation will shows as you need to push it (and multi-output document will fall apart very soon). For those who think native support of transclusion in MMD makes your life easier, 3rd party support of anything (including "transclusion") in pandoc scales much better with complexity. Unofficial features implemented through pandoc's filter system is not as bad as it sounds. In fact this is one of the best feature of pandoc. Give existing "include" filters a try before native include is provided. e.g. one of the panflute's example also did something like MMD's transclusion (with a different syntax).

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/9a7522f6-413d-4c15-bb4b-62a07a4b09b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Melroch]

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

Kolen, how do you propose that transclusion through link syntax would
distinguish between images and transclusions with the exact same syntax? By
looking at the file extension? That would seem rather fragile to me. I
experimented a bit yesterday with a (Perl) filter which would do
transclusions with divs or code blocks, since I ran into the problem that
you may want to specify a custom command line, which you could then do in
the code block body (split into tokens with Text::ParseWords, an ancient
module which parses a string into 'words' with shell-like semantics.)
However I think that you should also be able to specify a default command
line, per input format, which I as you might have guessed intend to have
declared in metadata.

/bpj


Den 10 feb 2017 23:20 skrev "Kolen Cheung" <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

> Yes, basically MMD's transclusion is a preprocessor. Marked (a markdown
> previewer on Mac) works very similarly, and support both MMD and Marked
> syntax.
>
> That kind of transclusion works best as a preprocessor. I think there's
> another thread here that mention another tool to include files that's also
> a preprocessor. Replicating something like that in the markdown reader does
> not make sense. (limited support of it might make sense though. i.e. same
> syntax but different implementation.)
>
> Some more comment on MMD: there's a lot of bad things about MMD e.g. MMD
> syntax to include raw LaTeX is very bad. MMD's design is kind of like
> gluing a lot of nice syntax together by duct tape. It works, but its
> limitation will shows as you need to push it (and multi-output document
> will fall apart very soon). For those who think native support of
> transclusion in MMD makes your life easier, 3rd party support of anything
> (including "transclusion") in pandoc scales much better with complexity.
> Unofficial features implemented through pandoc's filter system is not as
> bad as it sounds. In fact this is one of the best feature of pandoc. Give
> existing "include" filters a try before native include is provided. e.g.
> one of the panflute's example also did something like MMD's transclusion
> (with a different syntax).
>
> --
> 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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/pandoc-discuss/9a7522f6-413d-4c15-bb4b-62a07a4b09b4%
> 40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CADAJKhCBaFfmkf_O72_j5Pn3%2B59CbkW0rqTqxxSR3hT29byKeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[Kolen Cheung]

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



What do you mean by command line? Does it mean that e.g. if a file is rst, 
the custom command line calls rst2html instead to produce the html output? 
(or some other pandoc cli options)

I think this problem (on how to know what to do with the file) is a reason idea: 
include files and long tables · Issue #553 · jgm/pandoc 
<https://github.com/jgm/pandoc/issues/553> isn’t resolved yet. I think here 
and there people have suggested using the image syntax for other file 
inclusion. e.g. one of the CSV filter did use the image syntax to include a 
CSV table.

The main problem is while the image syntax is (probably) the only markdown 
syntax that points to a file, it isn’t really included (so it is still a 
pure function without IO). So if we overload the image syntax to do this, 
we are doing 2 fundamentally different operations on the same syntax. I 
think that’s why @jgm is hesitate about it.

If I were to write a transclusion filter using the image syntax, one thing 
I would worry is what if the included file extensions are one of the valid 
pandoc input formats. e.g. in markdown source, .html is included. Should it 
calls pandoc to parse it in AST for any output, or should it be pasted as 
raw HTML (and hence only for HTML output). The later approach would be 
problematic for HTML-like output, say, ePub (or even HTML5). In this case I 
think pandoc with not put the raw HTML (raw block with format html) in the 
epub output. (I tested something like this earlier on but forgot the exact 
behavior. I remember that it will have problems on other html-like output 
though.)

I think this is similar to what you describe — essentially how a certain 
file kind should be handled, when there can be multiple ways to handle 
that. Luckily image syntax has attributes, and we can also use metadata to 
do it. I think the major problem here is how to design it (workflow and 
syntax to use in attribute/metadata) to please everyone.

After thinking about all these, I think a “native” syntax of include, that 
only paste an included files (recursively) as is, will be a better idea. 
There’s much less thing to worry about and it won’t overload the image 
syntax to do completely different things.

Just to mention some notable markdown-ish include syntax (none of these are 
using existing pandoc markdown syntax, which is proposed e.g. image syntax 
or codeblock syntax):

   - mmd: {{file.md}} 
   - panflute filter: $include ../somefolder/somefile 
   - Marked2: <<[relative/path/to/some_other_file.md] 

On Saturday, February 11, 2017 at 2:00:57 AM UTC-8, BP wrote:

Kolen, how do you propose that transclusion through link syntax would 
> distinguish between images and transclusions with the exact same syntax? By 
> looking at the file extension? That would seem rather fragile to me. I 
> experimented a bit yesterday with a (Perl) filter which would do 
> transclusions with divs or code blocks, since I ran into the problem that 
> you may want to specify a custom command line, which you could then do in 
> the code block body (split into tokens with Text::ParseWords, an ancient 
> module which parses a string into 'words' with shell-like semantics.) 
> However I think that you should also be able to specify a default command 
> line, per input format, which I as you might have guessed intend to have 
> declared in metadata.
>
> /bpj
>
>
> Den 10 feb 2017 23:20 skrev "Kolen Cheung" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
> <javascript:>>:
>
>> Yes, basically MMD's transclusion is a preprocessor. Marked (a markdown 
>> previewer on Mac) works very similarly, and support both MMD and Marked 
>> syntax.
>>
>> That kind of transclusion works best as a preprocessor. I think there's 
>> another thread here that mention another tool to include files that's also 
>> a preprocessor. Replicating something like that in the markdown reader does 
>> not make sense. (limited support of it might make sense though. i.e. same 
>> syntax but different implementation.)
>>
>> Some more comment on MMD: there's a lot of bad things about MMD e.g. MMD 
>> syntax to include raw LaTeX is very bad. MMD's design is kind of like 
>> gluing a lot of nice syntax together by duct tape. It works, but its 
>> limitation will shows as you need to push it (and multi-output document 
>> will fall apart very soon). For those who think native support of 
>> transclusion in MMD makes your life easier, 3rd party support of anything 
>> (including "transclusion") in pandoc scales much better with complexity. 
>> Unofficial features implemented through pandoc's filter system is not as 
>> bad as it sounds. In fact this is one of the best feature of pandoc. Give 
>> existing "include" filters a try before native include is provided. e.g. 
>> one of the panflute's example also did something like MMD's transclusion 
>> (with a different syntax).
>>
>> --
>> 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-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>.
>> To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org 
>> <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pandoc-discuss/9a7522f6-413d-4c15-bb4b-62a07a4b09b4%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> ​

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/39e933be-e818-4eed-a73f-93c16f14e4af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: ANN: pandoc 1.19.1, and plans for 2.0

[BP Jonsson]

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

With command line I mean that a filter in order to convert the included
file to an AST the filter has to call out to pandoc with the same or
different options as the pandoc process which invoked the filter in the
first place. Moreover if inclusion is going to be recursive the filter may
need to add itself to those options, and append its own metadata
configuration to the included file if that file is markdown.

/bpj


Den 12 feb 2017 01:04 skrev "Kolen Cheung" <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

What do you mean by command line? Does it mean that e.g. if a file is rst,
the custom command line calls rst2html instead to produce the html output?
(or some other pandoc cli options)

I think this problem (on how to know what to do with the file) is a
reason idea:
include files and long tables · Issue #553 · jgm/pandoc
<https://github.com/jgm/pandoc/issues/553> isn’t resolved yet. I think here
and there people have suggested using the image syntax for other file
inclusion. e.g. one of the CSV filter did use the image syntax to include a
CSV table.

The main problem is while the image syntax is (probably) the only markdown
syntax that points to a file, it isn’t really included (so it is still a
pure function without IO). So if we overload the image syntax to do this,
we are doing 2 fundamentally different operations on the same syntax. I
think that’s why @jgm is hesitate about it.

If I were to write a transclusion filter using the image syntax, one thing
I would worry is what if the included file extensions are one of the valid
pandoc input formats. e.g. in markdown source, .html is included. Should it
calls pandoc to parse it in AST for any output, or should it be pasted as
raw HTML (and hence only for HTML output). The later approach would be
problematic for HTML-like output, say, ePub (or even HTML5). In this case I
think pandoc with not put the raw HTML (raw block with format html) in the
epub output. (I tested something like this earlier on but forgot the exact
behavior. I remember that it will have problems on other html-like output
though.)

I think this is similar to what you describe — essentially how a certain
file kind should be handled, when there can be multiple ways to handle
that. Luckily image syntax has attributes, and we can also use metadata to
do it. I think the major problem here is how to design it (workflow and
syntax to use in attribute/metadata) to please everyone.

After thinking about all these, I think a “native” syntax of include, that
only paste an included files (recursively) as is, will be a better idea.
There’s much less thing to worry about and it won’t overload the image
syntax to do completely different things.

Just to mention some notable markdown-ish include syntax (none of these are
using existing pandoc markdown syntax, which is proposed e.g. image syntax
or codeblock syntax):

   - mmd: {{file.md}}
   - panflute filter: $include ../somefolder/somefile
   - Marked2: <<[relative/path/to/some_other_file.md]

On Saturday, February 11, 2017 at 2:00:57 AM UTC-8, BP wrote:

Kolen, how do you propose that transclusion through link syntax would
> distinguish between images and transclusions with the exact same syntax? By
> looking at the file extension? That would seem rather fragile to me. I
> experimented a bit yesterday with a (Perl) filter which would do
> transclusions with divs or code blocks, since I ran into the problem that
> you may want to specify a custom command line, which you could then do in
> the code block body (split into tokens with Text::ParseWords, an ancient
> module which parses a string into 'words' with shell-like semantics.)
> However I think that you should also be able to specify a default command
> line, per input format, which I as you might have guessed intend to have
> declared in metadata.
>
> /bpj
>
>
> Den 10 feb 2017 23:20 skrev "Kolen Cheung" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
>> Yes, basically MMD's transclusion is a preprocessor. Marked (a markdown
>> previewer on Mac) works very similarly, and support both MMD and Marked
>> syntax.
>>
>> That kind of transclusion works best as a preprocessor. I think there's
>> another thread here that mention another tool to include files that's also
>> a preprocessor. Replicating something like that in the markdown reader does
>> not make sense. (limited support of it might make sense though. i.e. same
>> syntax but different implementation.)
>>
>> Some more comment on MMD: there's a lot of bad things about MMD e.g. MMD
>> syntax to include raw LaTeX is very bad. MMD's design is kind of like
>> gluing a lot of nice syntax together by duct tape. It works, but its
>> limitation will shows as you need to push it (and multi-output document
>> will fall apart very soon). For those who think native support of
>> transclusion in MMD makes your life easier, 3rd party support of anything
>> (including "transclusion") in pandoc scales much better with complexity.
>> Unofficial features implemented through pandoc's filter system is not as
>> bad as it sounds. In fact this is one of the best feature of pandoc. Give
>> existing "include" filters a try before native include is provided. e.g.
>> one of the panflute's example also did something like MMD's transclusion
>> (with a different syntax).
>>
>> --
>> 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-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/pandoc-discuss/9a7522f6-413d-4c15-bb4b-62a07a4b09b4%40go
>> oglegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> ​

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/
msgid/pandoc-discuss/39e933be-e818-4eed-a73f-93c16f14e4af%40googlegroups.com
<https://groups.google.com/d/msgid/pandoc-discuss/39e933be-e818-4eed-a73f-93c16f14e4af%40googlegroups.com?utm_medium=email&utm_source=footer>
.

For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAFC_yuR_2ZUxeznyuxLAEinWY6SUrpswcSUZWn%3D-QvV10DdBdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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