Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A few enhancements to make this a documentation browser #11

Open
kamranayub opened this issue Feb 15, 2013 · 2 comments
Open

A few enhancements to make this a documentation browser #11

kamranayub opened this issue Feb 15, 2013 · 2 comments

Comments

@kamranayub
Copy link

With a few enhancements, MM could easily be used as a documentation browser for our source code.

The three enhancements I'm thinking of:

  • Custom stylesheet/layout, on a per-solution basis. Just a way to make the preview prettier and add boilerplate HTML
  • Handle relative links correctly. In my Markdown, if I have a link to test.md it should tell VS to open that file if it exists. This will make it MM acts as a browser almost within VS. It will open extra tabs, but then you can use VS' built in back/forward to navigate between docs.
  • Switch to using Pandoc to generate HTML

Markdown# is cool, but I've had better luck packaging Pandoc.exe and executing it against markdown files to generate HTML. Here's a sample in C#:

// Process to output dir
var pandocStart = new ProcessStartInfo();
pandocStart.FileName = "pandoc";

// Standalone HTML generation using a template file
// Use Github Markdown processing!
pandocStart.Arguments = "pandoc -r markdown_github --highlight-style=kate --template=template.html --toc";
pandocStart.RedirectStandardError = true;
pandocStart.RedirectStandardOutput = true;
pandocStart.RedirectStandardInput = true;
pandocStart.UseShellExecute = false;
pandocStart.CreateNoWindow = true;
pandocStart.WindowStyle = ProcessWindowStyle.Hidden;

using (var pandoc = Process.Start(pandocStart))
{
    var rawText = File.ReadToEnd(markdownFile);
    string html;

    using (StreamWriter writer = pandoc.StandardInput)
    {
        await writer.WriteAsync(rawText);
    }

    using (StreamReader reader = pandoc.StandardOutput)
    {
        html = await reader.ReadToEndAsync();
    }

    using (StreamReader reader = pandoc.StandardError)
    {
        var error = await reader.ReadToEndAsync();

        if (!String.IsNullOrEmpty(error))
        {
            throw new Exception(error);
        }
    }

    // Do something with the HTML generated by Pandoc
}

I think this is better than using M# because it supports all sorts of extensions including tables, fenced code blocks, auto ID generation, and more (documented by Pandoc). Even cooler, it supports Pandoc title blocks or MultiMarkdown title blocks.

@NoahRic
Copy link
Owner

NoahRic commented Feb 17, 2013

(1) and (2) are entirely sensible. If you want to give it a go, feel free to try and send me a merge request!

(3) is tougher. Classification should match the eventual output, which means that MM needs a parser, and not just a translator as a binary. I see that pandoc has a haskell API and also some ability to spit out document ASTs, but it doesn't look like that information is sufficient to map from AST->original text, or at least it would be a large amount of work.

@kamranayub
Copy link
Author

Ahh, I entirely forgot about the whole syntax parsing :)

Well, in that case, even extending M# to support fenced code blocks might be good. I've done it for my personal blog, so I have the code that adds the regex and adds syntax highlighting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants