red

Style Guide: Wiki Basics

Getting Started

In general, existing content, including markup, should not be modified or removed.

Opening An Editor

If a page can be edited you will see two options to choose from in the left column:

1. blue

   • The Text editor provides more power/flexibility for editing than the GUI editor but requires that you know the wiki markup. Use the Text editor to see the content with raw markup. You will need to use the Preview feature to view the content as it will appear when saved.

   Specific markup instructions in this guide are for use with the Text editor but should also work in the GUI editor.
   For information on wiki markup not included here, or other MoinMoin-specific questions, please see the wiki help documentation.

2. blue

   • The GUI editor provides buttons, much like a simple word processor, to add formatting markup such as bolding text, making a table, or creating a numbered list. It is simpler to use than the Text editor but does not provide buttons for all the possible markup. Use the GUI editor to see the content appear roughly as it would on the screen as you edit or if you do not know or want to use the wiki markup.

   The GUI editor is fairly self-explanatory; however, if you require further assistance, see HelpOnGraphicalEditor for more detailed instructions.

Note that some formatting will appear slightly different in preview mode than on the finished screen.

Saving Your Changes

Before you save your changes please include a note in the Comment field below the editing box that summarizes what you have done.

• Sample comments:

  • added comment to end of remarks
  • added code example to C++ section
  • remarked on use of function with [sound card model]

Especially when using the text editor, use the blue

function in the left sidebar before saving your changes to ensure that the markup you have included is producing the desired result as well as to scan for errors in a different view.

When you have finished adding your content and filling in the Comment field, and are satisfied with the formatting, use the blue

function in the left sidebar to save your changes.

Automatic Backup of Drafts
(from: Help On Editing)

• Every time you are in the editor and use the "Preview", "Spell Check", "Cancel" or "Save Changes" buttons, moin saves a draft copy of your work internally. Use preview often! If you hit "cancel" accidentally, your machine crashes, or the browser window was accidentally closed, then the automatic backup of your draft may be easily recovered.

  To recover that draft, you simply edit that page again. If there is a draft, an alert message will be in the message box [at the top] and a "load draft" button will be present [in the left column]. Clicking the "load draft" will load your saved draft into the editor box replacing the current revision already loaded. You can continue editing the loaded draft, but this time try to save it at the end.

  Don't use the "preview", "spell check", "save changes" or "cancel" buttons on that page before "load draft" or you will overwrite your old draft with a new one. If you successfully save a page, the internal draft copy of it is not needed any more and will be deleted.

Return to Table of Contents

General Guidelines

red

Never remove DRAFT from any page!

The top of (nearly) every page begins with the following:

• #pragma section-numbers off
  #pragma camelcase off

• Any new or in progress page will also include:

  ||<tablewidth="100%" style="color: #FF0000;" :> DRAFT||

Never change the Category links at the bottom of a page.

Some Markup Basics

Below is a summary of the most commonly used markup in this wiki and some hints and tricks for using it.

The following is provided for your convenience and is meant to be general information. The other Style Guides describe where this formatting should be applied and where exceptions may exist.

A good place to look for additional information on MoinMoin wiki markup is HelpOnMoinWikiSyntax. Also see the Editor Hints in the left sidebar when in Edit mode for some of the most common markup.

Spacing

Both vertical and horizontal spacing can be rendered differently depending upon the combination of formatting markup that is used. If your formatting is not working out the way you want check the notes below on other formatting that you have used nearby that may be affecting how the local formatting is interpreted.

• Example: If you try to pick up a numbered list down the page after using unnumbered lines at the same indent level, the next number in the numbered list will count the unnumbered lines.

• See Some Known Problems and Solutions below for notes on known interference between markup.

Indenting

• Markup: Place blank spaces at the beginning of a line of text to create indents. (this line has 1 space)

  • Use one space for each indent level desired. (this line has 2 spaces)

• Note: Use a period (.) after the spaces and before the text (usually separated by a space after but not necessary) to ensure that the indent does not become a bullet or numbered list. Note that this markup will sometimes resolve problems when the spacing from line to line is not what you expected. (this line has 2 spaces and a starting period)

• Example:  . This line starts with a period   

  • generates
    

• This line starts with a period

• red

  Indenting often leads to inadvertent creating of a list. Lists follow very limiting, sometimes difficult to figure out, rules. See Lists below if your indenting is not working the way you think it should.

Hard Line Break

• Markup: <<BR>>

  • Place the above markup wherever you want to force the following text onto the next line but keep it in the same paragraph.
    

  • Note: You cannot change indent level immediately following a hard line break. (The next line is still part of the same paragraph.)

