SciTE Tips

SciTE is a highly customizable programming editor that has been ported to multiple platforms like Windows and Linux. You can download and find more information on the editor at:

Table of Contents:

To the main page.


Lots of files come with SciTE but I just keep the most important ones in a directory that's in my path environment variable. The basic files include:
SciTE.exe,,, SciLexer.dll, SciTEDoc.html
I also keep any files with the .properties extension related to the programming languages I work most with, such as for C/C++ programming and and for web design. The keeps a list of words you want to use as abbreviations and what you want to replace those words with. You could even have a template for comments and replace the word comment with the structure you use for comments. The file has settings for makefiles and files created by or for other common programming tools. To customize any of your editor settings, edit the file. You can also customize SciTE.Properties to create properties that only apply in the directory you're working in or the to create properties that apply to a directory and the subdirectories beneath it. However, these files are not necessary.

There are other files besides these you may want to install. There are files with the .api extension such as c.api that can be useful when you're programming with a specific language and want help remembering command syntax. There are also Lua files which can extend the editor even further with custom built scripts. I'll get into how I customize my Lua files later on, but I have a SciTEStartup.lua file that handles initialization by calling extman.lua. I use the Lua script extman.lua to allow several Lua scripts to run without colliding on common resources. The rest of my Lua scripts are in a scitelua subdirectory underneath the directory I keep SciTE in, so that I can keep track of all of them.

SciTE is not a portable app. You can't just copy it onto your USB drive or into another directory on another machine and go. The main reason is that it looks for your file and usually in places where you don't want to keep it. I keep mine in the same directory as SciTE. However, if you want to keep it in any place other than the default location, you must set the environment variable SciTE_HOME to let SciTE know where to find this file. You can either put the variable in a batch file before you invoke SciTE using the file or edit your environment variable permanently for that operating system. To edit the environment variable in Windows XP, go to the Start menu. Select Settings and then Control Panel. Click on System on Advanced Tab. Click on Environment Variables. Add a new User variable (click New) with Variable name: SciTE_HOME and Variable value set to the directory where SciTE resides. You can now keep all your major SciTE related files together in that particular location. For SciTE on Linux, I haven't had much luck adjusting the SciTE_HOME environment variable. I just let the files end up in their default directories. If you do use it, you'll probably need to make sure all SciTE related files including the application are in the directory you've indicated.

There is a portable app compilation of SciTE. Check the site's forum for more information and a link to it. There's also a version of SciTE for Windows called sc1 which is available at the Download section of the Scintilla project on Sourceforge. The executable is compressed to save file space and does not need dlls or properties files to run.


The main way to customize the editor is by editing the file. There is some help at the SciTE web site. The same information is also accessible when you use the Help menu and choose SciTE Help if you have the .html files that came with the distribution. However, some of this information isn't the most self-explanatory. I'll go into how I customize my in detail in this section. If there's interest, I'll upload a copy of my settings as a separate file that's easier to download when I get a chance.

Customizing using Lua

You can find more information on Lua scripts for SciTE at the SciTE Scripts page on There are several great scripts to choose from. They can add some wonderful extra functionality to SciTE.

In the file, you can set a default Lua script to run and set other Lua related properties. I set my startup Lua script to SciTEStartup.lua. It causes extman.lua to run at startup when the SciTEStartup.lua script is called. My SciTEStartup.lua file only contains:

