mosra / m.css

A no-nonsense, no-JavaScript CSS framework, site and documentation theme for content-oriented websites
https://mcss.mosra.cz
Other
406 stars 92 forks source link

Does htmlify leave alone string between [ and ] #220

Closed egberts closed 2 years ago

egberts commented 2 years ago

When a Pelican (markdown or ReST) document contains:


[jtable separator=“&”]
<p>ipsum delorus …

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

mosra commented 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 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. No need it seems, everything done already, see comment below.

mosra commented 2 years ago

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.

egberts commented 2 years ago

Thanks.... That did it.