aboutsummaryrefslogtreecommitdiffhomepage
path: root/doc/SciCoding.html
diff options
context:
space:
mode:
authorNeil <nyamatongwe@gmail.com>2016-09-18 22:19:06 +1000
committerNeil <nyamatongwe@gmail.com>2016-09-18 22:19:06 +1000
commit64eec884e7456bbd1236bc43624ad3e49e4cad55 (patch)
tree3114910412f40d71a6d912979e735f3e435d42ea /doc/SciCoding.html
parenta7e278ce6ef8269b3c13808dfc4648ad0ab79d87 (diff)
downloadscintilla-mirror-64eec884e7456bbd1236bc43624ad3e49e4cad55.tar.gz
Updating documentation on contributing code.
Diffstat (limited to 'doc/SciCoding.html')
-rw-r--r--doc/SciCoding.html32
1 files changed, 32 insertions, 0 deletions
diff --git a/doc/SciCoding.html b/doc/SciCoding.html
index 2e6e211c7..c6dd39536 100644
--- a/doc/SciCoding.html
+++ b/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,10 @@
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>
<h3>
Casting
</h3>
@@ -255,5 +261,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>