You'll find extman.lua at the Scite Scripts page. I picked scripts that I would find most useful from the SciTE Scripts page and wrote a few of my own and placed them in a subdirectory under SciTE defined by the property. The extman.lua program searches for all the files in the subdirectory indicated by It also sets up items for the Tools menu for each scite_Command entry it finds in a Lua file. The one thing I don't like about extman.lua is that it does a directory listing to find out what files are in your Lua subdirectory. When it does this, it executes or shells out to create a temporary file with that listing. I'm not fond of where it puts the file and it can do some annoying things with changing the focus of windows when it executes. A fix was to use the SciteOther library to replace the os.execute with a nicer implementation. I have my own fix. I ran extman.lua once to set up my temporary file with a directory listing. I moved the temporary file (on Windows, it's scite_temp1 and it'll be found in your topmost level directory on the drive you're running on) to the directory where SciTE is located. I edited extman.lua to point to this file and commented out the part that executes the code to create the directory file in the first place. I made sure that the code in extman.lua that tells where the temporary file is points to the directory where SciTE is, not my top level directory or a temp directory. That solves both issues I have with extman.lua, losing focus in my editor window on startup and leaving a temporary file with a directory listing where I don't want it.

If you're using Lua files including extman.lua on Linux, make sure all your paths use forward slashes instead of backslashes. The temporary file trick for extman.lua also works in Linux, but the scite_temp1 file had to be in a slightly different format to work properly. Create the scite_temp1 file once. Comment out the code related to creating the file during each run. Tell extman.lua where to look for the file with the correct path and file name. All lua files listed in scite_temp1 need their full path and file name not just the lua file name like on Windows. I also had to make sure the end of line characters in that file only contained a line feed and not a carriage return and line feed.

Some of the other Lua scripts I've found useful are:

Most of the scripts I use are available from the SciTE Scripts page. I did make a few changes to some to work properly in later versions of SciTE that use Lua 5.1. I've made changes to switch_buffers.lua to keep it from showing a blank for an Untitled tab and to let it show the current buffer too. You'll find these changes described at the SciTe Scripts web site as well. I also made the changes I mentioned above to extman.lua.

If you're interested in exporting documents to other formats such as ODT (Open Document) used by programs like LibreOffice or OpenOffice, have a look at the Lua Exporters scripts on the Scite Scripts page.

Customizing for File Types

You can customize SciTE to work with specialty file types. Below are some of the customizations I've experimented with.


Paragraph Wrapping

While I use a word processor for stories, articles or 'zines, I use a programming editor for documentation, notes or preliminary drafts. It's usually faster to get up and running and start typing in a programming editor than to wait for a word processor to display. However, programming editors usually do not have the features to do full-fledged word processing such as formatting a document nicely for printing or handling line wrapping of text and setting of margins well. SciTE gives some interesting options though.

I used to set my previous programming editor, PFE, to a line width of 65. That gives 6.5 inches of the paper, so an inch on either side for margins can be added later by the word processor. Sometimes PFE would line wrap okay and sometimes I would need to use the Reformat Paragraph function. When I copied the text to my word processor, if the line wrapping was inappropriate, I'd have to go in and delete carriage return/linefeeds for the word processor to try to wrap the text properly. When I switched to SciTE, I was dismayed to find out it didn't even handle line sizes for text wrapping. Things improved when I found there was a Lua script to reformat paragraphs similar to PFE. (Someone else had missed that feature as well.) However, I've since found an even better way to handle the situation.

