SciTE

SciTE Documentatation

Standard Editing

Text editing in SciTE works similarly to most Macintosh or Windows editors with the added feature of automatic syntax styling. SciTE will only edit one file at a time, but does list recently opened files on the File menu making it easier to open recent files. There are two panes in SciTE, the editing pane and the output pane. The output pane is located either to the left of the editing pane or below it. Initially it is of zero size, but it can be made larger by dragging the divider between it and the editing pane. The Edit | Vertical Split command can be used to move the output pane beneath the editing pane.

SciTE can perform commands to compile or run source files with the output from these commands directed into the output pane.

For example, if Python is installed on the machine, open a new document, type

	print "Hi"

Save the document as printhi.py.
The document should now appear coloured as SciTE is using the file's extension to decide upon the syntax styling to use:

	print "hi"	

	>python -u printhi.py
	hi
	>Exit code: 0

SciTE partially understands the error messages produced by Python, GCC, Visual C++ and other tools which use the same format as one of these. To see this, add a mistake to the Python file by adding a second line to make the file:

	print "hi"
	mistake	

Perform the Tools | Go command. The results should look like:

	>python -u printhi.py
	hi
	Traceback (innermost last):
	  File "printhi.py", line 2, in ?
	    mistake
	NameError: mistake
	>Exit code: 1

While it is easy to see where the problem is in this simple case, when a file is larger the Tools | Next Message command can be used to view each of the reported errors. Upon performing Tools | Next Message, the first error message in the output pane is highlighted with a yellow background, and an error indicator is displayed for the appropriate line in the editing pane. The caret is moved to this line and the pane is scrolled if needed to show the line. SciTE now looks like this:

SciTE now understands both the file name and line number parts of error messages in most cases so can open another file (such as a header file) if errors were caused by that file. This feature may not work where the file name is complicated by containing spaces or ".."

If command execution has failed and is taking too long to complete then the Tools | Stop Executing command can be used.

Properties file

Much of SciTE's behaviour can be changed by editing the properties files.

There are two properties files used, a global properties file found in the directory of the executable called "SciTEGlobal.properties" and a local one which may be present in the same directory as the file being edited called "SciTE.properties". Settings in the local properties file override those in the global properties files. The main use of the local properties files is to change the effects of the Compile, Build and Go commands for the files in a directory. For example, I use the javac compiler from the Java Development Kit for most work, so SciTEGlobal.properties sets the command for compiling .java files to "javac". If I want to use the jvc compiler for the files in one directory, then the SciTE.Properties file in that directory contains an entry setting the command to "jvc".

There are commands in the Tools menu for opening the global and remote properties files.

The files are in approximately the same format as Java properties files which have a simple text format. Lines that start with '#' or that are completely blank are comments. Other lines are of the form

variable=value

For long values, a '\' character at the end of the line continues that value on the next line. Values may include the values of other variables by using $(variablename). There are some variables set by the environment to access the name of the current file as well:

FilePath is the full path of the current file.
FileDir is the directory of the current file without a trailing slash.
FileName is the base name of the current file.
FileExt is the extension of the current file.
FileNameExt is $(FileName).$(FileExt).

Some featues use file name patterns to see which variable to use. For example, the lexer variable can be specialised for a particular file, or a group of files based upon wildcard matching so:
lexer.makefile=makefile indicates that the lexer called "makefile" should be used on files called "makefile".
lexer.*.cxx=cpp indicates that the lexer called "cpp" should be used on files with a "cxx" extension.
Bug: This is currently broken and only works for the second type.

Defined variables in properties files

