Update Scintilla to v3.7.0.

1 files changed, 36 insertions, 0 deletions

diff --git a/scintilla/doc/SciCoding.html b/scintilla/doc/SciCoding.html
index a487031..a226240 100644
--- a/scintilla/doc/SciCoding.html
+++ b/scintilla/doc/SciCoding.html
@@ -124,6 +124,8 @@
 	compilers on diverse platforms with high performance and low resource usage.

 	Scintilla has stricter portability requirements to SciTE as it may be ported to

 	low capability platforms.

+	Scintilla code must build with C++03 which can be checked with "g++ --std=gnu++03".

+	SciTE can use C++11 features that are widely available from g++ 4.6, MSVC 2012 and clang 3.4 compilers.

 	</p>

 	<p>

 	To achieve portability, only a subset of C++ features are used.

@@ -139,6 +141,14 @@
 	maintaining FORTRAN programs. The union feature is not used as it can lead to

 	non-type-safe value access.

 	</p>

+	<p>

+	The SCI_METHOD preprocessor definition should be used when implementing

+	interfaces which include it like ILexer and only there.

+	</p>

+	<p>

+	Headers should always be included in the same order as given by the

+	scripts/HeaderOrder.txt file.

+	</p>

     <h3>

        Casting

     </h3>

@@ -255,5 +265,31 @@
 	<p>Ensure there are no warnings under the compiler you use. Warnings from other compilers

 	will be noted on the feature request.</p>

 	<p>sc.ch is an int: do not pass this around as a char.</p>

+	<p>The ctype functions like isalnum and isdigit only work on ASCII (0..127) and may cause

+	undefined behaviour including crashes if used on other values. Check with IsASCII before calling is*.</p>

+	<p>Functions, structs and classes in lexers should be in an unnamed namespace (see LexCPP)

+	or be marked "static" so they will not leak into other lexers.</p>

+	<p>If you copy from an existing lexer, remove any code that is not needed since it makes it

+	more difficult to maintain and review.</p>

+	<p>When modifying an existing lexer, try to maintain as much compatibility as possible.

+	Do not renumber lexical styles as current client code may be built against the earlier values.</p>

+    <h4>

+       Properties

+    </h4>

+	<p>

+	Properties provided by a new lexer should follow the naming conventions

+	and should include a comment suitable for showing to end users.

+	The convention is for properties that control styling to be named 

+	lexer.&lt;lexername&gt;.* and those that control folding to be named

+	fold.&lt;lexername&gt;.*.

+	Examples are "lexer.python.literals.binary" and "fold.haskell.imports".

+	</p>

+	<p>

+	The properties "fold" and "fold.comment" are generic and can be used by

+	any lexer.

+	</p>

+	<p>

+	See LexPython for examples of properties in an object lexer and LexHTML for a functional lexer.

+	</p>

   </body>

 </html>