Hello, on Monday 10 December 2012 at 12:52, Nolan Darilek wrote: > Cool deal, thanks. Something else I just discovered: > > The first level 1 heading in a document replaces its title. So if you > were using the <title>Augmented page title</title> feature of embedded > docs, just do: > > # Augmented page title > > I don't know if that's just the first level 1 heading or the first > heading of any kind, but thought I'd document it here for anyone wanting > to use this feature. Must be the first item in the document.
It's for any level of heading, but it has to be the first thing in the markdown document to be considered as a document title. Put any text before that and the heading will be rendered in the document body. I thought it would fit well into the current document page system, but it was only a proposition of mine, open to discussion. On 12/09/2012 08:36 PM, Joe Mistachkin wrote: > Nolan Darilek wrote: >> Also, there are a bunch of variants in MD syntax. Is there a link to >> what is supported in the embedded engine? Is it just vanilla, or any >> extensions for tables/TOCs/etc.? >> > I'm not sure about this. Perhaps Natacha can shed some light on it? When I wrote that code, I thought there would be some discussion about which markdown superset to choose, so it was meant to be the engine itself with as few clutter as possible besides it. So what got merged is vanilla markdown with tables using PHP-markdown syntax (I honestly can't remember why I included tables, until I double-checked I thought I hadn't). It would be very easy to add new features, for example image size, pseudo protocols and class blocks from Discount, or <ins> and <del> with a syntax like ++this++ and --this--. I would gladly do so if there is some kind of consensus on which features to take and which ones to leave. One could also imagine a runtime setting to choose a feature-set, like vanilla/Discount-ish/full-blown bells and whistles, I did exactly that with the example binary provided with upstream (non-fossil-integrated) library. It's even possible to create one runtime setting per markdown feature to fine-tune exactly what gets rendered on a per-repository basis, though that might be more maintenance burden than it's worth. I don't mind providing any feasible feature request, what's really missing here is a policy or a consensus. Hoping this helps, Natacha Porté
pgpQIf0kYuMk6.pgp
Description: PGP signature
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
