Proposal: Alternate Granular Package Organization

Proposal: Alternate Granular Package Organization

[Getty Ritter]

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

This kind of suggestion might have already come up, but I couldn't find it 
being discussed either here or elsewhere, so I'm going to suggest it here:

I love both Pandoc-the-program and Pandoc-the-library, and use them all the 
time. One minor complaint I have, though, is that Pandoc-the-library is 
very large, and very often, I'm using only a small amount of the library 
(e.g. two or three readers and a single writer) and yet have to pull in and 
compile a large amount of code that my application will not use.

One way of alleviating this would be to split the current `pandoc` package 
into smaller packages with a tighter focus. Already, there is `pandoc` 
which depends on `pandoc-types`; `pandoc` could be further decomposed into 
a `pandoc-core`, a whole family of `pandoc-reader-foo` and 
`pandoc-writer-foo` modules for each individual reader and writer. Finally, 
the `pandoc` module would import `pandoc-core` as well as all the readers 
and writers and produce the executable and re-export the relevant modules.

This way, a single application that only wants to use Pandoc to (say) 
convert LaTeX to HTML could get by with dependencies on `pandoc-core`, 
`pandoc-reader-latex`, and `pandoc-writer-html`. I did some rough 
lines-of-code measurements, and it looks like this would avoid having to 
compile more than three-quarters of what currently goes into `pandoc`, or 
more than 18000 lines of code that are (to that application) unnecessary.

As another benefit, it would also mean more granularity in development of 
individual readers and writers: for example, issues on github could be made 
in the repository pertaining to each individual reader or writer, instead 
of keeping them in one large pandoc-related repository.

Finally, by having a `pandoc` package which produces the executable as well 
as importing and re-exporting everything, it could still expose an 
identical interface to programs that don't want or need a more granular 
interface. Existing uses of the Pandoc library would not break, but future 
uses could take advantage of the more granular structure.

The major downside I can forsee to this is that multiple repositories will 
have to be kept in sync, which shouldn't be infeasible but will probably be 
a bit more work than present. Additionally, building the full Pandoc 
library will now mean fetching dozens of smaller packages, which will 
nevertheless involve some extra overhead than before. There may be other 
downsides I haven't considered, and additionally, there may be other ways 
of splitting apart the library that I haven't considered.

If this is desirable, or even just interesting to people, I'd be happy to 
do the splitting myself and put the resulting modules in a repository 
somewhere so that people can experiment with this alternate 
organization—but I wanted to propose it for discussion first. Is there any 
immediate feedback on this idea? Has this or something like it been 
proposed anywhere before, and if so, was there a discussion or consensusus 
then? Would it be worthwhile to experiment with this?

Thank you for your time and consideration!

—Getty

-- 
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/995575dc-486c-4214-a36c-1c965de91df9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: Proposal: Alternate Granular Package Organization

[Ivan Lazar Miljenovic]

On 25 March 2015 at 08:44, Getty Ritter <gettyritter-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> This kind of suggestion might have already come up, but I couldn't find it
> being discussed either here or elsewhere, so I'm going to suggest it here:
>
> I love both Pandoc-the-program and Pandoc-the-library, and use them all the
> time. One minor complaint I have, though, is that Pandoc-the-library is very
> large, and very often, I'm using only a small amount of the library (e.g.
> two or three readers and a single writer) and yet have to pull in and
> compile a large amount of code that my application will not use.
>
> One way of alleviating this would be to split the current `pandoc` package
> into smaller packages with a tighter focus. Already, there is `pandoc` which
> depends on `pandoc-types`; `pandoc` could be further decomposed into a
> `pandoc-core`, a whole family of `pandoc-reader-foo` and `pandoc-writer-foo`
> modules for each individual reader and writer. Finally, the `pandoc` module
> would import `pandoc-core` as well as all the readers and writers and
> produce the executable and re-export the relevant modules.

