Welcome to SlickEdit, a text editor for programmers. In this first chapter, I start by telling you something about what makes... more

Welcome to SlickEdit, a text editor for programmers. In this first chapter, I start by telling you something about what makes SlickEdit so good, and why I think it is one of the best programming tools around. In the remainder of the chapter, we cover some of the central concepts of SlickEdit, which we use throughout the rest of the book.

... less

SlickEdit has hundreds of configuration options. It is one of the most configurable software products you will ever find.... more

SlickEdit has hundreds of configuration options. It is one of the most configurable software products you will ever find. As with most configurable software, SlickEdit comes with reasonable defaults. Nevertheless, in this book, we suggest that you should consider some alternatives to the defaults. In some cases, the default settings are designed to make SlickEdit familiar to users with experience with other common programs, such as Visual Studio or Windows Notepad. But Notepad is not the most effective programming editor, and SlickEdit has alternative ways of doing things that can be more powerful. We introduce a few of these in this chapter.

In the first part of this chapter, we cover some general information about configuration to give you the big picture. We discuss SlickEdit’s emulations, which provide behavior compatible with a selection of other editors. We introduce the “WROX Emulation,” which extends SlickEdit’s default emulation to provide more key bindings for useful commands.

In the second part of the chapter, we take a look at several common settings you might consider changing in order to get the most out of SlickEdit. These include obvious things such as fonts and also some subtler points like how SlickEdit treats cursor movement and line wrapping.

Finally, we explain SlickEdit’s configuration directory, and how you can manage SlickEdit configuration data.

... less

When I started using the ancient ancestor of SlickEdit, the E editor on DOS in the 1980s, screens had only 25 lines and 80... more

When I started using the ancient ancestor of SlickEdit, the E editor on DOS in the 1980s, screens had only 25 lines and 80 columns. The editor had a command line, a status line, and a help line. I could see 22 lines of my file, and those lines were not particularly long. Figure 3-1 shows this old editor.

These days we have GUI environments and much bigger screens. Many programmers now use a monitor at a resolution of 1600 ´ 1200 or more. With that kind of screen, in full screen mode it’s easy to get 60 or 70 lines on the screen, with a couple of hundred columns. (And, if you don’t mind a 6-point font, you can get a lot more.) This is usually enough space, because most people’s brains can’t cope with more lines of code than that anyway.

The thing is, our desktops and tools are a lot more sophisticated now, and they want to give us a lot more information, and give us more different ways of doing things. Some Office-style applications start up with three or four rows of toolbars. IDEs usually have extra windows on the sides and bottom, for different types of navigation. SlickEdit also has a lot of toolbars and tool windows. If you use them all, you can easily get back to a situation where you can see only 20 lines or less of your code.

The trick is to manage the toolbars, tool windows, and your editing area to maximize your productivity. SlickEdit allows several options for how you arrange its tools. In this chapter, we take a look at those options and recommend some strategies for using the features most effectively.

... less

With most programming IDEs, you organize your work into projects. In some IDEs, you cannot open a file unless it is part... more

With most programming IDEs, you organize your work into projects. In some IDEs, you cannot open a file unless it is part of your project. With SlickEdit, it’s easy to open any file on your system, but all the same it’s usually best to organize your work to get the most effective use of the editor’s features.

SlickEdit organizes your work using two concepts: workspaces and projects. Workspaces and projects are important for two main reasons:

• They allow you to organize, manage, and tag the files in your project.

• They provide structure around tasks such as building, running, and debugging your project.

Tagging refers to SlickEdit’s ability to index the symbols in your code for navigation and smart assistance features. We go into SlickEdit’s tagging features in more detail in Chapter 5.

To organize your work using SlickEdit’s workspaces and projects, you create a workspace. In the workspace you add one or more projects. SlickEdit stores the workspace details in a .vpw file, and the project details in one or more .vpj files. SlickEdit also creates a tag file (.vtg) to tag your project files and a .vpwhist file that contains state information about your workspace.

A workspace contains a set of projects and retains the state of an editing session. Opening a workspace returns you to the same state you were in when you last worked on this workspace, including the set of open files. Files are added to projects, and projects are added to workspaces, thus you cannot directly add a file to a workspace. You can open files that do not belong to any of the workspace’s projects, and they will be available for editing in the next session if not closed.

A project can be just a set of files, but if you are using the SlickEdit build system, then a project corresponds to a build target, something that gets built. For Java, it’s common to have a single project. For C/C++, you would have a project for each library, DLL or SO, that is built and one for each executable. Even if you don’t use the SlickEdit build system, partitioning files into projects like this is useful so that you can see the structure of your projects and do things like restricting searches to the current project.

Projects can be shared between workspaces. Once a project is defined, you can add it to a different workspace. The exact same project is shared; it is not a copy. This is useful if you have internal libraries that might be used and edited in multiple programs.

SlickEdit does not require that the files in a workspace be under the workspace directory. They can be located anywhere on the local machine or on a network, although local is always best. Some prefer that structure, creating a single root directory that contains subdirectories for each project, which contains a source tree. However, you can create a workspace directory that has no subdirectory and stores projects and files in other directories. Even if your source files are remote, it is very important to have your workspace and project files stored locally.

SlickEdit tags all of the files in a workspace (i.e., all of the files in the projects that the workspace contains) and creates the workspace tag file. It does not have project-specific tag files. For code that is used but not edited, it is generally best not to add it to the project. Instead, tag the library, and add the tag file to your environment. Because of the way in which Context Tagging works, it’s best to restrict your files to those that will be edited.

When you create a project, it is critical to get the project type correct. It is impossible to change some project types into others. For example, if you create a Generic C/C++ project, you will never be able to configure it through the GUI to work properly with GNU C/C++. You need to start with that project type to be successful.

Projects can be dependent on one another, creating a build dependency. If you have multiple projects, certain operations work on the Active Project. It is shown in bold in the Project tool window. You can change the Active Project by right-clicking on it or using Project→Set Active Project.

SlickEdit cannot create Microsoft Visual Studio project types. It can open them and change the set of defined files, but you have to create the solution or project in Visual Studio before opening it in SlickEdit. You will also have to make most of the changes related to build settings in Visual Studio.

In this chapter, you will see how to create workspaces and projects. We’ll take a look at how to set up projects for different build targets in your work, and how to automate building and testing your project in SlickEdit. We’ll look at several examples using programming languages with compilers—C/C++ and Java—and also an example of using SlickEdit projects with an interpreted language, Ruby. You can find the code for the sample projects on the accompanying CD-ROM.

For compiled languages such as C++ and Java, SlickEdit provides dialogs with a large number of compiler and linker options. Most of the options you can use with the command-line tools are available through the SlickEdit GUI. However, we don’t cover the compiler options in detail here, or even all the compilers. You can find better information about using a compiler in that compiler’s own documentation. Instead, we focus on using SlickEdit with programming language compilers and interpreters in general, and how to create an effective and productive development workflow using SlickEdit.

... less

A lot of SlickEdit’s power comes from a feature called Context Tagging. Many of SlickEdit’s advanced navigation, editing,... more

A lot of SlickEdit’s power comes from a feature called Context Tagging. Many of SlickEdit’s advanced navigation, editing, and browsing features depend on Context Tagging:

• Navigating to definitions and references.

• Automatic completions of functions, members, and parameters.

• Browsing definitions and references.

Context Tagging creates databases of symbols in your projects and libraries, and uses those databases to provide symbol-based navigation, editing, and browsing. The process of creating a tag database for a set of source files or a library is called tagging. When tagging a set of files, SlickEdit scans the files for symbols and updates the tag database with the symbol information. This information includes various properties about the symbol:

• The symbol’s category (class, structure, function, variable, etc.).

• The name of the symbol (owning class, short name, qualified name, etc.).

• The location of the symbol (file, line and column numbers, offsets, etc.).

• Associated data for the symbol (return type, arguments, exceptions, etc.).

SlickEdit uses the symbol information to provide a range of useful features.

In this chapter we describe how to ensure that your project is tagged correctly. We cover some of the features that Context Tagging provides. We also go into some detail about how to manage tag databases effectively and some issues that arise with tagging.

... less

Large software projects contain thousands of source files. Often those source files are spread over dozens or even hundreds... more

Large software projects contain thousands of source files. Often those source files are spread over dozens or even hundreds of directories. And those files can contain thousands of lines. You need to be able to open the file you want as quickly as possible. Once you are in the file, you need to be able to navigate quickly to any place in that file. You need to be able to jump from one place to another, then back, perhaps several times.

In Chapter 5, we saw how Context Tagging enables several powerful navigation features, along with other things. In particular, push-tag and push-ref are the preferred way to navigate a large base of source code in SlickEdit.

