![]() If you were using a workaround like (repo/blob/master/other_file.md), you'll have to update your documentation to use the new syntax. (path%20with%20spaces/other_file.md)Īnd we'll make sure it gets linked to user/repo/blob/branch/other_file.md. ![]() …you can use a relative link: (other_file.md) You want examples of link definitions and how they work? Here's some Markdown for you. Now you can link directly between different documentation files, whether you view the documentation on GitHub itself, or locally, using a different markup renderer. Starting today, GitHub supports relative links in markup files. Update 30th, January 2013, 16 months later: GitHub Blog Post Relative links in markup files: (even if the behavior when multiple links are defined, or when a link is defined but never used, is not strictly specified). In general, this approach should work with most Markdown parsers, since it's part of the core specification. Some parsers will output the comment if there is no blank line before, and some parsers will exclude the following line if there is no blank line after. The most recent research with Babelmark shows that blank lines before and after are both important. To improve platform compatibility (and to save one keystroke) it is also possible to use # (which is a legitimate hyperlink target) instead of : : # (This may be the most platform independent comment)įor maximum portability it is important to insert a blank line before and after this type of comments, because some Markdown parsers do not work correctly when definitions brush up against regular text. Or you could go further: : (This is also a comment.) ![]() : (in the output file unless you use it in) That is: : (This is a comment, it will not be included) If you want a comment that is strictly for yourself (readers of the converted document should not be able to see it, even with "view source") you could (ab)use the link labels (for use with reference style links) that are available in the core Markdown specification: The tests at the end of MarkdownFormatterTest seem to be commented out by private? Not sure why, but the tests work even after commenting it out to #private.I believe that all the previously proposed solutions (apart from those that require specific implementations) result in the comments being included in the output HTML, even if they are not displayed. The patch is included including a unit test. So I would strongly vote to change the default behavior towards more standard Markdown / GFM to stay compatible with the world. I guess we are not that rare when we intend to share Markdown sources between Redmine and GitLab and among Redmine and other systems - using API, mirroring wiki to git and indeed with users' copy&pasting it. And as the author says, it is against Markdown specs. On the other hand, it breaks compatibility with GFM, especially on its two major implementations GitHub and GitLab (as said - except GitHub issues, but our developers are really angry about GitHub issues having different behaviour than the rest of GitHub). Indeed, we do not know how intentional the decision was. On one hand, calling this a defect might not be fair, as it is apparently kind-of decision made in lib/redmine/wiki_formatting/markdown/formatter.rb with the setting :hard_wrap => true.
0 Comments
Leave a Reply. |