Remove indentation from <programlisting> blocks in docs

Many dozens (hundreds?) of documentation code blocks were indented to
match the surrounding XML or just arbitrarily. The thing is: Inside
<programlisting> tags, similar to <pre> tags, line feeds and leading
whitespace are being preserved, which looked very awkward in the HTML
documentation. While a few files were mostly correct in this respect,
which shows that it was meant to be like that, many others were not.
This was tedious, stupid work to fix, but it had to be done.

Please note that the documentation was in no way updated content-wise.
This is also overdue, but not my focus here.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

1 files changed, 46 insertions, 46 deletions

diff --git a/docs/progGuideDB/implementation.xml b/docs/progGuideDB/implementation.xml
index 52da14d9c..e1fa05f2b 100644
--- a/docs/progGuideDB/implementation.xml
+++ b/docs/progGuideDB/implementation.xml
@@ -5,7 +5,7 @@
 <sect1>
   <title>Compiler Notes</title>
 
-  <para> 
+  <para>
     The initial implementations of AspectJ have all been
     compiler-based implementations.  Certain elements of AspectJ's
     semantics are difficult to implement without making modifications
@@ -25,7 +25,7 @@
   </para>
 
 <programlisting><![CDATA[
-  before(): get(int Point.x) { System.out.println("got x"); }
+before(): get(int Point.x) { System.out.println("got x"); }
 ]]></programlisting>
 
   <para>
@@ -36,7 +36,7 @@
     compiled, whether changes were made later, etc.
   </para>
 
-  <para>   
+  <para>
     But AspectJ implementations are permitted to deviate from this in
     a well-defined way -- they are permitted to advise only accesses
     in <emphasis>code the implementation controls</emphasis>.  Each
@@ -67,11 +67,11 @@
     can be advised only if ajc controls the bytecode for the method or
     constructor body in question.
   	The end of an exception handler is underdetermined in bytecode,
-  	so ajc will not implement after or around advice on handler join 
+  	so ajc will not implement after or around advice on handler join
   	points.
-  	Similarly, ajc cannot implement around advice on initialization 
-  	or preinitialization join points.  
-    In cases where ajc cannot implement advice, it will emit a 
+  	Similarly, ajc cannot implement around advice on initialization
+  	or preinitialization join points.
+    In cases where ajc cannot implement advice, it will emit a
     compile-time error noting this as a compiler limitation.
   </para>
 
@@ -100,35 +100,35 @@
   </para>
   <para>
   	When declaring members on interfaces, the implementation must
-  	control both the interface and the top-level implementors of 
+  	control both the interface and the top-level implementors of
   	that interface (the classes that implement the interface but
   	do not have a superclass that implements the interface).
   	You may weave these separately, but be aware that you will get
   	runtime exceptions if you run the affected top-level classes
-  	without the interface as produced by the same ajc implementation.  	
-  	Any intertype declaration of an abstract method on an interface 
-  	must be specified as public, you will get a compile time error 
-  	message indicating this is a compiler limitation if you do not 
+  	without the interface as produced by the same ajc implementation.
+  	Any intertype declaration of an abstract method on an interface
+  	must be specified as public, you will get a compile time error
+  	message indicating this is a compiler limitation if you do not
   	specify public.  A non-abstract method declared on an interface
   	can use any access modifier except protected.  Note that this is
-  	different to normal Java rules where all members declared in 
+  	different to normal Java rules where all members declared in
   	an interface are implicitly public.
-  	Finally, note that one cannot define static fields or methods 
+  	Finally, note that one cannot define static fields or methods
   	on interfaces.
   </para>
   <para>
-	When declaring methods on target types, only methods declared 
-	public are recognizable in the bytecode, so methods must be 
-	declared public to be overridden in any subtype or to be called 
+	When declaring methods on target types, only methods declared
+	public are recognizable in the bytecode, so methods must be
+	declared public to be overridden in any subtype or to be called
 	from code in a later compile using the target type as a library.
   </para>
-    
+
   <para>
     Other AspectJ implementations, indeed, future versions of ajc, may
     define <emphasis>code the implementation controls</emphasis> more
     liberally or restrictively, so long as they comport with the Java
 	language.  For example, the <literal>call</literal> pointcut does
-	not pick out reflective calls to a method implemented in 
+	not pick out reflective calls to a method implemented in
 	<literal>java.lang.reflect.Method.invoke(Object, Object[])</literal>.
 	Some suggest that the call "happens" and the call pointcut should
 	pick it out, but the AspectJ language shouldn't anticipate what happens
