Why cmark-gfm instead of jgm / commonmark-hs?

[digitalmoksha]

I'm curious. What about porting from https://github.com/jgm/commonmark-hs rather than cmark-gfm? jgm as speced out extensions pretty well, it seems very extensible and supports source positions for all elements. And supports GFM.

[gjtorikian]

I'm not sure what @kivikakk's reply will be, but I can guess: we were both at GitHub when the GFM spec came out; and indeed, @kivikakk worked on that very spec.

This lib has gone on to evolve indepentently of GitHub/cmark-gfm and I'm sure any extension / suggestion that's PRed would be merged, a la #251

[kivikakk]

Also, no need to apologise for the questions, hah :) Happy to answer them! I don't really have much time to dedicate to Comrak these days, unfortunately — it's been many years since I was actively working in the CommonMark space, or with Rust for that matter, and life is rather a lot to manage these days — but I continue to do my best to keep it maintained and secure, encourage/shepherd new contributors, and make small improvements over time myself.

[digitalmoksha]

life is rather a lot to manage these days

Oh yeah, no kidding. Totally understand.

it's also tested in CI against all the same example files used by cmark-gfm

Ah, I knew I had to be missing a piece. 👍

sourcepos is semi-complete

This is actually a requirement for us - it's used both in our backend and frontend. With my limited Rust knowledge, I'm not sure I'd be much help right now.

Extensions aren't loaded at runtime or anything like that, no, and I would add new features (such as math) the same way. cmark-gfm is mostly the same: extensions are built-in at compile time, but the design of the code there allows extensions to hook themselves in and thus be separated out into a different source directory/library object archive before linking.

I have to admit I like the ability to have extensions hook themselves in, and be separated out. Looking at rlidwka/markdown-it.rs, that's what they are doing. Of course markdown-it is specifically built that way originally.

I'm thinking in terms of being able to create our own crate that pulls in yours and then adds an extension, such as our multiline block quote, or our task list extension. Things that might not necessarily belong in this repo (though I would love it if it did, enabled via a glfm flag 😄). We currently handle those things before/after the markdown transformation.

[kivikakk]

This is actually a requirement for us - it's used both in our backend and frontend. With my limited Rust knowledge, I'm not sure I'd be much help right now.

I understand! I have a personal todo to finish it off after I've finished moving house, but that's unlikely to be for a month or two.

I'm thinking in terms of being able to create our own crate that pulls in yours and then adds an extension, such as our multiline block quote, or our task list extension.

I'd be very happy for such things to be possible! I think it shouldn't be particularly complicated to make happen; just needs some care to make sure the extension API that results is useful in the right ways. (Some more of my thoughts about how to do this are at #258 (comment).)

[kivikakk]

For what it's worth, sourcepos landed in 0.18.0.

[digitalmoksha]

Oh, very awesome!! Thanks 🚀