Without having looked at the pandoc code any time recently... that
sounds like a *lot* of fragmentation for very little return (at the
very least, I see no need to split the -reader-foo and -writer-foo
modules into separate packages).  Especially since I would think that
the vast majority of users would be wanting the program rather than
the library.  Not to mention the question about how to deal with the
current internal-only modules.

Even then, many would have common dependencies (e.g. all the various
html-based outputs would want to use the same html/networking
libraries), so how would you structure those to have the same
dependencies (lots of copy-pasta with manual fiddling every time a
dependency had a version bump)?

Just to get an idea, I got the latest version of pandoc from package
and timed how long it took to install all the dependencies (not
including tests, etc.) into a new sandbox vs compiling pandoc itself:

$ time cabal install --only-dependencies:
...
real    15m6.075s
user    43m2.500s
sys    1m56.304s

$ cabal configure
...

$ time cabal build
...
real    3m50.379s
user    9m38.405s
sys    1m50.825s

(actually, it would be a bit longer than this, as I was doing this in
/tmp and I ran out of space just after the last module was compiled
but before the shared library could be linked together)

It's obvious that the dependency building time is rather large; this
might be alleviated by re-using some existing dependencies (e.g.
Pandoc currently uses parsec as its parser, but it also depends upon
aeson which uses attoparsec, so both end up being installed) and being
more explicit about flags (the dependencies included wai and
wai-extras, which are only needed by the `trypandoc` executable;
adding a `manual: True` statement to the flag for it might help cabal
realise it shouldn't install dependencies like this unless explicitly
requested to do so).

However, if you're developing with pandoc in multiple
libraries/executables, one option to help would be to use a common
sandbox to store all of this so you don't have to keep compiling the
dependencies.

>
> This way, a single application that only wants to use Pandoc to (say)
> convert LaTeX to HTML could get by with dependencies on `pandoc-core`,
> `pandoc-reader-latex`, and `pandoc-writer-html`. I did some rough
> lines-of-code measurements, and it looks like this would avoid having to
> compile more than three-quarters of what currently goes into `pandoc`, or
> more than 18000 lines of code that are (to that application) unnecessary.
>
> As another benefit, it would also mean more granularity in development of
> individual readers and writers: for example, issues on github could be made
> in the repository pertaining to each individual reader or writer, instead of
> keeping them in one large pandoc-related repository.
>
> Finally, by having a `pandoc` package which produces the executable as well
> as importing and re-exporting everything, it could still expose an identical
> interface to programs that don't want or need a more granular interface.
> Existing uses of the Pandoc library would not break, but future uses could
> take advantage of the more granular structure.
>
> The major downside I can forsee to this is that multiple repositories will
> have to be kept in sync, which shouldn't be infeasible but will probably be
> a bit more work than present. Additionally, building the full Pandoc library
> will now mean fetching dozens of smaller packages, which will nevertheless
> involve some extra overhead than before. There may be other downsides I
> haven't considered, and additionally, there may be other ways of splitting
> apart the library that I haven't considered.
>
> If this is desirable, or even just interesting to people, I'd be happy to do
> the splitting myself and put the resulting modules in a repository somewhere
> so that people can experiment with this alternate organization—but I wanted
> to propose it for discussion first. Is there any immediate feedback on this
> idea? Has this or something like it been proposed anywhere before, and if
> so, was there a discussion or consensusus then? Would it be worthwhile to
> experiment with this?
>
> Thank you for your time and consideration!
>
> —Getty
>
> --
> 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/995575dc-486c-4214-a36c-1c965de91df9%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
http://IvanMiljenovic.wordpress.com

-- 
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/CA%2Bu6gbz01Wn4DQ2KvFYVOM0Th-tp%2B5WsYxnKkyNEGH8XmQ4j7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Alternate Granular Package Organization

[Ivan Lazar Miljenovic]

On 25 March 2015 at 10:04, Ivan Lazar Miljenovic
<ivan.miljenovic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> $ time cabal install --only-dependencies:
> ...
> real    15m6.075s
> user    43m2.500s
> sys    1m56.304s
>
> $ cabal configure
> ...

I checked what happened if these two commands were flipped:

$ cabal configure
...