@@ -172,12 +172,12 @@
     </para>
 
 <programlisting><![CDATA[
-  class Test {
-      void main(String[] args) {
-          System.out.println(Test.class);        // calls Class.forName
-          System.out.println(args[0] + args[1]); // calls StringBuffer.append
-      }
-  }
+class Test {
+    void main(String[] args) {
+        System.out.println(Test.class);        // calls Class.forName
+        System.out.println(args[0] + args[1]); // calls StringBuffer.append
+    }
+}
 ]]></programlisting>
 
     <para>In short, the join point model of the current AspectJ
@@ -217,7 +217,7 @@
   </para>
 
 <programlisting><![CDATA[
-  cflow(call(void foo()) || handler(java.io.IOException))
+cflow(call(void foo()) || handler(java.io.IOException))
 ]]></programlisting>
 
   <para> will capture all join points in the control flow of a call to
@@ -236,9 +236,9 @@
   </para>
 
 <programlisting><![CDATA[
-  before(): handler(java.io.IOException) && cflow(void parse()) {
-      System.out.println("about to handle an exception while parsing");
-  }
+before(): handler(java.io.IOException) && cflow(void parse()) {
+    System.out.println("about to handle an exception while parsing");
+}
 ]]></programlisting>
 
   <para>
@@ -258,16 +258,16 @@
   </para>
 
 <programlisting><![CDATA[
-  class C {
-      double d = Math.sqrt(2);
-  }
+class C {
+    double d = Math.sqrt(2);
+}
 ]]></programlisting>
 
   <para>
     are considered part of constructors by the time AspectJ gets ahold
     of bytecode.  That is, the assignment of d to the square root of
     two happens <emphasis>inside</emphasis> the default constructor of
-    C.  
+    C.
   </para>
 
   <para>
@@ -280,15 +280,15 @@
   </para>
 
 <programlisting><![CDATA[
-  aspect A {
-      C.new(Object o) {} // implicitly calls super()
+aspect A {
+    C.new(Object o) {} // implicitly calls super()
 
-      public static void main(String[] args) {
-         System.out.println((new C()    ).d);    // prints 1.414...
-         System.out.println((new C(null)).d);    // prints 0.0
-  }
+    public static void main(String[] args) {
+       System.out.println((new C()    ).d);    // prints 1.414...
+       System.out.println((new C(null)).d);    // prints 0.0
+}
 ]]></programlisting>
-  
+
   <para>
     It is the job of an inter-type constructor to do all the required
     initialization, or to delegate to a <literal>this</literal>
@@ -302,8 +302,8 @@
   <para>Writing aspects in annotation-style is subject to the same
       bytecode limitations since the binary aspects take the same
       form and are woven in the same way.  However, the implementation
-      differences (e.g., the mechanism for implementing around advice) 
-      may be apparent at runtime.  See the documentation on annotation-style 
+      differences (e.g., the mechanism for implementing around advice)
+      may be apparent at runtime.  See the documentation on annotation-style
       for more information.
   </para>
 </sect1>
@@ -311,7 +311,7 @@
   <title>Summary of implementation requirements</title>
   <para>
 	This summarizes the requirements of our implementation of AspectJ.
-	For more details, see the relevant sections of this guide.	  
+	For more details, see the relevant sections of this guide.
   </para>
  <itemizedlist spacing="compact">
 	<listitem>
@@ -343,7 +343,7 @@
 	  <para>Implementation Caveats</para>
 		 <itemizedlist spacing="compact">
 			<listitem>
-			  <para>The initialization and preinitialization join points 
+			  <para>The initialization and preinitialization join points
 				  do not support around advice</para>
 			</listitem>
 			<listitem>
@@ -355,7 +355,7 @@
 				 </itemizedlist>
 			</listitem>
 			<listitem>
-			  <para>Declaring members on an interface in an aspect affects only 
+			  <para>Declaring members on an interface in an aspect affects only
 				the topmost implementing classes the implementation controls.</para>
 			</listitem>
 			<listitem>
@@ -363,7 +363,7 @@
 			</listitem>
 			<listitem>
 			  <para>
-                  Runtime <literal>ClassCastException</literal> may result 
+                  Runtime <literal>ClassCastException</literal> may result
                   from supplying a supertype of the actual type as an argument
                   to proceed(..) in around advice.</para>
 			</listitem>