There are also other ways of opening files in SlickEdit. Depending on the nature of your project and the way you prefer to work, some methods will suit you better than others. Some methods are obvious, such as File→Open. Others are not so obvious but can be far more effective.

SlickEdit allows you to open many different files at once. When you have only one or two files open, you can switch between them easily. If you have a dozen or more files open, SlickEdit offers several nice ways to get quickly to the one you want.

Most editors support a standard set of navigation commands for getting around inside a file. You have the arrow keys for moving a character or line at a time. You have keystrokes for moving a word or a page at a time. SlickEdit has a rich set of commands for navigating around the buffer. It’s well worth becoming familiar with these commands, because they can save you a lot of time and keystrokes.

If you find yourself returning to the same location in a file frequently, a bookmark can save a lot of time. Bookmarks also let you return quickly to where you were editing after jumping to a definition or a reference.

... less

A particularly important tool for navigation is searching. SlickEdit has a rich set of searching features. These range from... more

A particularly important tool for navigation is searching. SlickEdit has a rich set of searching features. These range from a simple search for a string, up through sophisticated searches using regular expressions and context-sensitive criteria. You can use selective display to filter which lines of the buffer are displayed on the screen, based on search conditions. You can selectively hide sections such as comments or arbitrary code blocks. You can also search across many files.

Along with searching, SlickEdit also supports replacing, with virtually the same set of features. Regular expression replacements are a particularly powerful way to edit files.

... less

While I’ve spent a lot of time writing code throughout my programming career, it seems that I spend just as much time in... more

While I’ve spent a lot of time writing code throughout my programming career, it seems that I spend just as much time in the editor working with other kinds of files. Some examples are

• Scripts or sets of commands.

• Test data (and sometimes production data too!).

• Log files.

• Configuration files.

• Stack traces.

• Dumps.

• Notes.

Sometimes I am merely searching and browsing. Sometimes I am moving things around and deleting unwanted data to analyze the content of a file. Other times I am actively editing, adding new data.

SlickEdit’s speed and advanced features make it ideal for all of these tasks. Many of SlickEdit’s features are generic to the job of editing text and are not specific to programming, much less to a particular programming language.

This chapter covers some of SlickEdit’s general-purpose text editing features. The topics are important in any task you are doing with SlickEdit. They include

• Using basic editing.

• Using selections and clipboards to move, copy, and manipulate text.

• Using word completion to save typing.

Chapter 9 follows this with detailed information specific to editing code. Chapter 10 focuses on data-oriented editing.

... less

Editing code is SlickEdit’s primary function. Many features of the editor apply to text editing in general. Some of them... more

Editing code is SlickEdit’s primary function. Many features of the editor apply to text editing in general. Some of them apply to editing data. But the most specialized features deal with specific tasks encountered while editing code. In Chapter 5, we cover Context Tagging, which is an important set of features that provide assistance when editing code. In this chapter, we cover a variety of additional features for editing code.

The most basic and obvious code-specific feature is color syntax highlighting. SlickEdit has color syntax highlighting for numerous programming languages, and you can easily add support for a new language. SlickEdit also supports a range of other options per programming language, such as indentation preferences and comment formatting. SlickEdit provides syntax assistance for common constructs in various languages. For example, SlickEdit expands control structures automatically.

When you type in starting elements in code, SlickEdit often adds the ending elements automatically. This happens with braces and multiline comments, for example. One reason for this is to save you time. Another reason is that it helps keep the file structure valid, and that is very useful because when SlickEdit can parse the file structure correctly, it can provide the best contextual assistance.

... less

Programmers frequently have to deal with data. Much of your programming job may be concerned with manipulating data, whether... more

Programmers frequently have to deal with data. Much of your programming job may be concerned with manipulating data, whether the data are in a corporate database, read from an instrument, or generated to describe a 3D world in a game.

Of course, if a certain task is within the scope of the main project you’re working on, you will write code for the task in your main programming language—it will be a feature of the application you’re building.

Often, though, you find you need to do something quick and ad hoc with some data. Someone sends you a spreadsheet with some test data that need to be entered in the database. You might need to sort a log file and count the number of error messages in it. You might want to take a directory listing and generate a one-off script from it. These are just some of many different scenarios that seem to arise daily in many programming or IT jobs.

