From eb5d774880b77c0e239d9ed4d04ea7c8ca8ddaa6 Mon Sep 17 00:00:00 2001
From: halw <halw@abb3cda0-5349-4a8f-a601-0c33ac3a8c38>
Date: Mon, 27 Aug 2012 12:18:28 +0000
Subject: [PATCH] Author:halw Date:2012-08-24T03:19:27.000000Z

git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1170 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
---
 .../method/eiffel-tutorial-et/et-inheritance.wiki  |  2 +-
 .../eiffel-tutorial-et/et-other-mechanisms.wiki    | 14 +++++++++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
index e6ab1d04..21003b6f 100644
--- a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
+++ b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
@@ -583,7 +583,7 @@ feature
 	
 </code>
 
-Again what counts, to determine if there is an invalid name clash, is the final name of the features. In this example to of the joined features were originally called <code>f</code>; the one from <code>A</code> was called <code>g</code>, but in <code>D</code> it is renamed as <code>f</code>, so without the undefinition it would cause an invalid name clash. 
+Again what counts, to determine if there is an invalid name clash, is the final name of the features. In this example, two of the joined features were originally called <code>f</code>; the one from <code>A</code> was called <code>g</code>, but in <code>D</code> it is renamed as <code>f</code>, so without the undefinition it would cause an invalid name clash. 
 
 Feature joining is the most common application of uneffecting. In some non-joining cases, however, it may be useful to forget the original implementation of a feature and let it start a new life devoid of any burden from the past. 
 
diff --git a/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki
index fc8562ec..ad5bd55d 100644
--- a/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki
+++ b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki
@@ -20,7 +20,7 @@ Manifest constants are also available for strings, using double quotes as in: <c
 
 ===Verbatim strings===
 
-There may be a need for a manifest string that represents a multi-line formatted string. In Eiffel we call this type of manifest string a '''verbatim string''', and there is a special syntax for specifying verbatim strings in Eiffel code. Verbatim strings are either '''aligned''' or '''non-aligned'''. Aligned verbatim strings will automatically be adjust so that their leftmost line contains no "white space" to the left of the first text character. For non-aligned verbatim strings, the white space is left untouched. You use a slightly different way of specifying each type of string. For example, this aligned verbatim string:
+You may occasionally have a need for a manifest string that represents a multi-line formatted string. In Eiffel we call this type of manifest string a '''verbatim string''', and there is a special syntax for specifying verbatim strings in Eiffel code. Verbatim strings are either '''aligned''' or '''non-aligned'''. Aligned verbatim strings will automatically be adjusted so that their leftmost line (the line with text characters closest to the left margin) contains no "white space" to the left of the first text character. For non-aligned verbatim strings, the white space is left untouched. You use a slightly different way of specifying each type of string. For example, this aligned verbatim string:
 
 <code>
     my_aligned_string: STRING =
@@ -68,6 +68,18 @@ will print like this:
 
 The difference in declaration is that the aligned verbatim string uses as its "opener" the double-quote plus bracket combination, " <code>"[</code> ", and the bracket plus double quote, " <code>]"</code> ", as its "closer". The non-aligned verbatim string uses braces, " <code>{</code> " and " <code>}</code> " instead of the bracket.
 
+The syntax for specifying verbatim strings allows an option for the situation in which the specified string might conflict with the "closer". You can include a simple string between the double quote and the bracket on each end of the verbatim string to guarantee uniqueness. Here's our aligned verbatim string with the simple string " <code>*?</code> " inserted in the opener and closer:
+
+<code>
+    my_aligned_string: STRING =
+    "*?[
+      Thrice hail the still unconquered King of Song!
+          For all adore and love the Master Art
+          That reareth his throne in temple of the heart;
+   And smiteth chords of passion full and strong
+      Till music sweet allures the sorrowing throng!
+    ]*?"
+</code>
 
 
 ==Constant attributes==