• Example: Typing the following in the text editor

    1 first line<<BR>>  2 this line typed on same line after hard line break markup, same indent<<BR>>   3 this line typed on same line after hard line break markup, +1 indent<<BR>>  4 this line typed on same line after hard line break markup, -1 indent<<BR>>  . 5 this line typed on same line after hard line break markup, same indent with period<<BR>>6 this line typed on same line after hard line break markup without any indent

  • generates

• 1 first line
  2 this line typed on same line after hard line break markup, same indent
  3 this line typed on same line after hard line break markup, +1 indent
  4 this line typed on same line after hard line break markup, -1 indent
  . 5 this line typed on same line after hard line break markup, same indent with period
  6 this line typed on same line after hard line break markup without any indent

• Note: Spaces between lines and paragraphs (which may be individual lines) are parsed with different spacing depending upon the context (especially relative indent level). It may take some playing around with the markup to get the spacing you want, or it may be that you will have to accept a certain amount of pre-determined spacing between lines.

  • Example: Typing the following in the text editor

     1 hard return followed by next line same indent
     2 hard return followed by next line +1 indent
      3 hard return followed by next line same indent using period
      . 4 hard return followed by next line same indent, no period
      5 hard return followed by next line -1 indent
     6 hard return after hard line break markup, followed by next line same indent<<BR>>
     7<<BR>> 8 next line typed on same line after hard line break markup, same indent

    • generates

    • 1 hard return followed by next line same indent 2 hard return followed by next line +1 indent
      • 3 hard return followed by next line same indent using period
      • 4 hard return followed by next line same indent, no period 5 hard return followed by next line -1 indent

      6 hard return after hard line break markup, followed by next line same indent
      7
      8 next line typed on same line after hard line break markup, same indent

  • To ensure that the next line is treated as a separate line (not necessarily a separate paragraph!)

    1. use two consecutive hard returns (Enter key)

       • Note: this will leave a larger space between lines (usually a double-space) but it is treated as a new paragraph

    2. use a hard line break

    3. indent more (farther right)

    4. use a period at the beginning of the line after indenting the same amount

    5. indent less (farther left)

Return to Table of Contents

Lists

red

Anything that interrupts a list, except a list item indented further right, will potentially end the list! This may affect the indenting, count, or symbols if you try to restart the list below the interruption. This may or may not be able to be overcome, so be careful with anything that interrupts a list!

Bullet Lists

• Markup: Begin a line with a space followed by an asterisk to create a bulleted line of text (space after asterisk is optional but seems to be preferred)

• Example:   * First line of bullet list
  

  • Generates:

  • First line of bullet list
    

Numbered Lists

• Markup: Begin a line with a space followed by the number 1 and a period (or choose another number format such as i or a).

• Note: Each line that should be part of the list begins with the same starting number. The wiki will generate sequential numbers in preview mode or after saving.

• Example:

   1. First line of numbered list
   1. Second line of numbered list

  • Generates:

  • First line of numbered list
  • Second line of numbered list

  More wiki markup for lists can be found at HelpOnLists

Some Known Problems and Solutions

green

red

Some list breaks cannot currently be fixed so you should be very careful when interrupting a list as it may force formatting you will not want.
See Mixed Lists for some discussion and examples of problems.
Note: The contents at this link may change at any time and this link may not always be up to date.

Return to Table of Contents

Text Formatting

Note: Formatting markup can usually be nested/grouped, but the order it is used in may affect whether it works as desired. Try using multiple formatting tags in a different order or check the help if you have trouble.

Font Types & Sizes

red

The wiki's default font type, font colors, and font sizes should be used in almost all cases.

Bold

• Bold

  • Place three apostrophes surrounding text to be bolded, without a space between markup and text.

    Example: '''bold text''' generates bold text

Italics

• Italics

  • Place two apostrophes surrounding text to be italicized, without a space between markup and text.

    Example: ''italics text'' generates italics text

Monospace

• Monospace

  • Place a backtick on either side of the text, without a space between markup and text. (Note: This may resemble inline code (see below) in many cases, but will not behave the same.)

    Example: `monospace text` generates monospace text

Code

• Code (or Verbatim Text)

  • Use three curly brackets surrounding text to be rendered as code.
    • Place the brackets inline with the text to display the code formatting inline.

      Example:

      {{{Verbatim text as it should be typed, or appear as code or with markup. If it is too long for the line it will not wrap.}}}

      • generates

      Verbatim text as it should be typed, or appear as code or with markup. If it is too long for the line it will not wrap.

    • Place the brackets above and below the text to display the code formatting inside a box.

      Example:

      {{{
      Verbatim text as it should be typed, or appear as code or with markup. This will word wrap if it is too long for one line.
      }}}

      • generates

      Verbatim text as it should be typed, or appear as code or with markup. This will word wrap if it is too long for one line.