Different programmers have different preferences for dealing with these situations. UNIX gurus are usually proficient with tools such as sed and awk, not to mention more powerful scripting languages, such as Perl, Python, or Ruby, all of which are well suited for quick data hacks. Windows programmers might prefer a more interactive environment such as Microsoft Excel for manipulating data that are in rows and columns.

SlickEdit provides several features that help out with ad hoc or one-off data manipulation. Using SlickEdit for one-off data jobs can provide an appealing mix of interactivity and scripted automation.

This chapter describes some of SlickEdit’s features that are useful for data, and also covers some techniques you can use to make ad hoc data manipulation as quick and easy as possible. We start by discussing more of what you can do with block selections, which are one of SlickEdit’s most fundamental tools for working with data. Next, we cover several tools that SlickEdit provides for working with data, for filling in data, sorting data, generating data, and calculating with data. Finally, we present three techniques in detail that can be used for working with data generally.

This chapter presents some further Slick-C code as examples. It also relies on the code in wrox_next_prev_word.e from Chapter 6.

... less

Programming often involves creating certain constructs repetitively, but with variations. For example, the classic C++... more

Programming often involves creating certain constructs repetitively, but with variations. For example, the classic C++ for() loop looks like this:

for (int i = 0; i < size; i++) {

  // do something

}

Aside from the loop counter and the bound, and, of course, the body, a lot of the loop construct is boilerplate. Built-in syntax assistance in a programming tool such as SlickEdit can go a long way to reduce the amount of typing you have to do for these constructs, but there are always other constructs that you use that the tool doesn’t know about. There are many examples of repetitive chunks of text other than programming constructs. In some cases, whole files follow a particular pattern, at least to begin with.

Aliases and file templates are a couple of SlickEdit features that assist with repetitive text. The alias feature expands short abbreviations into larger chunks of text, and can be used for a wide variety of purposes. File templates allow you to define standard boilerplates for often-used file structures, in one or more files, and create new items based on them at any time.

In this chapter, we look at the alias and template features, and see various applications of them.

... less

When you open a file in SlickEdit, the editor determines several things about it. We’ve already seen the importance of the... more

When you open a file in SlickEdit, the editor determines several things about it. We’ve already seen the importance of the extension in determining the document mode. (The mode is basically the programming language family; see Chapter 9.) Most programming language source files are simple ASCII files (or nearly enough), and that is all that matters. SlickEdit can also edit files of other types. Sometimes there is more involved in determining how to read them or display them.

SlickEdit can open binary files. For binary files, it’s usually more useful to view them in hex mode as bytes rather than as text characters. Sometimes hex mode is useful for text files too.

SlickEdit supports XML files as well. XML files are Unicode rather than ASCII and can be represented on disk in a variety of encodings. Unicode is a massive character set (~100,000 characters). This introduces some challenges, because most fonts are not capable of displaying the entire set.

When dealing with XML documents, SlickEdit’s default behavior is to try to provide as much assistance as it can by downloading referenced DTDs and schemas from the Internet. I use a laptop for almost all my work, and because I’m on the road a lot, not always connected to the Internet, sometimes I don’t want this behavior. Sometimes I need to prevent SlickEdit from fetching documents from the Internet. An even better option is to store local copies of required resources and get SlickEdit to use them instead.

In this chapter, we cover a variety of topics concerning types of files and ways to view and edit them.

... less

For some reason or another, we programmers always seem to end up with multiple, slightly different versions of the same file... more

For some reason or another, we programmers always seem to end up with multiple, slightly different versions of the same file. Or worse—multiple, slightly different versions of the same source tree. Now, one thing I’ve noticed in my career is that this has been happening a lot less since I started using version control. Proper use of version control reduces the need for archived or backup copies of source code, or copies of the same source tree all over your disk.

Note

We look at version control in more detail in the next chapter.

Of course, it still happens. (Usually when it happens to me, it means I haven’t been using version control properly!) This must be a fairly common occurrence for programmers, and perhaps other computer users too, because there are several commercial tools on the market whose sole function is to compare directories and files and resolve the differences. Happily, if you already own SlickEdit, you probably don’t need one of those tools, because SlickEdit has great file and directory comparison and merging built right in. You can even run SlickEdit’s comparison tools outside the editor, as a full replacement for standalone tools for the same purpose.

In this chapter, we’ll take a look at comparing and merging files and directories. We’ll also take a look at some basic versioning capabilities built into SlickEdit.

... less

