Markdown Discuss - Apr 2015 - js syntax highlighting for markdown (not for codeblocks in markdown)

Thanks for the quick reply,

On 23/04/15 16:57, John MacFarlane wrote:
> You might find this interesting: 
>
http://talk.commonmark.org/t/experiment-highlighting-markdown-via-source-mapping/1132
I am not sure if source mapping is the best approach. It sounds strange
to me that the highlighter would need the AST *and* the original input.

Wouldn't it be easier to include enough information in the AST to be
able to reconstruct the original input (e.g. whitespace)? It should then
be easy to add a second renderer for highlighting.
> I'm not sure if the project he's describing is js, though.
The URL mentions hoedown which is implemented in C.

tobias

+++ Tobias Bengfort [Apr 24 15 11:14 ]:
>I am not sure if source mapping is the best approach. It sounds strange
>to me that the highlighter would need the AST *and* the original input.
>
>Wouldn't it be easier to include enough information in the AST to be
>able to reconstruct the original input (e.g. whitespace)? It should then
>be easy to add a second renderer for highlighting.
In principle one might be able to include enough information in the
AST to reconstruct the exact source input, but this would make the
AST immensely more complex.  For example, for a block quote we'd have
to store the exact pattern of leading `>`s on every line, including any
initial indentation.  For any character that could be escaped we'd
need to store whether it was escaped in the source.  I could go on and
on.  I think that source mapping is a much simpler approach.  It also
has applications beyond highlighting (e.g., for "click the formatted
text and an edit box appears" style online editing).

One thing to note is that the source text for a particular element
can be discontinuous.  Take, for example:

    > This is *emphasized
    > text*.

Here the emphasized node corresponds to columns 10-20 in line 1
and columns 2-6 in line 2.  That's why my original approach of storing
start and end positions for each node is not enough.  So, the revisions
needed to commonmark.js are bigger than I thought, but still feasible.