From 64eec884e7456bbd1236bc43624ad3e49e4cad55 Mon Sep 17 00:00:00 2001 From: Neil Date: Sun, 18 Sep 2016 22:19:06 +1000 Subject: Updating documentation on contributing code. --- CONTRIBUTING | 20 ++++++++++++++++++++ doc/SciCoding.html | 32 ++++++++++++++++++++++++++++++++ doc/ScintillaToDo.html | 2 +- 3 files changed, 53 insertions(+), 1 deletion(-) create mode 100644 CONTRIBUTING diff --git a/CONTRIBUTING b/CONTRIBUTING new file mode 100644 index 000000000..cf70eafa6 --- /dev/null +++ b/CONTRIBUTING @@ -0,0 +1,20 @@ +Fixes should be posted to the Bug Tracker +http://sourceforge.net/p/scintilla/bugs/ + +Features should be posted to the Feature Request Tracker +http://sourceforge.net/p/scintilla/feature-requests/ + +Either send unified diffs (or patch files) or zip archives with whole files. +Mercurial patch files are best as they include author information and commit +messages. + +Questions should go to the scintilla-interest mailing list +https://groups.google.com/forum/#!forum/scintilla-interest + +Code should follow the guidelines at +http://www.scintilla.org/SciCoding.html + +Do not use SourceForge's Merge Request mechanism or message sending +feature as no one is monitoring these. +The neilh @ scintilla.org account receives much spam and is only checked +occasionally. Almost all Scintilla mail should go to the mailing list. \ No newline at end of file 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.

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.

+

+ The SCI_METHOD preprocessor definition should be used when implementing + interfaces which include it like ILexer and only there. +

Casting

@@ -255,5 +261,31 @@

Ensure there are no warnings under the compiler you use. Warnings from other compilers will be noted on the feature request.

sc.ch is an int: do not pass this around as a char.

+

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*.

+

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.

+

If you copy from an existing lexer, remove any code that is not needed since it makes it + more difficult to maintain and review.

+

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.

+

+ Properties +

+

+ 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.<lexername>.* and those that control folding to be named + fold.<lexername>.*. + Examples are "lexer.python.literals.binary" and "fold.haskell.imports". +

+

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

+

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

diff --git a/doc/ScintillaToDo.html b/doc/ScintillaToDo.html index 2995001b0..8ff64bc4b 100644 --- a/doc/ScintillaToDo.html +++ b/doc/ScintillaToDo.html @@ -31,7 +31,7 @@

Issues can be reported on the Bug Tracker - and features requested on the Feature Request Tracker. + and features requested on the Feature Request Tracker.

Scintilla Bugs -- cgit v1.2.3