Version control should be a key part of any programmer’s workflow. (Every file involved in the writing of this book was checked... more

Version control should be a key part of any programmer’s workflow. (Every file involved in the writing of this book was checked into and versioned in a Subversion repository.) Whether you work in a large distributed team, or are coding alone on a personal project, version control tools are very useful in helping you manage changes and versions of your code base.

Most programmers have been through a phase of using what I call “ZIP file archive version control,” which is pretty much what its name implies. If you’re using ZIP files or other ad hoc copies of your source code for version control, you are probably spending a lot of time using the diff tool and scratching your head. You may also have some trouble explaining why you cannot reproduce the behavior found in released versions of your product, because you cannot reliably reproduce those versions! Do yourself (and your customers) a favor, and start using version control.

SlickEdit provides support for several version control systems. In this chapter, we look at the two main popular open source version control systems: CVS and Subversion. As usual, we won’t be studying these version control systems in minute detail. You should refer to the appropriate documentation for each version control system for more detail. The main point of this chapter is to show how SlickEdit uses Slick-C and macro commands to interact with version control. You can use macros within the SlickEdit environment to add your own preferred key bindings and value-added commands. We show a set of possible key bindings for working with each of CVS and Subversion, and some sample macros that make these version control systems quicker and easier to use with SlickEdit. This should give you a start for building on your own requirements.

... less

As we’ve seen, SlickEdit’s DIFFzilla program is a useful program that is integrated in the editor but can also be used standalone... more

As we’ve seen, SlickEdit’s DIFFzilla program is a useful program that is integrated in the editor but can also be used standalone, for comparing files or directories. SlickEdit includes several other tools that you can also use within the editor, but may find useful in their own right.

SlickEdit’s remote ancestor was an IBM internal-use DOS editor in the 1980s. Along with the DOS editor, IBM also developed various PC productivity applications. One of the most popular of these was a file manager called FileMan. Other similar products existed in the DOS days outside IBM, such as XTree Gold.

One idea that reoccurred a few times in text-mode computing was combining the text editor with the file manager, often by implementing the file manager in the text editor. This happened on the IBM VM/CMS mainframe operating system, for example, with the XEDIT text editor and FILELIST file manager.

SlickEdit contains a text-based file manager implemented in Slick-C. You can use the file manager to browse and manage your files and directories and, of course, to open files. You can also use Slick-C in conjunction with the file manager to automate tasks involving both the files and the editor.

The file manager is intended for use on file systems visible on your machine, that is, local file systems or network attached ones. Using the FTP tool window, you can also open and edit files on remote hosts via the FTP or SFTP/SSH protocols.

Finally, SlickEdit’s Regex Evaluator tool window can be used to test regular expressions in any of SlickEdit’s supported regex styles.

In this chapter, we take a brief look at each of these tools.

... less

Slick-C is the main tool you use to customize and extend SlickEdit. We have already seen a lot of Slick-C code in this book... more

Slick-C is the main tool you use to customize and extend SlickEdit. We have already seen a lot of Slick-C code in this book. Most of SlickEdit’s features are implemented in Slick-C. Slick-C source code is provided with SlickEdit, and you can use it as the basis for your own features. In this chapter, we take a look at various aspects of the Slick-C language in more detail.

This chapter is not a complete reference for Slick-C. As well as reading this chapter, you should refer to the online Help for detailed reference information about Slick-C programming. The “Slick-C Macro Programming Guide” part of the online Help is also provided in PDF format in the SlickEdit installation. The installation includes another document—“Slick-C Macro Conventions and Best Practices for End Users”—which is also very useful. Finally, the SlickEdit Community Forums at http://community.slickedit.com have a section specifically for Slick-C macro programming.

For really learning Slick-C and SlickEdit customization, nothing beats studying the supplied macro source code. If you are after extreme SlickEdit customization, you will want to become familiar with the supplied source code. If you want to understand how a feature works, or perhaps you think there’s a bug in some feature, you can often find out by studying the source code for that feature. And, when you are trying to write some new function for your own needs, often the best way to see how to do things is to look for source code for features that do something similar.

In this chapter, we illustrate the usage of Slick-C for typical tasks. We provide code snippets to show how to work with Slick-C features and useful library functions. To complete the chapter, we provide several examples of full-length macros for automating tasks within SlickEdit.

For code snippets, I’ve adopted a convention of using assertions to illustrate the behavior of Slick-C features and functions. As of version 12.0.2, SlickEdit provides an assertion facility via the built-in _assert() function.

An assertion tests a condition and generates an informative stack trace if the condition fails. Assertions are useful in several aspects of programming, both in test code and live code. In this chapter, we will use the facility as a concise and informative way of presenting how Slick-C features work. For example:

int i1 = 0x80000000;

int i2 = - i1;

_assert(i1 < 0);

_assert(i2 < 0); // anomaly of signed 32 bit integers!

For examples in this chapter, we’ll use a few more functions to extend the basic _assert() for a few common cases:

void wrox_assert_false(boolean condition, _str msg = null) {

  _assert(!condition, msg);

}

void wrox_assert_equals_message(typeless expected, typeless actual, _str msg) {

  if (expected._varformat() == VF_LSTR && actual._varformat() == VF_LSTR) {

    _assert(expected :== actual, msg); // exact match for strings

  }

  else {

    _assert(expected == actual, msg);

  }

}

void wrox_assert_equals(typeless expected, typeless actual) {

  wrox_assert_equals_message(expected, actual, 

    "expected=["expected"], actual=["actual"]");

}

The code snippets demonstrating Slick-C features this way are all contained in files with names beginning with wrox_try_ in the Author/Chapter16/ directory of the CD-ROM.

... less

Throughout this book, a major theme has been to show you many ways in which you can customize and extend SlickEdit for your... more

Throughout this book, a major theme has been to show you many ways in which you can customize and extend SlickEdit for your own needs and preferences. In the previous chapter, we went into detail about Slick-C, which is the main power tool for customization in SlickEdit. In this chapter, we continue the theme of customization.

We’ll look at how you can fine-tune the behavior of common keyboard commands by creating your own wrapper versions for them. This is easy to do and provides an effective way in many cases of getting the editor to behave just the way you want it to.

SlickEdit supports a large number of programming languages out of the box, but new languages seem to appear just about every day. There are programming languages not supported by SlickEdit, from the ancient and obscure to some of the latest cutting-edge open-source languages. We’ll see how you can get a certain amount of support for these languages nevertheless, using SlickEdit’s features for defining new modes and lexers.

In the previous chapter, we looked at several ways to use Slick-C to automate tasks in the editor and to create new features of your own. You may be surprised to learn that the capabilities of Slick-C are not limited to traditional programming, but also cover GUI programming. You can customize most of SlickEdit’s user interface, that is, forms and menus, using GUI tools provided in the editor. You can also create your own GUI elements for use with SlickEdit using these tools, or directly in code. We’ll take a look at a couple of relatively simple but useful examples of editing forms and working with menus.

Finally, to be a truly expert user of SlickEdit, you need to be able to take control of your configuration. That means controlling it in code, so that your configuration settings are intentional and repeatable. All SlickEdit configuration settings can be accessed and controlled from Slick-C. We’ll cover several examples and show how you can determine the Slick-C code required for specific configuration changes you want to make.

... less

This appendix contains several tables listing commands, key definitions, and other settings for several different emulations... more

This appendix contains several tables listing commands, key definitions, and other settings for several different emulations. The tables are

• Command Keys by Category.

• Key Commands.

• Macro Variable Settings.

The emulations included are

• CUA, or “Windows.”

• SlickEdit.

• Visual C++ 6.0.

• Visual Studio.

The tables listed here were generated using a Slick-C macro command—wrox-make-emulations. The code for this macro is included on the CD-ROM, under Author/Chapter16/wrox_make_emulations.e. You can use the macro to generate plain text or HTML tables of selected emulations.

The tables printed in this book are for SlickEdit version 12.0.2. SlickEdit emulations change in minor ways from release to release.

... less

Table B-1 shows the complete syntax for regular expression features in the three variants supported by SlickEdit. Chapter... more

Table B-1 shows the complete syntax for regular expression features in the three variants supported by SlickEdit. Chapter 7 contains a shorter version of this table. Chapter 7 also contains explanations for some of the items in this table.

... less

Table C-1 lists the complete set of SlickEdit callbacks at the time of writing. Callbacks are covered in detail in Chapter... more

Table C-1 lists the complete set of SlickEdit callbacks at the time of writing. Callbacks are covered in detail in Chapter 16. The list of callbacks here was generated using the macro presented in that chapter. You can use the macro to get an up-to-date list, or adapt it for your own needs.

... less