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 <iam...@gmail.com <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 >> elm-discuss...@googlegroups.com <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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
