Influence header levels of transcluded files
Dear people,
What a wonderfull tool you have build. We are starting to use it for the user documentation of our products. The idea is to use the thransclusion feature to compile documents based on smaller components, and have those same components also be used in multiple documents. All works fine, but.....
it would be great if heading levels in the specific components can be influenced by the document that transcludes them. A bit like mdd_merge can do.
Would it be possible to do something like:
#My Chapter
{{part_a.mdd level:+1}}
{{part_b.mdd level:+1}}
{{part_c.mdd level:+2}}
Or any other syntax :-)
Met vriendelijke groet,
Kind Regards,
Sytze
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by fletcher on 03 Aug, 2015 05:38 PM
Glad you're finding MultiMarkdown helpful!
You can use the `Base Header Level` metadata to provide additional
control over transcluded files. Since the file being transcluded is
stripped of metadata, you can have different levels when the file is
used by itself as compared to when it is included in a parent file.
This should allow you to do what you need, but does require proper planning.
I use this approach for the MMD User's Guide.
<http://fletcher.github.io/MultiMarkdown-4/metadata.html#baseheaderlevel>
F-
2 Posted by sytze.boonstra on 04 Aug, 2015 07:11 AM
Hello Fletcher,
Thanks a lot for your reply.
I had discovered this is the way things are working and I can see it working. The only thing is indeed that it requires carefull planning, while when setting the base-level for the included document in the document that includes it (or actually not even the base level but the added number of increments) would allow, in my humble opinion, for a very modular documentation approach.
We start building our documentation on a component, screen and even field level. With for each field, screen or component a file describing the specific field. The screen document can transclude the field documents, but the component document can do so as well. It then becomes a tedious job to get the planning right.
All small documents are under version control (using stash-git and JIRA) allowing us for the first time to have perfect control over all our documentation, including documented reviews.
To conclude: MultiMarkdown is a wonderfull tool, I can see the offered approach working, and I hope my suggestion can be put on the wishlist, to further increase the power of the tool.
Best regards,
Sytze Boonstra
development manager
m +31 6 1001 6629
e [email blocked]<mailto:[email blocked]>
[cid:[email blocked]]
Bezoekadres
Postadres
www.autopharma.nl<http://www.autopharma.nl/>
Anne Wadmanwei 11
Postbus 8
facebook.com/autopharma<https://www.facebook.com/autopharma.leeuwarden>
NL-8914 BD Leeuwarden
NL-8900 AA Leeuwarden
twitter.com/autopharmabv<https://twitter.com/autopharmabv>
t +31 (0)58 213 27 15
f +31 (0)58 212 33 12
This message and any files or documents attached are strictly confidential or otherwise legally protected. It is intended only for the individual or entity named. If you are not the named addressee or have received this email in error, please inform the sender immediately, delete it from your system and do not copy or disclose it or its contents or use it for any purpose. Please also note that transmission cannot be guaranteed to be secure or error-free
Support Staff 3 Posted by fletcher on 04 Aug, 2015 06:29 PM
I'll consider it. I understand why it's useful, I just have to balance
net benefit to all users vs the increased complexity with every new
feature I add...
We'll see.
Thank you for your thoughts!!
Fletcher
fletcher closed this discussion on 02 Dec, 2017 01:56 PM.