%h3.page_title GitLab Flavored Markdown .back_link = link_to help_path do ← to index %hr .row .span8 %p For GitLab we developed something we call "GitLab Flavored Markdown" (GFM). It extends the standard Markdown in a few significant ways adds some useful functionality. %p You can use GFM in: %ul %li commit messages %li comments %li wall posts %li issues %li merge requests %li milestones %li wiki pages .span4 .alert.alert-info %p If you're not already familiar with Markdown, you should spend 15 minutes and go over the excellent %strong= link_to "Markdown Syntax Guide", "http://daringfireball.net/projects/markdown/syntax" at Daring Fireball. .row .span8 %h3 Differences from traditional Markdown %h4 Newlines %p The biggest difference that GFM introduces is in the handling of linebreaks. With traditional Markdown you can hard wrap paragraphs of text and they will be combined into a single paragraph. We find this to be the cause of a huge number of unintentional formatting errors. GFM treats newlines in paragraph-like content as real line breaks, which is probably what you intended. %p The next paragraph contains two phrases separated by a single newline character: %pre= "Roses are red\nViolets are blue" %p becomes = markdown "Roses are red\nViolets are blue" %h4 Multiple underscores in words %p It is not reasonable to italicize just part of a word, especially when you're dealing with code and names often appear with multiple underscores. Therefore, GFM ignores multiple underscores in words. %pre= "perform_complicated_task\ndo_this_and_do_that_and_another_thing" %p becomes = markdown "perform_complicated_task\ndo_this_and_do_that_and_another_thing" %h4 URL autolinking %p GFM will autolink standard URLs you copy and paste into your text. So if you want to link to a URL (instead of a textual link), you can simply put the URL in verbatim and it will be turned into a link to that URL. %h4 Fenced code blocks %p Markdown converts text with four spaces at the front of each line to code blocks. GFM supports that, but we also support fenced blocks. Just wrap your code blocks in ``` and you won't need to indent manually to trigger a code block. %pre= %Q{```ruby\nrequire 'redcarpet'\nmarkdown = Redcarpet.new("Hello World!")\nputs markdown.to_html\n```} %p becomes = markdown %Q{```ruby\nrequire 'redcarpet'\nmarkdown = Redcarpet.new("Hello World!")\nputs markdown.to_html\n```} %h4 Emoji .row .span8 :ruby puts markdown %Q{Sometimes you want to be :cool: and add some :sparkles: to your :speech_balloon:. Well we have a :gift: for you: :exclamation: You can use emoji anywhere GFM is supported. :sunglasses: You can use it to point out a :bug: or warn about :monkey:patches. And if someone improves your really :snail: code, send them a :bouquet: or some :candy:. People will :heart: you for that. If you are :new: to this, don't be :fearful:. You can easily join the emoji :circus_tent:. All you need to do is to :book: up on the supported codes. } .span4 .alert.alert-info %p Consult the %strong= link_to "Emoji Cheat Sheet", "http://www.emoji-cheat-sheet.com/" for a list of all supported emoji codes. .row .span8 %h4 Special GitLab references %p GFM recognizes special references. You can easily reference e.g. a team member, an issue or a commit within a project. GFM will turn that reference into a link so you can navigate between them easily. %p GFM will recognize the following references: %ul %li %code @foo for team members %li %code #123 for issues %li %code !123 for merge request %li %code $123 for snippets %li %code 1234567 for commits -# this example will only be shown if the user has a project with at least one issue - if @project = current_user.projects.first - if issue = @project.issues.first %p For example in your #{link_to @project.name, project_path(@project)} project, writing: %pre= "This is related to ##{issue.id}. @#{current_user.name} is working on solving it." %p becomes: = markdown "This is related to ##{issue.id}. @#{current_user.name} is working on solving it." - @project = nil # Prevent this from bubbling up to page title