I like to write my paragraphs the old-fashioned way, with a five space indent at the beginning, line wrapped text (after character 65 if I'm using a monospaced font) and a newline at the end of the paragraph. Instead of having an editor try to line wrap at a particular line width for you, I discovered you can leave a paragraph intact with no line wrap and a word processor can line wrap appropriately for you. Hitting the enter key, between paragraphs, marks the end of a paragraph for a word processor. I was having to take out extra carriage return/linefeed sequences from my programming editor if the wrapping wasn't done appropriately. Leaving the sequences out altogether makes it much easier to transition the information to the word processor. However, it does make it hard to read what you're typing in the text editor. SciTE has a nice feature to mitigate that issue. You can check the Wrap menu item from the Options menu. It will automatically display text on the screen as if it were wrapped and will resize to whatever size you make your editor screen. I now have a new technique for writing my stories in my favorite programming editor.

If I'm going to print a story, I'll move it to my word processor. You can use properties like print.margins, print.header.format and print.footer.format to customize the look of output if you want to solely use SciTE though. If I'm going to convert a story to HTML, I can work with the story in text format directly in my programming editor. Luckily, the above technique works equally well for files that are going to be converted to HTML. See converting from text to HTML for a how-to example.

Document Checking

Since I'm now doing more document editing in SciTE, I wanted to find ways to do functions I might do in an ordinary word processor such as check line and word count, check spelling and grammar. I looked into what tools were available to integrate with editors and was rather disappointed. I've highlighted some of my favorite finds including a spell-checker on my writing tools page. I'll discuss specifically how to use some of these applications in conjunction with SciTE below.

I wanted to integrate a stand-alone spelling or grammar checker into SciTE using the command.go property. I was hoping I could output an error list from the checker into a format similar to a compiler, so I could display errors in the output pane of SciTE and jump to the problems. A couple of issues arose. Obstacle one, you can only specify a file and a line number for an error. SciTE only supports column (and line) specific errors through the Tidy error format which doesn't support file names well. Also, you'd need to turn on the property to even spot the column. So, file and line number correction (without going to a specific column) isn't the worst issue in the world. Obstacle two, I needed to find a spelling or grammar checker that could output into a format that I could reformat in the appropriate manner. That's where I hit my problem. There are several old freeware spelling checkers and even some grammar checkers at various ftp sites. There's no source code and they mainly appear to be interactive. Not too useful. I checked for popular Open Source options that would work with programs like Open Office and Abiword. Another dead end. Many of these programs were written for Java or .Net. I wanted something fast and compileable, preferrably in C or C++. What little I did find that was written in C/C++ was built on top of so many libraries that it was a nightmare to try to make everything compile, build and play together nicely. Whatever happened to the Unix/Linux concept of small, discrete components that do one task well? So, unable to find any programs that did exactly what I wanted, I searched for some other options and finally found some.

To integrate an outside program such as my Perl spell-checker script or hunspell, you can add it to SciTE's Tools menu (as Build and Go commands) with lines such as any of the following:

command.go.$(file.patterns.text)=perl $(SciteUserHome)/ "$(FilePath)"$(file.patterns.text)=$(SciteUserHome)/hunspell -d  $(SciteUserHome)/en_US -u3 "$(FilePath)"*.html;*.htm=$(SciteUserHome)/hunspell -d  $(SciteUserHome)/en_US -H -u3 "$(FilePath)"

File Comparison

There are several good file comparison utilities out there. Ordinarily, I'd use them standalone. I found it difficult to make use of a file comparison utility within SciTE since I pretty much ended up specifying the file I was currently looking at, but I had no good way to specify the file I wanted to compare it to. Quite by accident, I ran across an option to pass a parameter to a program or script. If you choose View from the menu and then choose the Parameters option, you can specify other information that can be used when a command is executed. One of my favorite comparison programs, diffh, is actually a utility that works with the diff program and creates an html output of the differences. It can be difficult to launch because you need to call several programs and pipe output from one to another via the command line. I figured SciTE might have a useful way of hiding some of that complexity when I want to run this utility.

There's more information on diffh and setting up a script file to call it on my writing tools page. Once you have a script to run the appropriate commands, you can add it to file using syntax similar to the following:*=Difference
command.1.*.txt;*=*$(SciteUserHome)/scitetools/scitediff.bat "$(FilePath)" "$(1)"

Note the asterisk in front of the batch file path and name. This tells SciTE to bring up the Parameters dialog so a user can enter the second file name to use in the comparison. It's not quite as convenient as a dialog box for opening files (with directory and path information). However, if you can copy the file name and path from your file manager (or type it in by hand), you'll be able to tell SciTE the name of the second file you wish to compare to the currently open file. The $(1) parameter holds the information of the first parameter in the Parameters dialog box. You can use this trick with other scripts as well. Place an asterisk after the equals and before the program or script to execute in any command setting to call up the Parameters dialog. If you want the values of other parameters in the dialog, you can change the 1 to 2, 3 or 4 accordingly.

To make it easier to get the name of the second file, I can ask SciTE to do it for me. Adding the following to the file, invokes Lua and prints the name of the current file in the output pane when a user presses Ctrl-3.*=File Na&me
command.3.*=trace $(FilePath)

So, if you have both files you want to compare open in SciTE, go to the second file, press Ctrl-3 and then copy the file path and name of the file shown displayed in the output pane to the clipboard. Go to the first file, press Ctrl-1, and paste the file path and name from the clipboard to the first entry in the Parameters dialog. Click the Execute button and you should see the differences between the files appear (unless there are no differences between the two files).


Useful HTML Properties

In the file, I have the following settings for working with hypertext and xml files. I've set to 1 which will generate the closing tag for every opening HTML opening tag that needs one. If this is annoying, you can turn it off. Setting command.go for web related files to the full name of the file allows those files to be sent to the default web browser via the command line program. You can also specifically name a browser (including full path and file name) in front of the name of the web file to call the browser with that web file name.

Customizing an api

I've created my own custom html.api file. (If anyone's interested in seeing the entire file, let me know and I can upload it.) The html.api I created contains information of the following nature:

