unix 2014-10-29 23-01-24

SciTE Tips

Setup

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, SciTEGlobal.properties, SciTEUser.properties, SciLexer.dll, SciTEDoc.html
I also keep any files with the .properties extension related to the programming languages I work most with, such as cpp.properties for C/C++ programming and css.properties and html.properties for web design. The abbrev.properties 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 others.properties file has settings for makefiles and files created by or for other common programming tools. To customize any of your editor settings, edit the SciTEUser.properties file. You can also customize SciTE.Properties to create properties that only apply in the directory you're working in or the SciTEDirectory.properties 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 SciTEUser.properties 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 http://portableapps.com 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.
Customizing SciTEUser.properties

The main way to customize the editor is by editing the SciTEUser.properties 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 SciTEUser.properties 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.

Setting default width and height of the editor is fairly self explanatory.

# Default width and height in pixels of scite editor screen
position.width=800
position.height=640

There is Unicode support in SciTE. However, when I went to copy a document that had Unicode characters from the clipboard, I found SciTE changing the characters to ?. If you want to be able to paste Unicode characters into a document in SciTE, you'll need to indicate it in your settings. The default is to use single byte characters in a file. The setting below switches to using UTF-8 instead.

code.page=65001

I basically set most of my fonts to Courier 12 point since I like working with a monospaced font. You can set a font to another defined font, such as monospaced, with $(font.monospace). I went ahead and set the base font to a Unicode font so I could make out special characters. You may need to set other font options like font.text to a Unicode font as well if you want better Unicode support. The style.*.32 setting applies font and background color to everything, since style 32 is the default style and is inherited by the other styles. I personally prefer, black lettering on a light grey background. The light grey has been tested to be more readable for most people than white. However, for those who prefer black and white, uncomment the statement with back:#ffffff (which is white) and comment the one with back:#ececec (which is grey). The # at the beginning of the line makes the information a comment.

font.monospace=font:Courier,size:12
font.base=font:Ariel Unicode MS,size:12
font.small=font:Courier,size:10
font.comment=font:Courier,size:12
font.code.comment.box=$(font.comment)
font.code.comment.line=$(font.comment)
font.code.comment.doc=$(font.comment)
font.text=$(font.monospace)
font.text.comment=$(font.monospace)
font.embedded.base=$(font.monospace)
font.embedded.comment=$(font.comment)
#style.*.32=$(font.base),back:#ffffff,fore:#000000
style.*.32=$(font.base),back:#ececec,fore:#000000

I don't have a lot set up for printing, but I do have a few customizations. First, since my background is grey, I need to make sure I don't print the grey background to the paper. It uses to much ink/toner. Setting colour mode to 2 causes SciTE to print black text on a white background. I set the font to use when printing to general purpose Courier and also use it for creating PDF files through the Export feature. I've added the page number to the footer. You can also set up a printer on your operating system that strictly prints to PDF using Open Source software. If you use SciTE's standard print functionality and choose that, it gives you the equivalent of a Print Preview feature. The final PDF document can then be printed from your favorite PDF viewer.

print.colour.mode=2
print.style=$(font.monospace)
print.header.style=font:Courier New,size:9
print.footer.style=font:Courier New,size:9
print.header.format=
print.footer.format= $(CurrentPage)
export.pdf.font=Courier

If you want to have only one instance of SciTE running, add this line. Otherwise, if I want two instances of the program, possibly to place side by side on screen and compare, leave this out.

check.if.already.open

I'm used to hitting the home key to get to the start of the line quickly. Without this command, I'd end up having to hit the home key more than once to get there, since it would first go to start of text.

vc.home.key=0

I like to start from scratch when I open the editor, so I don't use save.session. However, I like to maintain a list of recently used files, so I can reopen them quickly. Use the command below to do that. The information is saved to the SciTE.session file in the directory pointed to by the SciTE_HOME environment variable. The most recently used files will appear on the File menu.

save.recent=1

I've been using lock file scripts integrated through the SciTE Tools menu to make sure that two people don't attempt to edit the same file at the same time. When you check out a file, a script unlocks that file so you can write to it and records who's editing the file. If someone else attempts to check out the file with the script, that person is notified as to which user already has the file checked. When you check in the file, a script locks the file again so someone doesn't accidentally change it. Later versions of SciTE provide an alternative mechanism to avoid collisions with multiple users editing the same files. You can have SciTE check to see if anyone's modified the file since the time you've opened it. SciTE will notify you when you attempt to save an open file if someone else has changed that file while you've been working on it. To enable SciTE's new functionality to check for file modifications, use the following setting:

save.check.modified.time=1

The behavior of SciTE can vary by file type. For instance, you can have a document indent by 5 spaces and a program indent by 3. When I open SciTE, I'm usually going to use it for a quick note or document, so I defaulted the file type to .txt. Any new Untitled documents end up inheriting the properties of a text file. Also, my text mode doesn't have highlighting of keywords which I sometimes find distracting. You can change the default for the document you're viewing through the Language menu if necessary.

default.file.ext=.txt

As I just mentioned, I like paragraphs to indent the standard 5 spaces in a text document. Programmers have different favorite indent settings when they write their programs. My personal preference is 3 spaces. I set my tab and indent sizes to 5 for files with extensions that indicate they're text files. The extensions used by $(file.patterns.text) are already predefined in the others.properties file. I assume any other file extensions are going to represent programs. I prefer tab and indent set to 3 spaces for those. The use.tabs determines whether tabs (and spaces) are used in indenting or whether to use only spaces. I dislike having tabs in my programs as it throws off spacing when I view it in another editor that doesn't have tab sizes set the same. I, therefore, consistently don't use tabs and always have them replaced by spaces. The only exception would be for makefiles where tabs are part of the file syntax and are needed. The tab.indents adds whitespace (index.size number of spaces) in place of the tab character. The backspace.unindents deletes the added space characters as a group instead of one at a time. The tab.timmy.whinge.level is supposed to check if indentation is consistent with previous line. The indent.automatic is used for programming. Programmers have individual preferences as to how they like their braces indented. My preference is for the braces to be under the statement they refer to and the information inside them to be indented by three. The indent.automatic setting influences how braces and the items within them are indented. There are options to specify these settings differently for opening versus closing braces too.

tabsize=3
tab.size.$(file.patterns.text)=5
indent.size=3
indent.size.$(file.patterns.text)=5
use.tabs=0
use.tabs.$(file.patterns.make)=1
tab.indents=1
tab.indents.$(file.patterns.make)=0
backspace.unindents=1
indent.automatic=1
tab.timmy.whinge.level=1

Setting clear.before.execute to 1, clears the output pane before running any outside applications such as a compiler or a spell checker. The split.vertical specifies where to display the output pane. Setting it to 0, places it at the bottom.

clear.before.execute=1
split.vertical=0

You can preset some of the find and replace options. I prefer that find and replace don't wrap around to the beginning of a file once they reach the end. The find.replace.advanced setting shows extra options in the find and replace dialogs. The find.replacewith.focus helps determine where focus is set when the replace dialog opens. I like focus set to the first textarea. The find.close.on.find setting in newer versions of SciTE determines whether the find dialog stays open after a text string is matched. The default is now to automatically close the Find dialog if this is not set to 0.

find.replace.wrap=0
find.replacewith.focus=0
find.replace.advanced=1
find.close.on.find=1

Saw a nice tip on the SciTE-interest mailing list. If you press Ctrl-Alt-i, you bring up an alternative search feature. If you don't like the way SciTE brings up the current word in the search box, this gives you an alternative. The search feature is similar to the Firefox browser's search. You can search again, by clicking the Find Next button. You can also use the tab or shift tab keys to navigate and enter to click a defaulted button. Accelerators are available for faster keyboard navigation too. However, you may not see them underlined unless you change focus such as when you click tab. The find.close.on.find option works for alternative search and replace as well. If you prefer these alternative search and replace features, you can make one or both the default instead of the standard dialog boxes. The new search feature, when turned on, gives even more options than just pressing Ctrl-Alt-i. For now, I prefer the dialog boxes, but one can switch to the new search and replace features by adding the following options:

find.use.strip=1
replace.use.strip=1

Setting the open file dialog to show a decent default directory location when it is called is a nuisance. I usually like it set to my last working directory. If the open file dialog is always set to the same specific directory, it's usually not the one I need at the time. SciTE has an interesting feature that will set the open file dialog to display in the same directory as the file you're currently viewing. I find it convenient when I'm working on a program, because I am usually going to be working in the same area when I do so. Setting open.dialog.in.file.directory to 1 activates this feature.

open.dialog.in.file.directory=1

You can customize the file types shown in the open file dialog. My preference is to be able to see all files. Other options can be added when you want to only see language related files. This is how I set my file types to display:

open.filter=\
$(all.files)\
Source Files (cpp,c,h,mak)|*.cpp;*.c;*.h;*.mak;makefile|\
Web Files (htm, html, css, xml, shtml, js, pl, asp)|*.html;*.htm;*.css;*.shtml;*.js;*.pl;*.xml;*.asp|\
Text (txt, doc)|*.txt;*.doc|

If you're using SciTE on Linux, it's easier to find files using the Open File Dialog if you add the following:

if PLAT_GTK
fileselector.show.hidden=1

The if PLAT_GTK makes sure any following indented code is only executed if you're using the version compiled with GTK on Linux/Unix/FreeBSD rather than the Windows version (PLAT_WIN).

One of the features I prefer in programming editors is to be able to map commands. I didn't switch over to using SciTE as my regular editor until I found out it was capable of doing this. I got used to several shortcuts from a variety of editors I've used over the years. I carried some of those shortcuts over to all my favorite programming editors since they're ingrained and I can execute the commands quite quickly. You can customize your own shortcuts however you prefer.

Some of my favorite shortcut combinations follow. Ctrl-k does a delete from current position to end of line. Notice, there's a number used to specify this command instead of IDM_. I ended up looking for the command in the Scintilla source code and finding the number associated with the option. The IDM_ options are set in the SciTE source code and some of them are mentioned in the SciTE documentation. I set up the output pane to toggle hiding and showing when I press Alt-F3, similar to WordPerfect's toggle control codes command. I use Alt-w and Alt-x often to save a file and close it quickly. I got very used to saving files over the years. You never know when a power surge could erase anything you're working on if your company doesn't give you a UPS device. I'm also used to pressing Alt-n to jump to the next file in a series of files or to cycle through files. Instead of F3, I sometimes use Ctrl-l to do a find next.

# User defined key commands
user.shortcuts=\
Ctrl+Shift+V|IDM_PASTEANDDOWN|\
Ctrl+PageUp|IDM_PREVFILE|\
Ctrl+PageDown|IDM_NEXTFILE|\
alt+n|IDM_NEXTFILE|\
Ctrl+L|IDM_FINDNEXT|\
alt+w|IDM_SAVE|\
alt+x|IDM_CLOSE|\
Ctrl+K|2396|\
alt+F3|IDM_TOGGLEOUTPUT|

Was having all kinds of trouble with the shortcuts using Alt or using numbers in place IDM_ commands on Linux or FreeBSD. For a while I was going into the code and adding the shortcuts I wanted by hand and recompiling SciTE. I did finally get the alt key combinations to work under some circumstances on Linux and FreeBSD. Be sure to set the alt and key combinations to lower case. If anyone has any further suggestions for fixing this please let me know.
I don't use the context menu much. You can bring one up by hitting the right mouse button or with the key combination Ctrl-Shift-F10. I added the toggle to hide and show the output pane just to demonstrate how it's done. You can add your own favorites.

user.context.menu=\
||\
Output alt+F3|IDM_TOGGLEOUTPUT|

You can use Lua scripting to extend the capabilities of SciTE. The ext.lua.startup.script setting tells SciTE the name of a Lua script to run when it starts up. This script appears to run before the language properties files are loaded. So, if you've set command options such as items on the Tools menu in your Lua scripts, these may be overridden by the settings in the language properties files. My startup script basically just runs extman.lua. That sets up my Lua scripts so that they can be run through the Tools menu and allows multiple Lua scripts to be run without colliding when they need the same resources. Add the ext.lua.directory to tell extman.lua where to find your other Lua scripts. I use a generic SciTEStartup.lua file and have that run extman.lua, but if you want to run it directly, you can just substitute extman.lua for SciTEStartup.lua.

ext.lua.startup.script=$(SciteUserHome)/SciTEStartup.lua
ext.lua.directory=$(SciteUserHome)/scitelua

A nice feature of SciTE is that you can customize the status bar. If you're using Windows, you can cycle through different status bar formats by clicking on the bar with the mouse. These are defined with the statusbar.txt options greater than 1. In my case, I've made the statusbar visible and set up three format options. One thing I find annoying is that the text on the status bar shifts if the information changes size, say if a number changes from 0 to 10. Adding another character can shift the postion of all the information following it on the status bar line. There's no option to display the information at a certain location or using a specified number of characters. Instead of following the format of my previous editor, I've tried to arrange the information so that it shifts less often and draws less attention to itself. The first status bar format is good for general information. I like having time and date easily accessible. Line and column numbers are also helpful. The second format gives extra information on the number of lines and characters in the file and about selected or blocked text. The third format gives info on the file you're editing, its date and time of creation and its full path and attributes. I hardly use anything but the first format, but it's nice to have the others for information purposes.

statusbar.visible
statusbar.number=3
statusbar.text.1=\
$(CurrentDate) $(CurrentTime) |$(EOLMode)|$(OverType)|Ln $(LineNumber) of $(NbOfLines)|Col $(ColumnNumber)|
statusbar.text.2=\
$(BufferLength) chars in $(NbOfLines) lines | Selc: $(SelLength) chars in $(SelHeight) lines
statusbar.text.3=\
$(FileDate) $(FileTime) | [ $(FileAttr) ] | $(FilePath)

You can create your own default commands for Help and for items on the Tools menu. You can also do this based on a file extension, so you can create commands relevant to a file type. For instance, you can add C++ compile and build commands for a C++ program. You can view a HTML file in a browser to check it as you're creating it. You can run a spell checker or style program for a text file. You can create a midi file for a song written in abc notation.

If you have any commands that you want to override the commands from language properties files, you'll want to place them here. Sometimes I set commands in Lua files and these can be overriden by defaults in the language properties files. However, placing them in the SciTEUser.properites files will override those defaults. If you're working in C++ and don't want Ctrl-0 to run Indent and Ctrl-1 to run Lint, reset them here.

I've set the help command to call my context help Lua script. Setting command.help.subsystem=3 lets SciTE know this is a Lua script routine, not an outside program or file. Setting command.go.$(file.patterns.web)=$(FilePath) allows web related files to be sent to the default web browser. Basically, the command is sent to the command line with the name of the file and the operating system's command shell determines how to handle a file with that file extension properly. I liked the Borland IDE and Brief feature of being able to bring up a buffer list and choose between files listed in them. Hitting Ctrl-0 on my system emulates that effect in SciTE using a Lua script.

command.help=dohelp ()
command.help.subsystem=3
command.go.$(file.patterns.web)=$(FilePath)
command.name.0.*=Switch &Buffer
command.0.*=do_buffer_list
command.subsystem.0.*=3

If your SciTE Help option from the Help menu isn't working or you want to change the default browser you can do this with command.scite.help. For instance, to change the default to the lynx browser try:

command.scite.help=lynx "file://$(SciteDefaultHome)/SciTEDoc.html"

If you have api files you want SciTE to make use of, you need to specify the files. These are links to two api files available at the SciTE web site.

api.$(file.patterns.cpp)=$(SciteUserHome)/c.api
api.$(file.patterns.perl)=$(SciteUserHome)/perl.api

For more information on api file settings, check out my example of using a custom html.api file.
If you want any custom or language related property files to be used by SciTE other than the defaults listed in SciTEGlobal.properties, you'll need to import them. I placed the statement in my SciTEUser.properties so that I would not need to modify the SciTEGlobal.properties which could change when SciTE is updated. The following command imports the properties for AutoHotKey file editing. There's a link to additional properties files like this one at the SciTE web site.

import ahk

I've set xml.auto.close.tag to 1 which will generate the closing tag for every opening HTML or XML opening tag that needs one. If this is annoying, you can turn it off. You can use the setting autocompleteword.automatic=1 to have SciTE try to guess at autocompleting what you type based on previous words you've typed in the current document.

xml.auto.close.tags=1
#autocompleteword.automatic=1

You can set up comment formats for a language and use the Block, Box or Stream Comment functions from the menu to automatically generate symbols that denote comments for a particular language. Below is an example for HTML comments.

comment.box.start.hypertext=<!--
comment.box.middle.hypertext=
comment.box.end.hypertext= -->

Customizing using Lua

You can find more information on Lua scripts for SciTE at the SciTE Scripts page on http://lua-users.org/wiki/SciteScripts. There are several great scripts to choose from. They can add some wonderful extra functionality to SciTE.

In the SciTEUser.properties 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:
dofile(props["SciteUserHome"].."/extman.lua")

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 ext.lua.directory property. The extman.lua program searches for all the files in the subdirectory indicated by ext.lua.directory. 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:

SciTE_ASCII.lua - Displays an ASCII table
SciTE_Reformat.lua - PFE style paragraph reformatting
switch_buffers.lua - Brings up a list of all my tabbed windows so I can jump between them. (It's a sample script in extman.zip. My custom changes are mentioned on the extman page at the SciTE Scripts site.)
switch_headers.lua - Brings up a .h file for an open .c or .cpp file or vice versa. (It's a sample script in extman.zip. My fixes for Lua 5.1 are mentioned on the extman page at the Scite Scripts site.)
SciTE_runone.lua - Runs one script from a list of scripts. You can add all your favorite scripts in your lua subdirectory to the list. Then you don't need them all in your Tools menu at once to access them.
SciTE_help.lua - A context sensitive help script I wrote.

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.
Text
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 error.select.line 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)/spell.pl "$(FilePath)"
command.build.$(file.patterns.text)=$(SciteUserHome)/hunspell -d $(SciteUserHome)/en_US -u3 "$(FilePath)"
command.build.*.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 SciTEUser.properties file using syntax similar to the following:

command.name.1.*=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 SciTEUser.properties file, invokes Lua and prints the name of the current file in the output pane when a user presses Ctrl-3.

command.name.3.*=File Na&me
command.3.*=trace $(FilePath)
command.subsystem.3.*=3

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).
HTML
Useful HTML Properties

In the SciTEUser.properties file, I have the following settings for working with hypertext and xml files. I've set xml.auto.close.tag 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.

xml.auto.close.tags=1
command.go.$(file.patterns.web)="$(FilePath)"

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
html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> ! hypertext markup tag - declaring start of hypertext
</html>
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 SciTEUser.properties 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:

api.$(file.patterns.web)=$(SciteUserHome)/html.api

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.

autocomplete.hypertext.start.characters=</
calltip.hypertext.parameters.start= ?=
calltip.hypertext.parameters.end=>
calltip.hypertext.parameters.separators= "
calltip.hypertext.end.definition=!

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

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

use.tabs.$(file.patterns.make)=1
tab.indents.$(file.patterns.make)=0

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 SciTEUser.properties, 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)

C/C++

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 SciTEUser.properties 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 abbrev.properties 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 abbrev.properties:

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.

command.build.*.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
command.name.4.*.abc=Convert abc to ps
command.4.*.abc;*=$(SciteUserHome)/scitetools/abcm2ps $(FileNameExt) -e 1 -O music.ps
command.name.5.*.abc=Print preview ps
command.5.*.abc;*=$(SciteUserHome)/scitetools/GSWin32c -dSAFER -dBATCH music.ps
command.help.*.abc=$(SciteUserHome)/scitetools/less $(SciteUserHome)/scitetools/abchelp.txt
command.help.subsystem.*.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:
</p>/n<p>
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 abbrev.properties 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.
Issues

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 SciTEUser.properties 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.

http://www.distasis.com/cpp/scitetip.htm