Re: Filter with arguments

[BP Jonsson <bpjonsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Den 2017-01-07 kl. 00:10, skrev Kolen Cheung:
> In addition, the above discussion hasn’t covered the case that one might
> want to write a program that can acts as both a filter and a standalone
> cli.

Is that a realistic scenario? Either the program would have to 
expect pandoc-style JSON as input when used standalone, or it 
could check whether the input is (pandoc-style) JSON and do 
something completely different if it isn't! I have some scripts 
which do essentially the same things to HTML documents as some of 
my pandoc filters, but they use entirely different libraries: an 
HTML parser instead of a JSON parser, and a different library for 
manipulating the data structure produced by the respective parser.

Explicit piping of `-t json` output is also a rather outlandish 
problem: it is now effectively only used by filter authors 
debugging their filters, who then really should not expect to not 
have to specify the output format as an argument to the program on 
the rhs of the pipe.

As for the problem of metadata being interpreted as markdown the 
code which Pandoc::Elements uses to convert metadata to plain data 
is not too complicated (the `string` methods are already there for 
other purposes anyway):

     sub Pandoc::Document::metavalue {
         my $meta = $_[0]->meta;
         return { map { $_ => $meta->{$_}->metavalue } keys %$meta }
     }

     sub Pandoc::Document::MetaMap::metavalue {
         my $map = $_[0]->{c};
         return { map { $_ => $map->{$_}->metavalue } keys %$map }
     }

     sub Pandoc::Document::MetaList::metavalue {
         [ map { $_->metavalue } @{$_[0]->{c}} ]
     }

     sub Pandoc::Document::MetaInlines::metavalue {
         join '', map { $_->string } @{$_[0]->{c}}
     }

     sub Pandoc::Document::MetaBlocks::metavalue {
         join "\n", map { $_->string } @{$_[0]->{c}}
     }

     sub Pandoc::Document::MetaString::metavalue {
         $_[0]->{c}
     }

     sub Pandoc::Document::MetaBool::metavalue {
         $_[0]->{c} ? 1 : 0
     }

As for hierarchical metadata structures being ugly I don't think 
they are. They create a namespace and keep related data together 
without relying on sorting order, and often hierarchical data make 
things easier to do compared to non-hierarchical data. That's the 
reason data structures in general and hierarchical data structures 
in particular were invented. At a user experience level they keep 
each mapping key shorter and less repetitive, since otherwise you 
would in principle have to make every key a 'path' in order to 
avoid field name clashes. I have been in the situation of having 
to emulate hierarcical data structures in languages which don't 
have them, or even associative arrays, in languages which don't 
have them. It's no fun.
Consider a case where the user would supply different data to be 
used in processing elements with different classes with different 
output formats, in an hierachical version

     myfilter:
       class:
         foo:
           latex: ...
           html: ...
         bar:
           latex: ...
           html: ...
         ...
       ...

and a 'non-hierarchical' version

     myfilter-class-foo-latex: ...
     myfilter-class-foo-html: ...
     myfilter-class-bar-latex: ...
     myfilter-class-bar-html: ...

I vastly prefer the first both as a document author and as a 
filter author!

/bpj


-- 
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/c21c773d-c958-2e55-725d-90863f5f9792%40gmail.com.
For more options, visit https://groups.google.com/d/optout.