Colored Text

• red

  orange

  yellow

  green

  blue

  indigo

  violet

  brown

  pink

  grey

  purple

  • We have the Color2 macro installed. It will colorize text outside of tables using the following syntax:
    

    • <<Color2(colorname,text to be colorized)>>
      

    • colorname may be most any simple color name like blue or red or green

    • If text to be colorized must contain commas each section must be colorized separately. Place the comma at the end of each string and the space after between colorized sections to accomplish this.

      • Example:

        • Correct

          <<Color2(purple,A sentence that contains commas,)>> <<Color2(purple,such as this one,)>> <<Color2(purple,must be broken into parts or the text before the first comma will not appear when parsed.)>>

          • generates

        • purple

          purple

          purple

        • Incorrect (note that the beginning of the sentence is missing)

          <<Color2(purple,A sentence that contains commas, such as this one, must be broken into parts or the text before the first comma will not appear when parsed.)>>

          • generates

        • purple

    The Color2 macro will work within a table also! However, there are other options for colorizing text (and backgrounds) in tables. See Tables below for more info.

    Please use colored text sparingly if at all. As a general convention we use blue to represent links (whether they actually behave as links or not), so please reserve that color for such purposes.

  More wiki markup for text formatting can be found at HelpOnFormatting.

Return to Table of Contents

Hyperlinks

• Although this wiki automatically creates some hyperlinks, in most cases for the SDL functions, enumerations, and structures it is unable to interpret the text correctly so we have disabled automatic linking via the following markup at the top of every page:

  #pragma camelcase off

Therefore, it is important that you manually create hyperlinks!

• Action: Always create a hyperlink to any API page.

• Action: Do not create hyperlinks to portions of the API that do not have their own page.

• Hint: If you are unsure, check the API By name page.

• Markup: A hyperlink to another page (especially within the wiki) is created, in most cases, by enclosing the text to be linked in double brackets:
  [[linktarget]]