html xmlns="" xml:lang="en"> ! hypertext markup tag - declaring start of hypertext
class=" ! style attribute - tells what type of style class to apply

To make sure SciTE can find it, a line needs to be added in the file telling what file types associate with that api file and where the api file is. Here's how I added my html.api file to my properties:


Once you have an api file, you can customize calltips and symbol completion. Here's what I did for my html.api file. I've set the autocomplete function to try to offer the Complete Symbol suggestion based on commands in the api file after a user types the less than symbol or a less than followed by a slash. I've set the calltip function to have Show Calltip activate after the question mark or equals sign is typed. I've told it that calltip parameter entries are separated by a space or double quote. The calltip ends at the greater than sign. This tries to simulate what a html tag looks like. It's started with a less than sign. For a closing tag only, a slash may appear next. I've treated the attributes as parameter lists. I've ended with a greater than sign. In the api file, any information after an exclamation mark is treated as a definition instead of part of the actual command. A calltip appears when you type a question mark or equals sign after an attribute. The equals is part of the actual HTML syntax. The question mark is a shortcut to ask for help.

calltip.hypertext.parameters.start= ?=
calltip.hypertext.parameters.separators= " 

Other HTML Tricks

If you're interested in reusing your HTML information, there's an interesting technique for doing so using makefiles. You don't need a fancy GUI HTML editor that supports templates. It works just fine with SciTE or any other editor. It's a nice alternative to server side includes which can take more processing time on the server.

If you're interested in converting text to HTML, I've included some information on how I usually do so for my works of fiction.

Compatibility with Commercial Tools

My place of employment uses Adobe Contribute and Dreamweaver for web development. I prefer to work with SciTE. The commercial tools use a protocol for check-in and check-out of files so that multiple developers won't overwrite each others' changes. In order to keep using SciTE, I wrote Perl scripts which could follow a check-in/check-out procedure and integrated them with the editor through the Tools menu. Unable to find a good version of an Open Source program to apply Dreamweaver style template updates to a file, I also wrote a short C program to do so. I can now update web page files much faster than the Dreamweaver and Contribute users at work and don't have to worry about any of us over-writing each others' work. If there's interest, I can share some of my code and techniques. Contact me through my XHTMLDesign or CppDesign mailing lists if you want to discuss the topic further.


With makefiles, I had to make sure tabs were treated as tabs instead of replaced by spaces. As mentioned in the Customizing section, I set the following two properties to allow actual tabs in the file.


If you're interested in using makefiles with HTML for code reuse or in place of templates, check out the information on one way to do it in the mingw FAQ. You can also run your makefiles through the Go option on the Tools menu. The instruction below, which can be added to, requires that your make program be in your environment path. Otherwise, specify the location of the make program in the property setting.

command.go.$(file.patterns.make)=make $(FileNameExt)


SciTE's pretty much set up for working with C/C++ out of the box. I did set some tab and indenting properties specifically for working with programming languages. You can customize the command property options to Compile, Build and Go for working with C/C++, but I find it easier to work with a makefile and build several files at once. See Customizing for details. The Lua switch_headers script is useful too. See Customizing using Lua. You can add a function outline (such as a typical version of main) or a specific comment format (such as a set format for documenting routines) to the file and call them up quickly (using Ctrl-B) as abbreviation shortcuts to cut down on typing time. My context help points to some of my more useful documents and help files for looking up information on the C library, STL and Win32 API. You can use the output pane to display compiler errors and jump directly to the file and line by clicking on the error.

If you like working with a command line or shell (as I do), you can invoke scite to view a file directly from the command line. On Windows, you just have to make sure the SciTE program is in your path and type scite and the file you want to edit. On a Posix machine, I found the case sensitive file names annoying when invoking the editor, so I created a shell script (in my path) called scite and had it call the SciTE binary directly and pass the command line arguments through. If you check the SciTE Help, it mentions other options (besides file names) that you can use on the command line. For instance, -goto: after a file name will go to a specified line number in that file.

Here's an example for an abbreviation for main () that can be added to

main ()=int main (int argc, char *argv[])\n{\n   return (0);\n}

End of Line

If you're converting between Windows, Mac and Posix systems, you may have issues with end of line characters. Some systems use carriage return, some use linefeed and some use a combination of both. If you customize the status bar as described above the $(EOLMode) will let you see what type of characters the file uses at the end of lines. You can convert between systems by bringing up the file in SciTE and choosing the end of line type you want to use from the Options menu, Line End Characters selection. Once that's done, from the Options menu, select Convert Line End Characters and your file will be converted to the format you want. Windows C/C++ compilers are not usually too fussy about the characters at the end of a line. However, if you're trying to port code you've edited on Windows, to a POSIX system (like Linux or FreeBSD) or for use with the Cygwin compiler, you'll need to make sure you use the right type of line endings or your programs may not build.

ABC Notation

I've added context help for ABC. It calls some of the text files describing how to work with ABC. I've also added commands to convert abc to midi, and abc to postscript and to play or view those files.

The build and go commands convert ABC notation to midi and play midi. The Ctrl-4 and Ctrl-5 commands on the Tools menu, convert ABC notation to postscript and display it. I've assumed that tools used for the process have been placed in a scitetools directory beneath the directory SciTE resides in. Adjust the paths as necessary for your system if this is not the case. See my article about music on your PC for links to these tools. You can substitute your Karaoke player of choice in the command.go setting. In the example, I've used a freeware program called Van Basco which is typically located in the standard Windows program files directory. For an Open Source cross-platform Karaoke player, check out Timidity. Also for Linux/BSD, use gs in place of GSWin32c. You can also use programs like gv (on POSIX systems), xpdf or even gsview32 on Windows in place of Ghostscript as your viewer.

The settings assume you want to play the first tune in your ABC file. Edit 1 in the settings below to the appropriate tune number if you need to change this. I typically keep only 1 tune in each of my ABC files, even though the notation allows for several in the same file.*.abc=$(SciteUserHome)/scitetools/abc2midi $(FileNameExt) 1 -o music.kar
command.go.*.abc=c:/progra~1/vanbas~1/vmidi music.kar
command.go.subsystem.*.abc=2*.abc=Convert abc to ps
command.4.*.abc;*=$(SciteUserHome)/scitetools/abcm2ps $(FileNameExt) -e 1 -O*.abc=Print preview ps
command.5.*.abc;*=$(SciteUserHome)/scitetools/GSWin32c -dSAFER -dBATCH*.abc=$(SciteUserHome)/scitetools/less $(SciteUserHome)/scitetools/abchelp.txt*.abc=2

Text to HTML

I often convert stories I write from text to HTML. If it wasn't a fairly easy process in a standard text editor, I would have written a program for it, but you can do it in relatively few steps and have a story converted in under 5 minutes

First step, I save my document file as a file with the html extension (or htm or other relevant extension). Second, I do a Replace from the search menu. I select Transform backslash expressions. I search for /n followed by 5 spaces and replace with:
If I have any section breaks, I'll need to go in by hand and fix those, removing excess paragraph tags (<p>) and replacing the spacing with pre tags (<pre>) and the necessary spacing or section break marks between them. At the bottom of the file, I add the final closing paragraph tag (</p>). At the top of the file, I remove the extra closing paragraph tag. Now I add a generic html header and footer that I just copy from other story pages. The header can include anything and everything from the doctype or html tag to the body or h1 header tag of the html document. The footer can include (among other things) the closing body tag, any optional address tag information and the closing html tag. You can then go in and customize this information, such as the title and h1 tag names for your particular document. If you use the same information over and over, instead of copying from another html document, you can add the information to the file and have SciTE fill it in for you when you select Expand Abbreviation or Insert Abbreviation from the Edit menu. That's it. You now have a html file. You can validate it using the w3c validator online or any other html tools you like.


I have two issues with SciTE that I don't like about the editor. All in all, that's not too bad concerning how much it can do. First, I dislike the search feature. All my other editors bring up the last word I searched or a blank. SciTE brings up the current word. Why would I want to search for a word my cursor is currently sitting on? If anyone runs across a fix for this without having to recompile and rebuild SciTE, please let me know. Second, a nice feature that SciTE appears to be lacking is column blocking/moving/copying. It's a nice ability for an editor, especially if you're trying to draw flow charts or diagram your logic in some way. Actually, I should correct my statement to SciTE has partial support. I recently found out it does have some support for column selection and editing columns. You need to hold down the Alt and Shift keys and use them in conjunction with your mouse or the arrow keys. I found out the hard way, SciTE doesn't treat the arrow keys on the numeric keypad the same as standard arrow keys. Unfortunately, I almost exclusively use the numeric keypad's arrow keys. You can also use another tool to do column editing on a document. I know WordPerfect and Pedit offer this feature. I've heard Cream and Notepad++ may offer it. There might be a way to write a less buggy or more customizable rendition using scripting as well. If anyone does run across a Lua script for this that works well with SciTE, please let me know.

I have a large issue with SciTE on Linux and FreeBSD. I'm unable to get the user.shortcuts settings to work properly. Alt keys work fine if they're part of the original menu, but not if they're in your file. I haven't been able to tie some Scintilla functions (such as delete from current position to end of line) to a shortcut like I can on Windows. For now, I've been changing the key-mapping in the actual code before I compile and build the SciTE editor if I want to use shortcuts that contain alt keys and the shortcuts I want already exist in the SciTE menus. If the functionality I want for my shortcut is not already offered on the SciTE menus, I have been unable to find a work-around. Making sure the shorcuts are in all lower case seems to have helped somewhat with this issue though and may provide just the work-around I've been looking for. I hate not being able to call up a file in the most recently used file list by pressing a number. Why this works differently on Linux and FreeBSD than it does on Windows makes no sense to me. Being able to select a recently used file from the File menu by simply pressing a key is a nice feature for those of us who prefer to use our keyboards over the mouse. Everything else, including lua scripts appears to be working as it should. If anyone has suggestions for fixing any of these problems or any work-arounds, please let me know. Thanks.


I run several mailing lists. If you'd like to share some of your own tips for working with SciTE or discuss using SciTE for programming, with music applications or for writing, feel free to mention it on any of the appropriate mailing lists. The lists are not specifically for SciTE and probably can't answer SciTE related questions, but if you'd like to share what you've learned or discuss it with others who may be using the editor for similar purposes, please do so.

To the main page.

Validate XHTML

The information on these pages is copyrighted by the author with all rights reserved. Reproduction of anything without the author's permission is in violation of copyright laws.
All original material is copyrighted:
(c) Copyright 2008, 2022 by Laura Michaels
All Rights Reserved
Last Update: 20220109