-
Notifications
You must be signed in to change notification settings - Fork 57
Description
I'm incorporating MMD into a GUI on OS X. To do this, I'm using libMultiMarkdown and calling the various functions directly (as opposed to calling the compiled mmd binary on a separate process).
The Problem
Whenever the parser or one of the writers (odf.c, opml.c, etc.) encounters an error, you call exit(EXIT_FAILURE), which immediately terminates my entire app. This is obviously not what we want.
The Solution
The only thing that should be calling exit() is multimarkdown.c, which is the file that compiles into the command line utility. The rest of the project should never call exit() directly. Instead, the various functions in the rest of the project should include an error parameter. That way, when an implementor attempts to use libMultiMarkdown in their project, the framework is agnostic—it won't assume that it's simply running as a separate process where it's fine to kill everything.
Proposals
The main function currently looks like this:
char * markdown_to_string(const char * source, unsigned long extensions, int format);
One option would be to add an error parameter, like this:
char * markdown_to_string(const char * source, unsigned long extensions, int format, char **error);
If error is not NULL, you know something went wrong and can handle it appropriately. The parameter would be populated with the messages you currently spit to stderr just before calling exit(). This is the option with the least amount of major refactoring.
A better option would be to create a set of "context" structs, like this:
struct mmd_result_context
{
bool success;
char *output;
char *error;
};
struct mmd_context
{
char *source;
int outputFormat;
unsigned long extensions;
mmd_result_context *result
};
Now, you create an mmd_context and set the first three parameters. Then, instead of calling markdown_to_string(), you'd call something like:
bool mmd_compile_context(mmd_context *ctx);
This would create the mmd_result_context as a child of the original mmd_context. You could inspect the contents of the result context to act appropriately. This is the much more robust solution.
Need a Go-Ahead
I'm willing to refactor MMD to use either of these approaches, but I'd like to know that if I do so and submit a pull request, you'll merge it. Otherwise, I'd have to re-do all this work every time you update the project in the future. I don't want to invest all the time without knowing up-front if this is something you'll approve. Thanks!