• Example: [[SDL_VideoInit]] generates SDL_VideoInit

  • If a hyperlink is automatically created where you don't want one check to ensure that the #pragma markup mentioned above is correct at the top of the page. If it is not, correct or add it. This should resolve the issue.

  • A hyperlink to an anchor (or any unique text on a page) is created, in most cases, by
    

    • [[#anchorname|description]]
      where anchorname is a previously created anchor or a unique bit of text on the page (but not a header) and description is the text that will actually appear as the link.
      

    Example: [[#hyperlinks|how to hyperlink]] creates how to hyperlink (try clicking the link to see it in action)

  • A hyperlink to an outside web or email address may be created by simply typing or pasting in the address. The wiki should auto-recognize and link these standard forms.
    • To create a link with link text other than the address itself, enclose the address followed by a pipe and the alternate link text in double brackets.

      Example: [[link address|alternate text]] produces alternate text

  • Any link referencing the header files should replace the version number (12-digit alpha-numeric code) with default in the address if the link should be to the most current version rather than to a specific version of the header file.

  More wiki markup for tables can be found at HelpOnLinking

Return to Table of Contents

Anchors

• <<Anchor(anchorname)>>
  

  • Place the above markup in the location where you wish to create an anchor, replacing anchorname with a word (or phrase) that has meaning in that application.

  • Example: <<Anchor(hyperlinks)>> would create an anchor called hyperlinks that would be located at the beginning of a section related to hyperlinks.
    

  More (but not much) wiki markup for anchors can be found at HelpOnLinking and HelpOnMacros.

Return to Table of Contents

Tables

• Two pipes (||) are used to begin and end a table row, with two pipes separating each cell in between.

  • It is important that there are no blank spaces or other characters after the closing pipes on a line.

    Example:

    ||row 1 column 1||row 1 column 2||row 1 column 3||
    ||row 2 column 1||row 2 column 2||row 2 column 3||

    Generates:

    row 1 column 1	row 1 column 2	row 1 column 3
    row 2 column1	row 2 column 2	row 2 column 3

  To add color within a table use the following markup:

  • <style="color: #FF0000;">	set text color
    <bgcolor="#XXXXXX">	set cell background color
    <rowbgcolor="#XXXXXX">	set row background color (only valid in first cell)
    <tablebgcolor="#XXXXXX">	set table background color

  More wiki markup for tables can be found at HelpOnTables

Return to Table of Contents

Headers

• Use one to five equals signs (=) surrounding header text, with a space between markup and text.
  • One equals sign is the highest level header (largest)

  • Example: = Title =
    

  • Five equals signs is the lowest level header (smallest)

  • Example: ===== Minor =====
    

  Example: === Some Wiki Markup Basics ===
  Headers will appear in an automatically generated Table of Contents.

• More (but not much) wiki markup for headers can be found at HelpOnHeadlines.

Return to Table of Contents

Includes

• An include enables you to copy all or a portion of a page onto another page, allowing changes to one page to be automatically updated on another. This is especially useful for listing enumeration values for a function parameter on the function page, for example.
  To create an Include place the following markup in the location where you wish the data to begin on the recipient page.

  • For copying values from an enumeration:
    

    <<Include(SDL_Enumeration, , , from="== Values ==", to="== Code Examples ==")>>

    • where SDL_Enumeration is replaced by the Enumeration's name.
      

    For copying data fields from a structure:
    

    <<Include(SDL_Structure, , , from="== Data Fields ==", to="== Code Examples ==")>>

    • where SDL_Structure is replaced by the Structure's name.
      

    The basic format is

    <<Include(pagename, heading, level, from="regex", to="regex", sort=ascending|descending, items=n, skipitems=n, titlesonly, editlink)>>

    • See HelpOnMacros/Include for details if a different include becomes necessary.

    The from= and to= start markers are very literal! They will include everything following the end of the start marker and up to but not including the beginning of the end marker. (This is why the header markup is included in the above statements.) When creating an Include statement choose from= and to= parameters carefully.

Return to Table of Contents

Miscellaneous Notes

Style Guide Terminology

Some terms used in the style guides are intended to have specific meanings or purposes that may or may not be as intuitively clear as we hope. Explanations are provided here to avoid any potential confusion.

• API Page

  • Refers to any Function, Structure, or Enumeration page.

• Category Page

  • Refers to the front page of each major category found in the API by Category list.

  DRAFT

  • Any page with red

    at the top is incomplete. It should not be used as a formatting example until red

    is removed. There may be missing or extra information, unusual formatting, colors, markup, notes, etc. on these pages. They will all be cleaned up by the time red

    is removed. Please bear with us while they are in place as they help to speed up the editing process. Thank you!

• If...

  • Found at the beginning of detailed style guide sections, this indicates options for you to choose from. Select the one(s) that best suit your content given the context on the page you are editing and follow the related instructions. (See Action through Example below.)

  • In some cases a portion of the statement following If will be underlined to help you quickly scan for the option(s) that you need.

• Action:

  • The instructions immediately following Action indicate what you should do to apply the style guide guidelines. In some cases you will select an Action that is relevant to your particular content (usually from a table of options). In many cases everyone making a certain type of edit should follow the same Action in which case no options will be given.

  • Action is almost always followed by Markup or How and may also be followed by any of the other markers (see below).

  • Please read any Note or red

    comment related to the Action(s) you choose. If you are otherwise familiar with the wiki and it's markup the other sections can usually be skipped.

• Markup:

  • The instructions immediately following Markup indicate the critical markup that would be used in the text editor to complete the Action above it. If you prefer another way to achieve the same result, or prefer to use the GUI editor this information should be used to clarify the correct formatting for you to match.

• How:

  • Usually used instead of Markup, the information immediately following How describes specific actions to be taken outside of the editing window in order to complete the Action above it.

• Note:

  • The instructions immediately following Note: should be taken into consideration as necessary.

• red

  • Similar to a Note, but indicates that the noted information is especially important and should be heeded by all Contributors.

• Example:

  • Provides a direct example of the markup or points to a place in the wiki where the related Action and Markup can be observed.

Other Help

Some other wiki help that might be of interest or helpful to find quickly:

• HelpIndex

• HelpOnFormatting

• HelpOnEditing

• HelpOnSmileys

• HelpOnAdmonitions

Return to Table of Contents

Resources

Our goal is to create accurate, consistent, helpful, user-friendly documentation. We appreciate your efforts to make your additions fit into the existing framework and retain the same look and feel as much as possible.

If you have questions that aren't addressed here:

1. Search for another page that contains something similar to what you want to do and copy all the basics as much as applicable.

2. Check the other SDL Style Guides.

3. Post a question to Feedback and

include a way to contact you.

1. Post a question to the Mailing List

2. Send a comment or question to <ANTI SPAM wiki AT libsdl DOT org> for clarification.

If you have suggestions for changes or additions to this document or any other portion of the wiki please don't hesitate to contact us with your thoughts. We are happy to have the participation!

Disclaimer