fletcher/peg-multimarkdown — Issue #93: Auto-referencing not working between files
Author: x3ro
Created: 2011-11-27 13:40:12+00:00
State: open

Say we have two files such as these:

### test1.mmd

# A section
Some text

### test2.mmd

# Another Section
That references [A section][]

When processed with `multimarkdown -t latex test1.mmd test2.mmd`, the result will be:

\part{A section}
\label{asection}

Some text

\part{Another Section}
\label{anothersection}

That references A section (\autoref{a section})

If you process it in batch-mode however, it won't get the references right - `multimarkdown -b -t latex test1.mmd test2.mmd` will result in these files being generated:

### test1.tex

\part{A section}
\label{asection}

Some text

### test2.tex

\part{Another Section}
\label{anothersection}

That references [A section][]

Which is unfortunate, especially if you're trying to a extensive document like a thesis, and you don't want to keep everything in a single file.

# Ideas

I took a look at the code, I think that the "issue" lies in `markdown_to_g_string()`, because it does not allow for multiple inputs being processed with the same `references`, `notes` and `labels`.

So my first idea was to write a function that, instead of taking a single input string, takes an array of strings (as many as there are input files), then builds a common reference base for all of them, after which the actual MMD-processing per file happens. This assumes that it is possible to append to an existing references / labels / notes data-structure.

In pseudo-code, I'm thinking of something like this:

files := [test1.mmd, test2.mmd]
output := [ ] // Empty array

references := []

// Same for labels and notes
FOR file IN files
references := references APPEND parse_references(file)
END

FOR file IN files
temp := parse_markdown_with_metadata(file)
output .= output APPEND process_raw_blocks(temp)
END

RETURN ouput

Note that the `files` array could also contain the contents of the files, I just wrote it this way to keep the pseudocode clean. Also, I left out lots of non-essential (or so I think) parameters for the function calls, but I hope I'm making clear what my idea is.

@fletcher Let me know what you think about it :)