fix HACKING asciidoc file.

The HACKING file seemed to be broken :
http://archlinux.org/pacman/HACKING.html

And indeed, running asciidoc HACKING issued a number of warnings :

WARNING: HACKING: line 27: missing [paradef-default] C-style entry
type:  numbered : expected  1  got  3
WARNING: HACKING: line 44: list item 3 out of sequence
WARNING: HACKING: line 49: missing [paradef-default] C-style entry
type:  numbered : expected  2  got  4
WARNING: HACKING: line 62: list item 4 out of sequence
type:  numbered : expected  3  got  5
WARNING: HACKING: line 69: list item 5 out of sequence
type:  numbered : expected  4  got  6
WARNING: HACKING: line 75: list item 6 out of sequence
type:  numbered : expected  5  got  7
WARNING: HACKING: line 83: list item 7 out of sequence
WARNING: HACKING: line 104: missing [paradef-default] C-style entry
WARNING: HACKING: line 116: missing [paradef-default] C-style entry
WARNING: HACKING: line 126: missing [paradef-default] C-style entry

I just followed the syntax example there :
http://www.methods.co.nz/asciidoc/userguide.html#X56
And all is fine now :)

Signed-off-by: Xavier Chantry <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>

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:
 +
-[C]
-code~~~~~~~~~~
+[code,C]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 /* vim: set ts=2 sw=2 noet: */
-code~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 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 @@ code~~~~~~~~~~
     braces, even if it's just a one-line block. This reduces future error when
     blocks are expanded beyond one line.
 +
-[C]
-code~~~~~~~~~~
+[code,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;
 }
-code~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 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.
 +
-[C]
-code~~~~~~~~~~
+[code,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)
   }
   ...
 }
-code~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 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:
 
-[C]
-code~~~~~~~~~~
+[code,C]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 #include "config.h"
 
 #include <standardheader.h>
 #include <another.h>
 #include <...>
-code~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Follow this with some more headers, depending on whether the file is in libalpm
 or pacman proper. For libalpm:
 
-[C]
-code~~~~~~~~~~
+[code,C]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 /* libalpm */
 #include "yourfile.h"
 #include "alpm_list.h"
 #include "anythingelse.h"
-code~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 For pacman:
 
-[C]
-code~~~~~~~~~~
+[code,C]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 #include <alpm.h>
 #include <alpm_list.h>
 
 /* pacman */
 #include "yourfile.h"
 #include "anythingelse.h"
-code~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 /////
 vim: set ts=2 sw=2 syntax=asciidoc et: