1.0 Roadmap

[maciejhirsz]

I feel like we are in a pretty good place right now with the feature set and the API surface. Checklist for 1.0 release:

• [ ] Remove(!) #[md] and markdown support. Figure out more generic way to support writing to encoders without intermediate buffers from iterators like pulldown_cmark's one.
• [ ] Template interrogation as per #1 (seriously, 1).
• [ ] ..?

[luciusmagn]

Is some if-like structure planned?

Also will there be an easy replacement for #[md] available? I like this feature quite a bit, so I am wondering if I were to depend on it for now. I am currently trying to reduce dependencies and code in my fork of mdblog and #[md] seems like a godsend.

[maciejhirsz]

Sections serve as if conditions in Mustache: {{#condition}}...{{/condition}}. You can use a boolean on a flat struct, or you can use an Option:

#[derive(Content)]
struct Foo {
    name: &'static str,
    maybe_bar: Option<Bar>,
}

#[derive(Content)]
struct Bar {
    count: usize,
}

Will work with {{name}} {{#maybe_bar}}{{count}}{{/maybe_bar}}.

As for #[md], my idea would be to replace it with something like #[callback(some_fn)], where some_fn is a function you've defined that takes a ref to the field, and a mut ref to generic std::fmt::Write (or std::io::Write), so you can just grab whatever markdown and pipe it through pulldown_cmark (which is basically what Ramhorns is doing now). Whenever that happens I'll be sure to include a migration guide in release notes.

[grego]

I think there could be #[ramhorns(callback = "some_fn")], where some_fn would take a ref to the field and a mut ref to a generic Encoder. Also, #[ramhorns(md)] or even #[md] could be kept for the case of some_fn equal to ramhorns::cmark::encode. I can implement this if it sounds alright.