While I appreciate the intent behind the suggestion to use protocols like this i still think that a pseudo-attribute 'format' which can/will be discarded is preferable to pseudo-protocols because (1) if you are going to use a URL rather than a path most include files will properly have a `file://` URL and (2) in principle it should be possible to include a markdown/csv/whatever file from a remote location, and in that case there will be a different protocol like http or ftp. thus something like this is safer, more robust, and clearer: ![file description or caption](path/or/url){format=markdown} torsdag 26 maj 2016 skrev Sergio Correia : > A bit late to the party, but: > > 1) An alternative to using extensions to indicate the required action > would be to use protocols. > For instance, this example pandoc filter: > > http://scorreia.com/software/panflute/guide.html#calling-external-programs > > Thus, you can do > > [Caption of the Table](csv://some/path.csv) > > Or maybe > > [some/path.md](include://) > > > > 2) For tables, I would also suggest to take a look at this filter: > > http://scorreia.com/software/panflute/guide.html#yaml-code-blocks > > It allows markdown like this: > > Some text > > ~~~ csv > title: Some Title > has-header: True > --- > Col1, Col2, Col3 > 1, 2, 3 > 10, 20, 30 > ~~~ > > More text > > > This combines pure CSV with options set up in YAML, so you can add > captions and customize the table. > > Since the CSV is handled by python's CSV library, it is quite powerful. > Also, complex things like selecting a subset of rows/cols, or adding > format, could be done in 1-2 lines of code. If you are interested, shoot me > an email and I can add a more complex working example. > > Cheers, > S > > > On Wednesday, May 25, 2016 at 7:18:10 AM UTC-7, Frank Colcord wrote: >> >> I'd like to second this proposal. As a simple Pandoc user, these would be >> very helpful: >> >> >> ![an image](foo.jpg) >> >> ![an include](foo.txt) >> >> ![a csv to be rendered as a table](foo.csv) >> >> thanks for all the development. >> >> Frank >> >> On Friday, May 20, 2016 at 6:55:10 PM UTC+1, jgabriele wrote: >>> >>> Hi Martin, >>> >>> There's also [issue 553](https://github.com/jgm/pandoc/issues/553 >>> >>> ). >>> >>> Personally, I think I like (from that issue thread) anton-k's original >>> idea: >>> >>> ![an image](foo.jpg) >>> >>> ![an include](foo.txt) >>> >>> ![a csv to be rendered as a table](foo.csv) >>> >>> (that is, based on filename extension) >>> >>> Those seem sensible, symmetrical, easy to remember, and I think fit well >>> with what pandoc already does (`![]()` is already like an include). >>> >>> As for a syntax to allow writing your csv data right into your md file, >>> ... Pandoc already supports a generous number of table formats that are >>> pretty easy to type. And for larger tables that you might be tempted to >>> copy/paste in, might be better easier to bang-include them (as in, >>> `![]()`), rather than muck up your pretty markdown file with a giant bunch >>> of csv data. :) >>> >>> -- John >>> >>> >>> >>> >>> On Fri, May 20, 2016, at 05:38 AM, Martin Fenner wrote: >>> >>> Dear group, >>> >>> The topic of CSV support in Pandoc has come up several times on this >>> list, includes this thread from 2014: >>> https://groups.google.com/forum/#!topic/pandoc-discuss/kBdJU_JktzI >>> >>> Since last year I work for an organisation that frequently deals with >>> tabular data (and helped organize CSVconf earlier this month), and I have >>> done some thinking on how CSV could fit into Pandoc. I see two important >>> use cases: >>> >>> * CSV reader that converts to tables in HTML, docx, latex, etc. >>> * CSV has a format to describe tables in markdown >>> >>> For the first use case I wrote a hack for the Jekyll blogging platform >>> this week that turns CSV files into markdown grid tables format that is >>> then processed by Pandoc (https://github.com/datacite/jekyll-csvy). I >>> would rather use Pandoc with a CSV reader, but my Haskell isn't good enough >>> to write one. But for now I can generate blog posts directly from CSV >>> files. Other people have done similar things with Pandoc and CSV. >>> >>> 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 like three commas on a new line to indicate the start and end of a >>> table, but that is of course open for discussion. The format is much easier >>> to read and edit for humans compared to grid tables, the only tricky bit is >>> maybe the \n for multiline columns. I would think we could add metadata to >>> the fenced table blog similar to code blocks, e.g. >>> >>> ,,,{ #mytable .numberRows } >>> >>> One challenge with CSV is that it is an ill-defined format somewhat >>> similar to markdown before CommonMark. It may make things easier to only >>> support a specific CSV variant (e.g. comma as separator, header required, >>> comment lines not allowed). >>> >>> Thoughts? >>> >>> Best, >>> >>> Martin >>> >>> >>> >>> >>> >>> -- >>> 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/msgid/pandoc-discuss/20BF19CB-A2B0-4B19-A749-D750CDD89736%40martinfenner.org >>> >>> . >>> 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/b9147aed-bf8e-4136-8fd2-949dea1034ea%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/CADAJKhATyS6Nu49vbs-zp5UU2_05_dsPtzV2VHEsJ-q7i2VZPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.