$ time cabal install --only-dependencies
...
real    9m49.014s
user    29m29.900s
sys    1m22.710s

Which is a tad better.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
http://IvanMiljenovic.wordpress.com

Re: Proposal: Alternate Granular Package Organization

[Manolo Martínez]

I just wanted to +1 this. It would also help getting people (students,
for example) to try out pandoc with less overhead.

M

On 03/24/15 at 02:44pm, Getty Ritter wrote:
> This kind of suggestion might have already come up, but I couldn't find it 
> being discussed either here or elsewhere, so I'm going to suggest it here:
> 
> I love both Pandoc-the-program and Pandoc-the-library, and use them all the 
> time. One minor complaint I have, though, is that Pandoc-the-library is 
> very large, and very often, I'm using only a small amount of the library 
> (e.g. two or three readers and a single writer) and yet have to pull in and 
> compile a large amount of code that my application will not use.
> 
> One way of alleviating this would be to split the current `pandoc` package 
> into smaller packages with a tighter focus. Already, there is `pandoc` 
> which depends on `pandoc-types`; `pandoc` could be further decomposed into 
> a `pandoc-core`, a whole family of `pandoc-reader-foo` and 
> `pandoc-writer-foo` modules for each individual reader and writer. Finally, 
> the `pandoc` module would import `pandoc-core` as well as all the readers 
> and writers and produce the executable and re-export the relevant modules.
> 
> This way, a single application that only wants to use Pandoc to (say) 
> convert LaTeX to HTML could get by with dependencies on `pandoc-core`, 
> `pandoc-reader-latex`, and `pandoc-writer-html`. I did some rough 
> lines-of-code measurements, and it looks like this would avoid having to 
> compile more than three-quarters of what currently goes into `pandoc`, or 
> more than 18000 lines of code that are (to that application) unnecessary.
> 
> As another benefit, it would also mean more granularity in development of 
> individual readers and writers: for example, issues on github could be made 
> in the repository pertaining to each individual reader or writer, instead 
> of keeping them in one large pandoc-related repository.
> 
> Finally, by having a `pandoc` package which produces the executable as well 
> as importing and re-exporting everything, it could still expose an 
> identical interface to programs that don't want or need a more granular 
> interface. Existing uses of the Pandoc library would not break, but future 
> uses could take advantage of the more granular structure.
> 
> The major downside I can forsee to this is that multiple repositories will 
> have to be kept in sync, which shouldn't be infeasible but will probably be 
> a bit more work than present. Additionally, building the full Pandoc 
> library will now mean fetching dozens of smaller packages, which will 
> nevertheless involve some extra overhead than before. There may be other 
> downsides I haven't considered, and additionally, there may be other ways 
> of splitting apart the library that I haven't considered.
> 
> If this is desirable, or even just interesting to people, I'd be happy to 
> do the splitting myself and put the resulting modules in a repository 
> somewhere so that people can experiment with this alternate 
> organization—but I wanted to propose it for discussion first. Is there any 
> immediate feedback on this idea? Has this or something like it been 
> proposed anywhere before, and if so, was there a discussion or consensusus 
> then? Would it be worthwhile to experiment with this?
> 
> Thank you for your time and consideration!
> 
> —Getty
> 
> -- 
> 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/995575dc-486c-4214-a36c-1c965de91df9%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/20150325083551.GB9957%40beagle.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Alternate Granular Package Organization

[John Muccigrosso]

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

I know of at least one markdown editor which hasn't added pandoc as an 
export option because of its size. Presumably all they'd want to add is the 
writer to go from .md to something(everything?) else.

-- 
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/599889b8-3d60-4153-9a0a-8229b6e429e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: Proposal: Alternate Granular Package Organization

[Ivan Lazar Miljenovic]

On 27 March 2015 at 01:40, John Muccigrosso <jmuccigr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I know of at least one markdown editor which hasn't added pandoc as an
> export option because of its size. Presumably all they'd want to add is the
> writer to go from .md to something(everything?) else.

