$thusly would probably be a class .csv and recognition of a class .code for when you want the code block to be left as an actual code block.
John, this may be something that could stand to be in the faq:
----------------------
Q. Can I write csv content in my input file and have Pandoc render it as
a table?
A. Pandoc doesn't support this directly, but you *can* put your csv data
into a delimited code block, mark the block $thusly, then use then use a
filter to process these specially-marked blocks. For example, {snip}.
A nice benefit of this is that it will degrade gracefully if the
document is then processed without using the filter.
There may be other options available on the [Pandoc Extras page],
including ... {snip preprocessors, scripts, ...?}
----------------------
Not sure about what "$thusly" would be though. Also have not used Pandoc
filters before.
-- John
On Fri, May 20, 2016, at 02:36 PM, John MACFARLANE wrote:
> +++ Martin Fenner [May 20 16 12:38 ]:
> > I would rather use Pandoc with a CSV reader, but my Haskell isn't good
> > enough to write one.
>
> This would be a pretty easy project for someone trying to
> learn Haskell; maybe someone on the list wants to try it?
> The cassava library works well for csv parsing.
>
> > For the second use case I see a clear advantage of CSV over the various
> > attempts to format tables in markdown (simple_tables, multiline_tables,
> > grid_tables, pipe_tables). Everyone (and many tools) understands the
> > CSV format, and you can do most of the things with CSV that the other
> > table formats allow (multi-column formats and column alignment are a
> > bit trickier). This has been done before using Pandoc filters, but I
> > think a Pandoc "csv_tables" Pandoc extension would make this easier for
> > the casual user. Using the grid_tables example from the Pandoc
> > documentation, this could look like this:
> >
> > : Sample csv table.
> > ,,,
> > Fruit,Price,Advantages
> > Bananas,$1.34,- built-in wrapper\n- bright color
> > Oranges,$2.10, - cures scurvy\n- tasty
> > ,,,
>
> I think that using a filter that processes specially marked
> code blocks is a better way to go than introducing yet
> another delimited block type.
>
> For one thing, this will degrade much more gracefully when
> you render it with a standard markdown renderer.
> (The CSV will show up as code rather than garbage.)
>
> One could think about integrating the filter into pandoc
> itself, as an option, but the code and syntax would not
> have to be different, I think.
>
>
> --
> 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
> To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pandoc-discuss/20160520183616.GB95956%40protagoras.berkeley.edu.
> 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/1463772643.1938448.614055033.793EA897%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.