Closed egberts closed 2 years ago
The smart quotes or the hyphenation features of m.htmlsanity
plugin (I assume that's what you mean by "htmlify") works on docutils text nodes -- i.e., it relies on docutils themselves providing proper semantic structure of the document, what is a paragraph, what is a literal block, what is some raw HTML that shouldn't be touched, etc.
So e.g., if a reST document looks like this:
Some text with :code:`some inline code`, and
.. math::
a + math = equation
And a code block:
.. code:: py
int a = 3;
Then the plugin will know that it shouldn't touch some inline code
, a + math = equation
and int a = 3;
, because that's not semantically a text node. But the rest is, and so it gets processed.
Which means, if some random plugin decides to completely ignore the reST markup and the docutils semantic structures and goes instead with a regex match over the generated HTML, this can't work together. At all. The designated way to implement plugins that can interoperate with other reST functionality is to implement a custom text role, or a directive. So, say, if instead of
[jtable]
Year,Make,Model,Length
1994,Ford,E350,2.34
2000,Mercury,Cougar,2.38
[/jtable]
it'd be a
.. jtable::
Year,Make,Model,Length
1994,Ford,E350,2.34
2000,Mercury,Cougar,2.38
and then the plugin would be implemented as a directive, parsing whatever it needs to parse and produce a docutils node tree with a table, rows and cells, then yes, that would work. And as a bonus, any hyphenation or smart quotes would magically work inside the table cells as well. Or, even, any other reST markup (like emphasis, inline math, inline code...), with a minor extra effort done from the plugin side.
In other words, the [jtable]
way works probably well enough for Markdown, where it's all an unregulated underspecified mess of every plugin recognizing its own markup and the things somehow kinda working together (or not), but it doesn't match well to how reST and docutils work. On the other hand, if a plugin follows how docutils work, it becomes much more powerful than Markdown could ever get.
If you want to take a stab on updating the No need it seems, everything done already, see comment below.just_table
plugin to be docutils-friendly, I can give you some pointers. I might eventually also have a need for more advanced tables that don't need a rigid ASCII-art structure, but given my constant task overload I can't even estimate when I would get to implementing that.
Oh, I knew there was something to fit your need already -- the reST .. csv-table::
directive. So the above would be directly doable as ... just this, I suppose?
.. csv-table::
Year,Make,Model,Length
1994,Ford,E350,2.34
2000,Mercury,Cougar,2.38
With no need for any external tool, or having to write your own plugin. And it can apparently read external CSV files too, which jtable
has just as a TODO.
Thanks.... That did it.
When a Pelican (markdown or ReST) document contains:
does htmlify of
m.css
leave those regions between square brackets alone for later Pelican plugin(s) to work with?I saw a blurb of your comment over at Pelican issues (and I think on m.css website) that the htmlify only works at paragraph level.
Just not sure what it meant, text-editor LF-CR or HTML
<p>
?reference: https://github.com/getpelican/pelican/issues/2986