diff --git a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
index c4ec5961..7de6c7ca 100644
--- a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
+++ b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
@@ -750,7 +750,7 @@ Assignment attempt is useful in the cases cited -- access to external objects be
 
 {{note|As a consequence of the advent of [[Void-safe programming in Eiffel|void-safe Eiffel]], an elegant language construct has been added to Eiffel which can be used in place of the assignment attempt. The [[Void-safety: Background, definition, and tools#The attached syntax (object test)|attached syntax]] can be used to test for an attached object (object test), but it can also be used as to provide a convenient [[Creating a new void-safe project#As a replacement for assignment attempt|replacement for the assignment attempt]] which does not require the separate declaration of a local variable.}}
 
-==Covariance and anchored declarations==
+==Covariance, anchored declarations, and "catcalls"==
 
 The final property of Eiffel inheritance involves the rules for adapting not only the implementation of inherited features (through redeclaration of either kind, effecting and redefinition, as seen so far) and their contracts (through the Assertion Redeclaration rule), but also their types. More general than type is the notion of a feature's '''signature''', defined by the number of its arguments, their types, the indication of whether it has a result (that is to say, is a function or attribute rather than a procedure) and, if so, the type of the result. 
 
@@ -879,7 +879,7 @@ Likewise the compiler in EiffelStudio will produce warnings in cases in which ca
 
 
 
-===Non-conforming inheritance===
+==Non-conforming inheritance==
 
 So far, our experience with inheritance is that of "conforming" inheritance ... the most commonly used type of inheritance. Conforming inheritance is what allows a direct instance (in the '''catcall''' example above) of <code>COW</code> to be attached at runtime to an entity of type <code>ANIMAL</code>. This can be a powerful modeling capability, but it is this same polymorphism facilitated by conforming inheritance that puts us in the danger of using polymorphic '''catcalls'''. 
 
@@ -890,14 +890,16 @@ In order to use non-conforming inheritance for a particular parent, we use the m
 <code>
 class
     MY_HEIR_CLASS
+
 inherit
     MY_CONFORMING_PARENT
-inherit
-    {NONE} MY_NON_CONFORMING_PARENT
+
+inherit {NONE} 
+    MY_NON_CONFORMING_PARENT
         ...
 </code>
 
-Here there are two inherit clauses, one to specify conforming parents, and one to specify non-conforming parents. The clause specifying the conforming inheritance must precede the one specifying the non-conforming inheritance.
+Here there are two <code>inherit</code> clauses, one to specify conforming parents, and one to specify non-conforming parents. The clause specifying the conforming inheritance must precede the one specifying the non-conforming inheritance.
 
 So, in this case, at runtime it is valid for a direct instance of <code>MY_HEIR_CLASS</code> to be attached to an entity of type <code>MY_CONFORMING_PARENT</code>, but not to an entity of type <code>MY_NON_CONFORMING_PARENT</code>. Accordingly, the compiler would reject any code in which an instance of <code>MY_HEIR_CLASS</code> could become attached to an entity of type <code>MY_NON_CONFORMING_PARENT</code>. Because the polymorphic attachment cannot be made, the possibility of a catcall is avoided.