tabsize	Sets the size of a tab as a multiple of the size of a space character in the style of the first style definition.
back fore size font	Define the default style attributes when an individual style does not explicitly set them. If these options are not set, then default text is black on white, Verdana 8 point. Colour values are represented as in HTML, a '#', followed by 3 2 hex digit values for the red, green and blue components of the colour. For example, "#00FF00" is green.
position.left position.top position.width position.height	Set the initial window size and position. If these are ommitted or set to 0 then the environments defaults are used. Currently, the GTK+ version uses hard coded sizes rather than these.
are.you.sure	The classic GUI question. Normally, when SciTE is about to close a file which has unsaved edits it asks this annoying question. To turn off the question, set are.you.sure to 0 and files will be automatically saved without bothering the user. To abandon edits to a file use the New command. New always asks "Are you sure?" giving an opportunity to not save the file.
view.whitespace	Setting this to one makes SciTE start up with whitespace visible.
line.numbers	Setting this to one makes SciTE start up with a column of line numbers displayed to the left of the selection margin.
use.palette	Setting this to one makes SciTE use a palette to enable it to display more colours on 8 bit displays. Without this option SciTE will only display with colours already available which is normally the 20 colour Windows system palette. The downside of turning on this option is that there will be some flashing as windows are activated. This option has no effect on GTK+ where a palette is always used.
selection.fore selection.back	Sets the colours used for displaying selected text. If one of these is not set then that attribute is not changed for the selection. The default is to show the selection by changing the background to light grey and leaving the foreground the same as when it was not selected.
caret.fore	Sets the colour used for the caret. This only works on GTK+. On Windows the caret blinks instead.
split.vertical	If set to 1 then the output pane is to the left of the editing pane, if set to 0 then the output pane is below the edinting pane.
open.filter	This is a complex expresion used for determining the file types that will be available in the open file dialog. For each type of file, there is some explanatory text, a '|' character, some file patterns, and another '|' character. In the distributed SciTEGlobal.properties file, the line continuation character '\', is used to spread these items out, one per line. These file types appear in the "Files of type:" pull down. The first item is the default, so you may wish to change the first item to include the file types you commonly open. This option has no effect on GTK+ where a filter of * is always in effect.
find.command	The Find in Files command works in a similar way to the building commands executing a command line tool with output redirected to the output pane. If the command produces output understood by one of the error output passes, as does grep, then the F4 and Shift+F4 keys can be used to move through all the matches. The $(find.what) and $(find.files) variables can be used to use the values from the Find in Files dialog.
find.files	This is the default set of files to search through using the Find in Files command.
code.page	To support a DBCS language such as Japanese, a code page can be set here. This ensures that double byte characters are always treated as a unit so the caret is never located between the two bytes of a double byte character. This option has no effect on GTK+ where SciTE only supports single byte character sets.
lexer.filepattern	A lexer splits a file up into syntactic pieces. SciTE can then display these pieces in different visual styles. Several lexers are available in SciTE for some of the popular programming languages such as Python, Java, C/C++, JavaScript and VB. Often several file extensions (.cpp, .cc, .h) can map to one language (C++) and hence one lexer. These settings associate a file name with a lexer.
keywords.filepattern keywordclass.lexer	Most of the lexers differentiate between names and keywords and use the keywords variables to do so. To avoid repeating the keyword list for each file extension, where several file extensions are sed for one language, a keywordclass variable is defined in the distributed properties file although this is just a convention.
style.lexer.stylenumber	The lexers determine a style number for each lexical type, such as keyword, comment or number. These settings determine the visual style to be used for each style number of each lexer. The value of each setting is a set of ',' separated fields, some of which have a subvalue after a ':'. The fields are font, size, fore, back, italics and bold. The font field has a subvalue which is the name of the font, the fore and back have colour subvalues, the size field has a numeric size subvalue, and bold and italics have no subvalue. The value "fore:#FF0000,font:Courier,size:14" represents 14 point, red Courier text.
command.compile.filepattern command.build.filepattern command.go.filepattern	These settings choose which commands to execute when the Compile, Build or Go menu items are selected.
command.go.needs.filepattern	Sometimes a file must be compiled or built before it can be run. If this is the case, this setting indicates what command needs to be run to perform the compile or build step before running the file. When a file is compiled, this is noted and future runs will not perform a compile or build.
autocompletion.root	This is a feature of demonstration mode and will go away in future versions.
fn.function	This is a feature of demonstration mode and will go away in future versions.

Supporting a new language

For languages very similar to existing supported languages, which may only differ in a minor feature such as the keywords used, the existing lexers can often be reused. The set of keywords can then be changed to suit the new language. Java and JavaScript could have reasonably reused the C++ lexer. The Java lexer was added only to support doc comments.

For languages that can not be lexed with the existing lexers, a new lexer can be coded in C++.

The open.filter should be modified to include the file extensions used for the new language and entries added for command.compile, command.build, command.go and command.go.needs for the language.