Except that IIUC, the proposal from Getty was just to split up the
*library* and keep the executable as-is.  Furthermore, unless the
editor itself was written in Haskell (or used some kind of
Haskell-to-foo bindings) I imagine it would be using the executable
and not the library.

Having an extensible executable seems to be a different situation than
this proposal (which admittedly would have its own benefits), though
I'm not sure how that would work (sub-executables ala how git
interprets "git foo" as running "git-foo"?).

The current list of packages on Hackage that use pandoc as a library
can be found here: http://packdeps.haskellers.com/reverse/pandoc  As
it is, many of these seem to not be using the latest version of Pandoc
(one of which is admittedly mine; looks like I didn't notice the
version bump) and as such may not be maintained/used any longer (even
the ones that don't say so explicitly but instead have open-ended
dependencies are likely to be those that aren't maintained as the API
for pandoc has changed and as such those packages are likely not to
build with newer versions of pandoc).  This seems to argue that -
baring private/internal projects - most people are *not* using pandoc
as a library.

>
> --
> 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/599889b8-3d60-4153-9a0a-8229b6e429e3%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
http://IvanMiljenovic.wordpress.com

Re: Proposal: Alternate Granular Package Organization

[Vincent Zhao]

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

Hi All,

Sorry to bother, I'm a student who want to take this task as my GSOC 
project. I've published a proposal here, and also the homepage of GSOC.

Hope to hear from you guys!

On Wednesday, March 25, 2015 at 5:44:37 AM UTC+8, Getty Ritter wrote:
>
> This kind of suggestion might have already come up, but I couldn't find it 
> being discussed either here or elsewhere, so I'm going to suggest it here:
>
> I love both Pandoc-the-program and Pandoc-the-library, and use them all 
> the time. One minor complaint I have, though, is that Pandoc-the-library is 
> very large, and very often, I'm using only a small amount of the library 
> (e.g. two or three readers and a single writer) and yet have to pull in and 
> compile a large amount of code that my application will not use.
>
> One way of alleviating this would be to split the current `pandoc` package 
> into smaller packages with a tighter focus. Already, there is `pandoc` 
> which depends on `pandoc-types`; `pandoc` could be further decomposed into 
> a `pandoc-core`, a whole family of `pandoc-reader-foo` and 
> `pandoc-writer-foo` modules for each individual reader and writer. Finally, 
> the `pandoc` module would import `pandoc-core` as well as all the readers 
> and writers and produce the executable and re-export the relevant modules.
>
> This way, a single application that only wants to use Pandoc to (say) 
> convert LaTeX to HTML could get by with dependencies on `pandoc-core`, 
> `pandoc-reader-latex`, and `pandoc-writer-html`. I did some rough 
> lines-of-code measurements, and it looks like this would avoid having to 
> compile more than three-quarters of what currently goes into `pandoc`, or 
> more than 18000 lines of code that are (to that application) unnecessary.
>
> As another benefit, it would also mean more granularity in development of 
> individual readers and writers: for example, issues on github could be made 
> in the repository pertaining to each individual reader or writer, instead 
> of keeping them in one large pandoc-related repository.
>
> Finally, by having a `pandoc` package which produces the executable as 
> well as importing and re-exporting everything, it could still expose an 
> identical interface to programs that don't want or need a more granular 
> interface. Existing uses of the Pandoc library would not break, but future 
> uses could take advantage of the more granular structure.
>
> The major downside I can forsee to this is that multiple repositories will 
> have to be kept in sync, which shouldn't be infeasible but will probably be 
> a bit more work than present. Additionally, building the full Pandoc 
> library will now mean fetching dozens of smaller packages, which will 
> nevertheless involve some extra overhead than before. There may be other 
> downsides I haven't considered, and additionally, there may be other ways 
> of splitting apart the library that I haven't considered.
>
> If this is desirable, or even just interesting to people, I'd be happy to 
> do the splitting myself and put the resulting modules in a repository 
> somewhere so that people can experiment with this alternate 
> organization—but I wanted to propose it for discussion first. Is there any 
> immediate feedback on this idea? Has this or something like it been 
> proposed anywhere before, and if so, was there a discussion or consensusus 
> then? Would it be worthwhile to experiment with this?
>
> Thank you for your time and consideration!
>
> —Getty
>

