I'm building a document editor with executable code in it. So far, I have SQL embedded in Markdown.
For markdown, I needed flexibility in changing the output from the standard HTML output, like adding extra info around a code block. I looked at elm-markdown, and found it didn't have this flexibility. In addition, it embedded a minified version of marked.js inside of it. Looked into parsing markdown briefly, and discovered it's not even a BNF, and would probably spend a lot of time writing the parser. I found commonmark.js. So now, either I write a ports for commonmark.js, or I write it as a native module. I asked about it here <https://groups.google.com/forum/#!topic/elm-discuss/Kd53qnKY-io> with no answers. I decided to write it as a native module with elm-markdown.js as a template. It's a bit messy in there, because 1) I'm proving out a concept, but also, 2) I'm not sure what is considered good practice. I had looked at a few other libs with native modules, and it seemed like they were using an API of some sort, rather than directly using namespaces like "_elm_lang$virtual_dom$Native_VirtualDom" That's why I was asking. In cases where it's an integration library, like talking to the twitter API, I think it makes sense to write it entirely in Elm. Might be boring work, but it's doable. But what about things like parsers? If you find a parser in JS (ie. code above a certain complexity threshold) for a language, should you try to rewrite it in Elm? My guess is ideally, yes. But often times, I'm under a time crunch, or I'm more interested in proving out a concept to myself, so diving down to take the time to write a parser didn't make sense for me this time. Wil On Monday, December 5, 2016 at 9:22:42 AM UTC-8, Richard Feldman wrote: > > No new thinking on that as far as I'm aware...what are you looking to > build? > > On Mon, Dec 5, 2016, 8:37 AM Wil C <[email protected] <javascript:>> wrote: > >> Do you know if there's going to be a guide on native modules? I just used >> elm-markdown as a guide, but I saw there were other conventions in other >> libraries with native modules. >> >> I understand the hesitation in giving a guide on an escape hatch to >> native, since people will instinctively reach for it. Just was wondering if >> there was new thinking on it. >> >> >> On Monday, December 5, 2016 at 8:19:14 AM UTC-8, Richard Feldman wrote: >>> >>> Looking at the evancz/elm-markdown >>> <https://github.com/evancz/elm-markdown> parser, that seems like a case >>> that warrants it, yeah. >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Elm Discuss" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/elm-discuss/nuR4NnCVcMs/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
