Pandoc: CriticMarkup Support?

[ickc]

I searched CriticMarkup and found something here and there for example at #2374 and #2814.

I didn't read through everything but the main difficulty seems to be related to the pandoc AST.

I created a script at ickc/pandoc-criticmarkup: using criticmarkup in the pandoc markdown source that manipulate the markdown _before_ pandoc process it (so it is not a filter), it can accept and reject changes on the sources, as well as output a HTML or PDF (via LaTeX) through RAW HTML/LaTeX in pandoc markdown.

Could a functionality like this make into the official pandoc? On one hand it seem to violate the pandoc philosophy that it acts on the AST. But on the other hand CriticMarkup is really about tracking changes during the editing phase but not in the output, so the 2 can be orthogonal. I'm not sure how it should be called though since it is not a filter (and the current "official" way to work with pandoc is template, filter, and YAML).

[jgm]

Well, my original objection to including CriticMarkup in
pandoc was precisely that it is a source-file transformation
rather than an AST transformation. So it makes more sense
to make it a separate tool that could be used as a
preprocessor in front of pandoc. It seems that this is what
you have created.

+++ ickc [Apr 23 16 18:21 ]:

I searched CriticMarkup and found something here and there for example
at [1]#2374 and [2]#2814.

I didn't read through everything but the main difficulty seems to be
related to the pandoc AST.

I created a script at [3]ickc/pandoc-criticmarkup: using criticmarkup
in the pandoc markdown source that manipulate the markdown before
pandoc process it (so it is not a filter), it can accept and reject
changes on the sources, as well as output a HTML or PDF (via LaTeX)
through RAW HTML/LaTeX in pandoc markdown.

Could a functionality like this make into the official pandoc? On one
hand it seem to violate the pandoc philosophy that it acts on the AST.
But on the other hand CriticMarkup is really about tracking changes
during the editing phase but not in the output, so the 2 can be
orthogonal. I'm not sure how it should be called though since it is not
a filter (and the current "official" way to work with pandoc is
template, filter, and YAML).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or [4]view it on GitHub

References

1. https://github.com/jgm/pandoc/issues/2374
2. https://github.com/jgm/pandoc/issues/2814
3. https://github.com/ickc/pandoc-criticmarkup
4. https://github.com/jgm/pandoc/issues/2873

[ickc]

I see. I'm going to put it in the wiki/pandoc extras/Preprocessors then.

[ickc]

On 2nd thought, there could be a way to work with CriticMarkup in the AST level.

First of all, philosophically, rather than thinking CriticMarkup as some kind of pandoc-diff, we should shift our perspective to treat it as a Markup, as its name suggested.

Then in the AST level, we can define 5 new elements corresponding to the 5 CriticMarkup. (note that the deletion is almost the same as strikethrough but spaces on 2 ends are allowed, I'm not sure if currently pandoc allow this in the native format).

e.g. the mapping I used for tex and html output is this (color, soul packages is needed in LaTeX):

| critic markup | HTML | LaTeX |
| --- | --- | --- |
| {--[text]--} | <del>[text]</del> | \st{[text]} |
| {++[text]++} | <ins>[text]</ins> | \underline{[text]} |
| {~~[text1]~>[text2]~~} | <del>[text1]</del><ins>[text2]</ins> | \st{[text1]}\underline{[text2]} |
| {==[text]==} | <mark>[text]</mark> | \hl{[text]} |
| {>>[text]<<} | <aside>[text]</aside> | \marginpar{[text]} |

After treating it as a Markup and new elements defined, accept and reject is a matter of a filter that transform these elements.

Note: there will be problem when the CriticMarkup crosses the boundary of other markup, but the official CriticMarkup also discourage this, using the example of*...{...*...}.

Edit:

To be clear, the above suggested method never make any change to the scource md file. The output option can be set in the command but comes with a default. e.g. --criticmarkup=markup|accept|reject. The default can be markup if we want to emphasize it's primarily a markup but can alternatively be used as accept/reject. On the other hand the default can be accept if we want to use it primaily to track change.

In the case if one really want to accept/reject on the source level, a preproceesor like mind can be used. Alternatively, pandoc can operate it at the AST level and almost like the trick another thread has mentioned that apply -f markdown -t markdown except that it is a special mode that only does that on the 5 CriticMarkup AST elements with the --criticmarkup=accept|reject option.

[jgm]

See the earlier thread for the rationale for NOT treating it
with new elements at the AST level.

(To see why this won't work, consider that you might want
to delete a section from a code block. In a pandoc code
block there is no structure -- it's just a string -- so
there'd be nowhere to put the critic markup annotations
in the AST.)

[ickc]

Ok, I see.

[ickc]

But I still think if the whole CriticMarkup treated as a markup will make everything fine. As a markup it shouldn't be in a code block. I mean people might want to use that in a code block too, as a tool of checking diff (in that case they should use a preprocessor). So treating CriticMarkup as a markup in pandoc is a partial support of the whole CriticMarkup concept. If abbreviation can be provided as a partial support, this could also be provided as a partial support.

On the other hand, some people do certainly use CriticMarkup as a markup that emphasize things. i.e. they are their own critics and show it to the public. (Many news site do that when they made change after they publish. I even read a news site that uses a lot of these normally used for annotation/critics elements to help the readers digest a long post.)

[jgm]

You might look at the pandoc-discuss discussion, and
contribute there if you like.

https://groups.google.com/d/msg/pandoc-discuss/STbm1W4ASiU/bYfBOroTkhoJ

+++ ickc [Apr 24 16 21:42 ]:

But I still think if the whole CriticMarkup treated as a markup will
make everything fine. As a markup it shouldn't be in a code block. I
mean people might want to use that in a code block too, as a tool of
checking diff (in that case they should use a preprocessor). So
treating CriticMarkup as a markup in pandoc is a partial support of the
whole CriticMarkup concept. If abbreviation can be provided as a
partial support, this could also be provided as a partial support.

On the other hand, some people do certainly use CriticMarkup as a
markup that emphasize things. i.e. they are their own critics and show
it to the public. (Many news site do that when they made change after
they publish. I even read a news site that uses a lot of these normally
used for annotation/critics elements to help the readers digest a long
post.)