Fix some incorrect asciidoc syntax

Signed-off-by: Dan McGee <dan@archlinux.org>

1 files changed, 18 insertions, 18 deletions

diff --git a/HACKING b/HACKING
index 537d9a37..c659ff0b 100644
--- a/HACKING
+++ b/HACKING
@@ -12,10 +12,10 @@ Coding style
 1.  All code should be indented with tabs. (Ignore the use of only spaces in
     this file) By default, source files contain the following VIM modeline:
 +
-[code,C]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[source,C]
+-------------------------------------------
 /* vim: set ts=2 sw=2 noet: */
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 2.  When opening new blocks such as 'while', 'if', or 'for', leave the opening
     brace on the same line as the beginning of the codeblock. The closing brace
@@ -24,8 +24,8 @@ Coding style
     braces, even if it's just a one-line block. This reduces future error when
     blocks are expanded beyond one line.
 +
-[code,C]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[source,C]
+-------------------------------------------
 for(lp = list; lp; lp = lp->next) {
   newlist = _alpm_list_add(newlist, strdup(lp->data));
 }
@@ -40,14 +40,14 @@ while(it) {
   free(it);
   it = ptr;
 }
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 3.  When declaring a new function, put the opening and closing braces on their
     own line. Also, when declaring a pointer, do not put a space between the
     asterisk and the variable name.
 +
-[code,C]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[source,C]
+-------------------------------------------
 alpm_list_t *alpm_list_add(alpm_list_t *list, void *data)
 {
   alpm_list_t *ptr, *lp;
@@ -58,7 +58,7 @@ alpm_list_t *alpm_list_add(alpm_list_t *list, void *data)
   }
   ...
 }
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 4.  Comments should be ANSI-C89 compliant. That means no `// Comment` style;
     use only `/* Comment */` style.
@@ -101,37 +101,37 @@ Currently our #include usage is in messy shape, but this is no reason to
 continue down this messy path. When adding an include to a file, follow this
 general pattern, including blank lines:
 
-[code,C]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[source,C]
+-------------------------------------------
 #include "config.h"
 
 #include <standardheader.h>
 #include <another.h>
 #include <...>
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 Follow this with some more headers, depending on whether the file is in libalpm
 or pacman proper. For libalpm:
 
-[code,C]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[source,C]
+-------------------------------------------
 /* libalpm */
 #include "yourfile.h"
 #include "alpm_list.h"
 #include "anythingelse.h"
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 For pacman:
 
-[code,C]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[source,C]
+-------------------------------------------
 #include <alpm.h>
 #include <alpm_list.h>
 
 /* pacman */
 #include "yourfile.h"
 #include "anythingelse.h"
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 GDB and Valgrind Usage
 ~~~~~~~~~~~~~~~~~~~~~~