Add-on: Issue references within a repository
As you know, when parsing the markdown body of a issue or pull-request comment, you can find something like a #96, which in the context of this project is translated to [#96](https://github.com/pillar-markup/MicroDown/issues/96).
Probably this is not something we want in general MicroDown, but it can be an add-on/plugin.
Reference: GitHub Flavored Markdown
In fact, the guide (linked above) shows other 2 forms of referencing issues, which allows linking to issues in other GH repositories. Example:
#1
mojombo#1
mojombo/github-flavored-markdown#1
That would be good to have too, of course.
I do not see a way in which this can be done. On github it knows in which project we are working, hence #123 is unique. In pharo it is less obvious what the context is. Do you have any ideas @tinchodias of how to find the context?
@kasperosterbye In that moment when I created the issue I only imagined something like:
aParser := MDParser new.
aPlugin:= MDGithubRepoPlugin user: 'pillar-markup' project: 'MicroDown'.
parser addPlugin: aPlugin.
aParser parse: '#1'
because I wished to parse contents answered by the GithubAPI and my tool had that information. But... just a wish, maybe you can close this request.
I now see a way in which this can be done. We could support a preprocessor for the source code that allow you accept an extended source, and return pure microdown.
Such methods could be identified using a microdownPreprocessor pragma. An extension could then be written as:
expandGithubNumberLinksIn: source
<microdownPreprocessor>
^ self doFancyRegularExpressionSubstitutionOn: source
Microdown could then look if there are such pragmas and run them before it actually attempts to parse.
For our own testing purposes we need to be able to turn such preprocessing on and off.
Notice - It is left to @tinchodias to figure out how to relate this to github projects etc. Microdown would just give a way to do it.
As an alternative design, the substitution could be applied only by the inline parser. The inline parser is the one responsible for bold, links etc as opposed to the block parser which works on whole lines building paragraphs, lists, tables, etc.