[latexila] Improve/simplify the HACKING file

[Sébastien Wilmet <swilmet src gnome org>]

commit 71321d14b37449156b8d39159c8b91cd00b3eee0
Author: Sébastien Wilmet <swilmet gnome org>
Date:   Thu Nov 2 10:48:58 2017 +0100

    Improve/simplify the HACKING file
    
    I think we can assume that the contributor has basic knowledge of Git
    and gdb.

 HACKING |   91 +++++++++++++++++++-------------------------------------------
 1 files changed, 28 insertions(+), 63 deletions(-)
---
diff --git a/HACKING b/HACKING
index c114287..3b47b19 100644
--- a/HACKING
+++ b/HACKING
@@ -1,88 +1,53 @@
-Guidelines for LaTeXila
-=======================
+How to contribute to LaTeXila
+=============================
 
-LaTeXila source code is maintained using the Git version control system and is
-available at the following location:
+The Git version control system is used. Read the following wiki pages to know
+how to create and send patches to bugzilla, and the conventions for the commit
+messages:
 
-    git://git.gnome.org/latexila
-
-A web interface is available at:
-
-    http://git.gnome.org/browse/latexila
-
-You can download the source code from the Git repository by doing:
-
-    $ git clone git://git.gnome.org/latexila
-
-Later, to take the new commits you just have to do:
-
-    $ git pull
+    https://wiki.gnome.org/Git
+    https://wiki.gnome.org/Git/WorkingWithPatches
+    https://wiki.gnome.org/Git/CommitMessages
 
 An easy way to build LaTeXila and its dependencies is to use jhbuild
 (gnome-world moduleset). Example of a jhbuildrc file for LaTeXila:
 
     https://people.gnome.org/~swilmet/latexila/jhbuildrc
 
-Commits
-=======
-
-To create a patch, make first one or several commits (in another branch) and
-then use the 'git format-patch' command. You can submit your patch to the
-GNOME bugzilla.
-
-A GitHub repository is available, so you can fork it easily:
-
-    https://github.com/GNOME/latexila
-
-Git commits should have maximum 72 characters for the first line, followed by a
-blank line and then a longer description.
-
 Code conventions
-================
+----------------
 
-For consistency, there are some conventions to follow when coding.
+For consistency, there are some conventions to follow for the code.
 
 For Vala and C:
-    - no trailing spaces
-    - use blank lines to space out blocks of code (only one blank line is enough).
-    - space out each case in a switch, i.e. have a blank line after each 'break;'.
-    - as a general rule of thumb, when modifying a file use the same coding
+    - No trailing spaces.
+    - Use blank lines to space out blocks of code (only one blank line is enough).
+    - Space out each case in a switch, i.e. have a blank line after each 'break;'.
+    - As a general rule of thumb, when modifying a file use the same coding
       style of that file.
 
 For Vala:
-    - indentation: 4 spaces
-    - lines: 90 characters maximum (in some cases it can be a little more)
-    - /* ... */ comments for delimiting code sections
-    - // ... comments otherwise (e.g. for explaining just one line)
-    - curly braces are always on a separate line
-    - for one-line blocks (if, for, while, etc), no curly braces
-    - some spaces almost everywhere:
+    - Indentation: 4 spaces.
+    - Lines: 90 characters maximum (in some cases it can be a little more).
+    - /* ... */ comments for delimiting code sections.
+    - // ... comments otherwise (e.g. for explaining just one line).
+    - Curly braces are always on a separate line.
+    - For one-line blocks (if, for, while, etc), no curly braces.
+    - Some spaces almost everywhere:
         - function (blah);                // not function(blah);
         - int num = 5;                    // not int num=5;
         - if (! foo)                      // not if (!foo)
         - for (int i = 0 ; i < max ; i++) // not for(int i=0;i<max;i++)
         - etc...
-    - do not use 'var' for declaring variables, unless the type is very long.
-      The type of a variable is a form of self-documentation.
+    - Do not use 'var' for declaring variables, unless the type is very long.
+      The type of a variable is useful to understand the code, it is a form of
+      self-documentation.
 
 For C:
-    - follow the GNU coding style:
+    - Follow the GNU coding style:
       https://developer.gnome.org/programming-guidelines/stable/c-coding-style.html.en
-    - no maximum line length (but short lines are better)
-    - only /* ... */ comments (for C89 compatibility)
-    - spacing differences with Vala:
+    - No maximum line length (but short lines are better).
+    - Only /* ... */ comments (for C89 compatibility).
+    - Spacing differences with Vala:
        - if (!foo)
        - for (int i = 0; i < max; i++)
-
-Debug
-=====
-
-How to debug LaTeXila with gdb?
-    Build LaTeXila with the option -g in the CFLAGS.
-
-    Here is how you can get the backtrace after a crash:
-    $ gdb latexila
-    > run
-    [segmentation fault]
-    > backtrace
-    > quit