-- 
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/2e255e37-4cb1-48ac-8153-2d1af529e203%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: Proposal: Alternate Granular Package Organization

[John MacFarlane]

This is a well thought-out proposal, and clearly there would be some
advantages to having more modularity.  But I don't think I'd be in favor
the change, for practical reasons (mostly summed up by Ivan in his
reply).  Having to maintain dozens of repositories for the project, each
with separate issue trackers, and dozens of separate libraries on
Hackage, sounds like a lot more work for the maintainers.  (And most
users won't know which of the many issue trackers to use for their
reports -- I already get lots of reports on the pandoc repository for
issues with pandoc-citeproc, texmath, or highlighting-kate -- so in
practice the issues relevant to a module will be spread to several
separate trackers.) Since I have limited time to devote to pandoc, I am
reluctant to make a change that would make maintaining the project a lot
less convenient.

John

+++ Getty Ritter [Mar 24 15 14:44 ]:
>This kind of suggestion might have already come up, but I couldn't find it
>being discussed either here or elsewhere, so I'm going to suggest it here:
>
>I love both Pandoc-the-program and Pandoc-the-library, and use them all the
>time. One minor complaint I have, though, is that Pandoc-the-library is
>very large, and very often, I'm using only a small amount of the library
>(e.g. two or three readers and a single writer) and yet have to pull in and
>compile a large amount of code that my application will not use.
>
>One way of alleviating this would be to split the current `pandoc` package
>into smaller packages with a tighter focus. Already, there is `pandoc`
>which depends on `pandoc-types`; `pandoc` could be further decomposed into
>a `pandoc-core`, a whole family of `pandoc-reader-foo` and
>`pandoc-writer-foo` modules for each individual reader and writer. Finally,
>the `pandoc` module would import `pandoc-core` as well as all the readers
>and writers and produce the executable and re-export the relevant modules.
>
>This way, a single application that only wants to use Pandoc to (say)
>convert LaTeX to HTML could get by with dependencies on `pandoc-core`,
>`pandoc-reader-latex`, and `pandoc-writer-html`. I did some rough
>lines-of-code measurements, and it looks like this would avoid having to
>compile more than three-quarters of what currently goes into `pandoc`, or
>more than 18000 lines of code that are (to that application) unnecessary.
>
>As another benefit, it would also mean more granularity in development of
>individual readers and writers: for example, issues on github could be made
>in the repository pertaining to each individual reader or writer, instead
>of keeping them in one large pandoc-related repository.
>
>Finally, by having a `pandoc` package which produces the executable as well
>as importing and re-exporting everything, it could still expose an
>identical interface to programs that don't want or need a more granular
>interface. Existing uses of the Pandoc library would not break, but future
>uses could take advantage of the more granular structure.
>
>The major downside I can forsee to this is that multiple repositories will
>have to be kept in sync, which shouldn't be infeasible but will probably be
>a bit more work than present. Additionally, building the full Pandoc
>library will now mean fetching dozens of smaller packages, which will
>nevertheless involve some extra overhead than before. There may be other
>downsides I haven't considered, and additionally, there may be other ways
>of splitting apart the library that I haven't considered.
>
>If this is desirable, or even just interesting to people, I'd be happy to
>do the splitting myself and put the resulting modules in a repository
>somewhere so that people can experiment with this alternate
>organization—but I wanted to propose it for discussion first. Is there any
>immediate feedback on this idea? Has this or something like it been
>proposed anywhere before, and if so, was there a discussion or consensusus
>then? Would it be worthwhile to experiment with this?
>
>Thank you for your time and consideration!
>
>—Getty
>
>-- 
>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/995575dc-486c-4214-a36c-1c965de91df9%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/20150327004511.GA35684%40localhost.hsd1.ca.comcast.net.
For more options, visit https://groups.google.com/d/optout.