This section contains general information about the editor and the thoughts that went into building it. If you are new to the X2 Editor you may want to skip ahead to the Tutorial before reading this chapter.
The X2 Editor was designed and built to enhance the process of producing source code. As a programmer's editor the most important considerations were performance and ease of use. Wherever possible, the editor has been written so that it will automatically do things when writing code. In order to do this, it must make certain assumptions about the format of the file being edited. Some of these assumptions can be tailored through the user profile, but others are imbedded in the editor. This may cut down on the flexibility of the interface, and some people may not agree with the shortcuts which the editor makes for the user. It is felt that this tradeoff is worthwhile for the productivity benefits that can be realised through such a design.
While the OS/2 Presentation Manager (PM) environment provides a useful graphical interface for most computer users, it does tend to use a large amount of the available computer cycles for doing nothing more than painting the screen. The author feels that productivity can be gained for serious programmers by utilising the full screen features of OS/2 and foregoing the nice windows and fonts available on the desktop. It is for the performance benefits that can be realised in such an environment that the X2 Editor was built. If you are not an editor "power user" or you like a full graphical environment, this editor is not your best choice.
The editor does not support interaction through a mouse interface, for several reasons:
The X2 Editor is an ASCII text editor suitable for editing any flat text file. There are versions available for the OS/2, DOS, 32 bit Windows, AIX 4.1, AIX 4.2, AIX 4.3, Linux, and Solaris operating systems.
The OS/2 and Windows versions are 32 bit VIO (full screen) applications, which can be used either from a full screen session or from a VIO window. The Unix versions are X-Windows applications, although a fullscreen CURSES version is also available for Linux. In features the X2 Editor is most similar to the EOS2 editor, although it has some important differences from that editor, including:
For information on configuring the X2 Editor to behave similarly to the default EOS2 editor, consult Sample Profile for EOS2 Users.
This document describes the OS/2 version of the editor, except where noted. Details of the differences between the three versions may be found in Editor Differences Between Operating Systems.
The cursor movement keys in the X2 Editor are defined to move the cursor where you are likely to want it to go, depending on the file contents. For example:
By default, the Enter key moves the cursor to the first non-blank character on the next file line. If the next line is blank, the cursor is positioned beneath the first non-blank of the current line. If the cursor is on the last visible line of the file, it will not be moved.
To insert a new line, press the Ctrl-Enter key. This will leave the current line unchanged, and a new line will be added beneath the current line. The cursor will be positioned on this new line, beneath the first non-blank character on the old current line. The contents of the new file line may vary. If the cursor starts on a line that looks like a block comment, then a new, empty block comment line will be inserted. Otherwise, the new line will be completely blank.
The X2 Editor reserves the last line of the screen for the display of function key help. This information will dynamically change depending on user interactions - if the user presses and holds the Shift key, for example, the text will change to display the settings of the various shifted function keys. There are four possible lines that can be displayed, for Shifted, Alt, Ctrl, and unshifted states. These lines can be changed in the user profile.
Another feature of the PF display line is that it is used to indicate the CapsLock state of the keyboard. If CapsLock is ON, the PF line will contain only upper case letters. If CapsLock is OFF, the PF line reverts to the normal mixed case representation.
When the cursor is active in the file area, no command line is visible. When the cursor is moved to the command line with the Esc or Alt-Enter keys, the command line is written over the topmost visible file line on the screen. If commands have been issued previously, these are also displayed under the command line. These lines represent the command stack, which contains a maximum of 20 previous commands. They are saved in chronological order, the most recent command at the top of the stack. The default size of the command stack window is 10 lines, but all 20 commands can be scrolled with the cursor movement keys. As the commands are scrolled, the current (highlighted) command is copied to the command line. The command stack window size may be modified through the user profile. See Command Stack Window Size for details.
As a command is typed on the command line, the first few characters are compared against previous command stack entries. If a (case-insensitive) match is found, the current stack entry will be highlighted. This provides a convenient way to recall previous commands with only a few keystrokes.
The command stack is saved from session to session. It is saved on the X2PATH (see Installation) as XCMDSTCK.DTA. Note that if the X2PATH is undefined, the path to X.EXE will be used as the location for XCMDSTCK.DTA.
When entering commands on the command line, multiple commands may be issued by separating them with the Linend character. This character is defined as the caret (^). If the linend character is found on an input line, everything up to that character will be issued as a command, and subsequent text will be issued as another command when the first command has completed. The linend character may be turned on and off with the LINEND command, or modified through the profile (see Customising LINEND Character).
The X2 Editor is supported on various platforms: OS/2, 32 Bit Windows, DOS, Linux, Linux390, AIX 4.1, AIX 4.2, AIX 4.3, Sun Solaris SunOS 5.6, and HP-UX 10.2. The executables are delivered as X2.ZIP, XWNT.ZIP, XDOS.ZIP, xlinux.tgz, xlin390.tgz, xaix41.tgz, xaix42.tgz, xaix43.tgz, xsun_tar.Z, and xhp.tgz respectively; you have to unpack the files yourself. The files are available from the World Wide Web (WWW) at the public site http://www.tangbu.com.
Useful macros are available in the xmacros.zip file on the download WWW page. Each macro has the file extension .X. Macros may be installed by copying selected files to a directory in your PATH. Macros must have file extension .X or the editor will not find them. Commands and Macro Support discusses how to write your own editor macros. Macro support is not available for the DOS version.
To use the X2 Editor on OS/2 follow these steps:
The same executables can be used on any 32 Bit Windows operating system. X2 has been tested on Windows 95, Windows NT, Windows 2000, and Windows XP. To use the X2 Editor on these systems follow these steps:
If you want to run Rexx macros with the Windows NT version, you'll have to install Object Rexx, which is available from http://www2.hursley.ibm.com/orexx/orexx.htm. Alternatively, you may install the Regina Rexx interpreter, which is freely available from ftp://ftp.lightlink.com/pub/hessling/Regina/.
To install the editor for DOS:
To install the editor for Linux:
The above installation may be simplified by use of the x2install utility that comes packaged with the rest of the files. If you decide to use x2install, make sure you read the code before running it so you understand what it will do.
The Linux version supports two versions of Rexx - Object Rexx and Regina. Rexx for Linux is available from http://service2.boulder.ibm.com/dl/rexx/orexxlinux-d or http://www2.hursley.ibm.com/orexx/orexx.htm. Alternatively, you may install the Regina Rexx interpreter, which is freely available from ftp://ftp.lightlink.com/pub/hessling/Regina/.
To install the editor for Linux390:
Note that the following instructions use the generic name xaix.tgz as a placeholder for xaix41.tgz, xaix42.tgz, or xaix43.tgz. Please substitute the correct name depending on whether you are running AIX 4.1, AIX 4.2, or AIX 4.3 and above. To install the editor for AIX:
To install the editor for Solaris SunOS 5.6:
To install the editor for HP-UX:
From the operating system command line, the editor is invoked with the following syntax:
<d:\path\>X <fn1 fn2... <-B> <-BIN> <-BINONLY> <-Ccmd>> <-ERR> <-NOPROF> <-NOTABS> <-NOUNDO> <-Pprofname> <-Q> <-S> <-T> <-TABS> <-TEn> <-TEXTONLY> <-TOP>
When editing a file with the internal EDIT and X2 commands, the same options may be used, with the following differences and exceptions:
Files are loaded either as parameters to X.EXE, or as parameters on the EDIT command. Several shortcut keys are available when specifying file names:
The following table contains examples of file name resolution. The
currently edited file is C:\MYDIR\MYFILE.TST.
An environment variable named X2PATH is set to
A great deal of effort was invested in making file load times as fast as possible in the X2 Editor. Editor Performance Comparison - File Load and Editor Performance Comparison - File Load & Quit show the results of performance comparisons between the X, EOS2, and T2 editors. Editor Performance Comparison - File Load shows the time required to load the editor and a file, while Editor Performance Comparison - File Load & Quit shows the time required to load the editor and a file, and to quit back to a fullscreen prompt. The first results were obtained with a stopwatch, while the second results were obtained with the program in Rexx Program to Measure Editor Load Times. The second set of results are more reliable.
These tables show the results of the tuning efforts combined with the performance benefits of 32 bit compilation. While X2 is comparable in speed against T2 and EOS2 (both 16 bit editors) for small files, it is much faster when loading larger files.
The table compares file load times for 3 editors against 3 files: T1 was
1000 lines of 10 characters each, T2 was 10000 lines of 10 characters each,
and T3 was 100000 lines of 10 characters each. Times are in seconds as
measured by a stopwatch, starting from an OS/2 fullscreen command line. The
load time measures the time taken from hitting Enter to seeing the file data
on the screen. The test machine was a PS/2 Model 77 running a 486SX chip at
33MHz. Times are the average of 3 trials for each editor on each file.
The table compares times to load a file and then quit for 3 editors
against 3 files: T1 was 1000 lines of 10 characters each, T2 was 10000 lines
of 10 characters each, and T3 was 100000 lines of 10 characters each. Times
are in seconds as measured by a Rexx program (see
starting from an OS/2 fullscreen command line. The test machine was a PS/2
Model 77 running a 486SX chip at 33MHz. Times are the average of 3 trials
for each editor on each file.
X2 provides several windows to help navigate between files and inside a single file. Each of these windows is displayed on the screen in response to user keys. When a popup window is active, several default keys have slightly different functionality:
All other keys will remove the window, and then perform their normal function. Note that the functions defined to these default keys may be moved to other keys, in which case the new key will have the stated function. While the popup window is active, the PF line will change to provide information about the action of the Enter, Ctrl-Enter, and Alt-Enter keys.
Navigation between files when there are many files in the edit ring is sometimes difficult. A Ring Window can be displayed by pressing Ctrl-F12 on the default keyboard layout. This key will display a popup window containing a list of the names of the files in the ring, sorted alphabetically, with the current file selected. Any files which have been modified are displayed with the filename highlighted in the window_emphasis colour. The width defaults to 40 characters, but will dynamically re-size itself to display as much of the longest file name as possible.
Code Functions List describes how to set up the user profile so that the X2 Editor can recognise functions in various programming languages. This information is used by the FUNCWIN command to display a window containing all the functions that are defined within the current file. Selecting a line and pressing Enter will move the cursor to the beginning of the specified function definition.
Sample Macro to Create a Popup Window contains a sample macro which uses the WINDOW and WINLINE commands to create and respond to a popup window.
X2 defines four margins for text formatting purposes. These are:
When entering text into a document it is useful for the text of a line to automatically split when it reaches a certain length. This allows you to continue typing and still see the entire text that you have entered. Every time you enter a character, the length of the current line is checked against the right auto-flow margin. If the line is too long, the line will be split at the first blank to the left of this margin. If the cursor is positioned at the end of the line it will be moved to the end of the newly inserted line; otherwise, it remains in the same location on the screen.
The text that is split from the end of the current line will be placed on a new line if one of the following conditions is met:
In all other cases, the split text is inserted into the beginning of the following line. An attempt is made to align the new text with the current line. The same indentation will be used unless the current line looks like a list, in which case the new line will be padded to align with the text following the dash on the current line.
The file margins may be queried or changed with the MARGINS command. Default margins are set in the user profile; however, once changed, they are saved with the file on disk.
Similar to file margins, comment margins are used to identify text that is being entered into a comment block. If the beginning of the line and end of the line match the comment identifiers that are in effect for the current file, and the last entered character will move the cursor onto the trailing comment text, a new block comment line will be inserted at the current position, and the cursor positioned for further typing.
The capability exists to define two strings for any file extension, which will be recognised by the editor as indicating a comment. User Profile Extension Customisation discusses setting up these strings.
Comments are very important when writing code, but care must be taken that they do not confuse the code by making it appear cluttered. Aligning comments is one way to make the code appear neater and easier to read, but manually aligning comments is an unnecessary chore which can be handled quite readily by the editor, if it is provided with sufficient formatting rules. The X2 Editor contains five settings for inline comment formatting:
Inline comments are defined as comments which are located on the same line as some text. A shortcut method of entering these comments is defined by the editor. Simply indicate the comment with the quick_comment string defined for the file extension. The editor will detect this shorthand when you move off the current line with the cursor down or Enter keys. It will be converted by adding the comment prefix and suffix strings to the body of the comment, and aligning it to the desired margins. See the following picture for an example of how this works.
By default, the quick_comment string is "", which means no
comment conversion will be performed. Comments are also not converted if a
regular comment string is found on the same line. Quick comment conversion
may be turned on in the user profile by defining a
comment_prefix and a quick_comment string (see
User Profile Extension Customisation).
if (a > b) max = a; // New maximum value if (a > b) max = a; /* New maximum value*/
Block comments are defined as comments which are on their own without any code on the line. These may be formatted with the Alt-P key or the REFORMAT command. X2 contains special logic for formatting these comments. First, the line is scanned for occurrences of the prefix and suffix comment strings. If found, these strings are removed. Any multiple blanks in the line are removed. Two spaces are inserted after every sentence, where a sentence is defined as follows:
The formatting will continue until one of the following conditions is reached:
Finally, the text is formatted to fit within the defined reflow margins, the comment strings are added to the beginning and end of every line, and the line is written to the file. The cursor will be placed at the next file line which was NOT processed. Note that comment strings are not always desired in the reformatted output. They may be excluded with the user profile. See User Profile Extension Customisation for details.
For editing purposes block comment markets are treated as close to invisible as possible. For example, when the cursor is moved to a new line it will normally move to the first non-blank text on that new line. If, however, the new line is a block comment, the cursor is moved to the first text after the comment start. Similarly, inserting text at the end of the block comment will automatically insert a new block comment and position the cursor appropriately to continue typing without interruption. Finally, deleting characters within a block comment will not adjust the right comment marker, so the block comment will remain intact.
If comment prefix and suffix strings have been set up through the user profile, they will be used when re-formatting comments. Several checks are made on the supplied strings for use with different formatting jobs:
When writing code it is often useful if parts of the code can be displayed in a different colour from the normal text colour. X2 provides the ability to display comments, special keywords, and quoted strings in a different colour. Highlighting is provided on a text line in a hierarchy of precedence, which is:
Before any line is displayed on the screen, it is scanned for comments. If a comment is detected, it will be displayed in a different colour, which can be modified in the user profile. If the comment colour is chosen to be the same as the normal text colour, this feature will be effectively disabled.
X2 does not attempt to detect comments which may span more than one line, nor code which has been commented out with such tricks as the C language #if 0 preprocessor command. To add this feature would require a language-sensitive file parser, and would slow down processing speed.
Two sets of keywords may be defined in the user profile, which will be displayed using the keywords or alt_keywords colour if detected in an uncommented section of a line. Keyword detection is limited to the following rules:
The keyword search logic necessarily involves a certain overhead in the display of each line. The performance penalty will increase as the number of keywords increases. If you find the performance to be unacceptable, this feature may be disabled by removing all occurrences of the highlight_keyword and alt_highlight_kw strings from your profile with the _RESET keyword.
Language context keywords are sometimes desired to have special capitalisation, either for cosmetic reasons or because the language is case sensitive. The keyword_trans profile setting can be used to automatically translate keywords on changed lines into all upper case, all lower case, or into mixed case.
Multiple highlight_keyword and alt_highlight_kw profile lines may be specified for a given extension. Note that keywords must be separated in the profile by a comma but not a space, as spaces may be considered part of the keyword text.
The default editor highlights the current or cursor line the same as other file lines, but this may be changed in the user profile with the csr_line colour setting. Setting it to an explicit colour will only change the portion of the current line that would normally be displayed with the data colour, but using the special keyword reverse will cause the entire current line contents to be displayed using the reverse of the normal colours. For example, if a character would normally be displayed with black on white, it would be displayed for the cursor line as white on black.
Normally when you split a line the line is terminated at the cursor position, and everything to the right of the cursor is inserted as a new line in the file. If the current line contains an unmatched left parenthesis "(" before the cursor position, the new line will be lined up beneath the first non-blank character following the parenthesis. If the current line begins with a bulleted list, i.e. it begins with "- ", the new line will be aligned beneath the beginning of the list text. If the current line contains no left parenthesis and does not indicate a list, the new line will be lined up with the first non-blank character on the old line.
The X2 Editor defines file margins which will cause text to be automatically split when a line gets too long. For example, if the file margins are defined as 1 70 1 77, any character entry that causes the current line to extend beyond position 70 will cause the current line to be split at the first blank before column 70. If the cursor is at the end of the current line, it will be moved to the end of the newly inserted line.
When compiling source code, most programmers will see warnings and error messages from the compiler. Instead of writing down the source file, line of the error, and the error message, it is convenient to let the computer do some of the work. The author makes extensive use of Make files to compile source code, and uses the following inference rule line to speed up detection and fixing of errors:
$(CC) $(CCOPTS) $*.c >$*.ERR 2>&1 || x $*.c -ERR
This rather cryptic looking line does many things for the user. First, it uses the compiler defined by $(CC) to compile the source code, represented by $*.c, with the options defined by $(CCOPTS). It re-directs the output from the compiler to a file with the same filename as the source code, and an extension of ERR. The directive "2>&1" makes sure that all error messages that would normally be written to stderr are also written to the .ERR file. If the return code from the compiler is non-zero, the editor will be invoked on the source file with the -ERR option. -ERR from the operating system command line will automatically load the .ERR file and insert a specially-marked comment at the appropriate line in the source file for each error it finds. Ctrl-N can be used to locate the next error comment.
Compiler error output differs with different compilers and source languages. The compiler error parsing rules are controlled through the openfile_id parameter in the user profile, which is defined for all files with extension .ERR. Note that the error parsing scans file lines for valid filename characters; all characters that are recognised by the operating system are considered valid except the left and right parentheses, which are commonly used in compiler output to delimit such things as error line numbers. The equals sign (=) is also not accepted as it has a special meaning to the editor.
If a file is loaded with the -ERR option, you will hear a short beep from the speaker. This is to alert you that you have an error in your code. Usually when running a long MAKE program under OS/2, you will want to take advantage of multitasking and do something else while waiting. If your MAKE is running in a fullscreen session which is not visible to you, an audible notification of an abnormal MAKE termination can be quite useful.
When all errors have been corrected, there is no need to remove the comment lines which were inserted by -ERR. Simply saving the file will cause the editor to scan for these lines and remove them before saving the file to disk. If they are in the way, they may be removed with Ctrl-O.
When the editor is ended, it will terminate with a special return code of -1. This indicates to the MAKE program that one of its commands failed, so it will not try to continue with the make.
Compiler error parsing is known to work with the following compiler output:
The X2 Editor has the ability to selectively exclude and include lines from the display. The lines are still part of the file and will be saved to disk with the rest of the file, but are not viewed. In addition, any mark operation (copy, move, delete, shift left or right) that spans one or more excluded lines will only affect the visible lines in the mark. Optionally, a shadow line can be displayed to represent the hidden lines. An ALL command is also provided which works much like XEDIT's ALL command. See ALL for a detailed description of the ALL command.
When a file is saved with the X2 Editor, additional information is written to the file's extended attributes (EAs). Specific editor settings are saved, so that when the file is next edited, the edit environment can be restored as much as possible. The settings that are saved and restored are:
If no saved information is found for a file, or the /TOP option is used, the cursor position will default to the first row of the file. The default file margins, tab settings, and comment formatting style are obtained from the user profile. Extended attribute information is saved in all versions except the DOS version. Extended attributes may be turned off with the EA command (see EA). Note that the Windows, AIX, and Linux versions save extended attribute information into a file called XEAINFO.DTA in the directory specified by the X2PATH environment variable.
The X2 Editor supports three types of marks:
Line marks include the entire contents of the line, while block marks only include a sub-section of a line. Block marks may be defined by specifying two corners of the block with Alt-B, or by moving the cursor with the cursor movement keys while simultaneously depressing the Shift key. Word marks are special cases of block marks. A word mark has the special property that when copied or moved, if the target area is preceded with a space, an extra space will be inserted with the marked word. When deleting a word mark, if the word is preceded and succeeded with a space, an extra space will be removed.
The default X2 Editor follows the E Editor standards for marking text, with one important exception. If a mark already exists, it is removed in response to a request for a new mark, instead of being extended as in the E Editor. For example, the first invocation of Alt-L will define a single line mark. If Alt-L is pressed again with the cursor on another line, the line mark is extended. Another press of Alt-L will cause the previous line mark to be removed, and a single line mark to be started at the current cursor location. Options are available to allow the mark keys to always extend a current mark. For example, to force the Alt-L key to extend a line mark, define it to "MARK LINE EXTEND".
The X2 Editor provides a facility to record keystrokes for later playback. Every key pressed will be remembered between two presses of the record key (Ctrl-R is the default key). The key sequence can then be replayed with another key, which is Ctrl-T in the default configuration. This is a very handy way to write little "on-the-fly" macros to do some kind of repetitive task. Note that the keystroke buffer can hold a maximum of 255 keystrokes. If this limit is hit before the recording is stopped, it will automatically be stopped and a message will inform the user.
When playing back a key sequence, the entire sequence may not be completed. If the sequence contains a Find command which is unsuccessful, it halts and displays a message. This allows fast execution of a sequence by holding down the Ctrl-T key while still providing some file protection by checking for deviations from expected response. The recording can be re-activated by switching to another file, or by defining a new Find string and executing a successful find.
Control over the continuation of playback sequences is managed internally by the error flag. The error flag is cleared when a remembered key sequence is completed, but set whenever a Find operation returns a non-zero return code. It may be controlled through a user macro or even interactively via the command line, by use of the ERRORFLAG command.
The initial state of the command line and insert mode are remembered when starting a keystroke recording. These values are restored to their original states as part of the playback initialisation. A message "Remembering keys" is displayed in place of the PF line while keystroke recording is active.
When X2 loads a file, it scans the first 80 bytes of the file for the null (hex 00) character. If it finds a null character in the file, the file will initially be displayed in hex mode. You can toggle the display back to text mode with the Alt-H key. See Hexadecimal Mode Screen Layout for details about editor behaviour in hex mode.
The scan for binary files will be skipped if the /BIN command line option is used to specify binary editing. Invoking The Editor describes the /BIN option.
The following settings are provided. They can be tailored through user commands, and their initial values may be set through the user profile. In each case, issuing the command with no parameters will cause its setting to be toggled, or the keywords ON and OFF will explicitly set the command.
When viewing files that have the Read Only attribute set, the editor will automatically disable any changes to the file. This Browse Mode may be turned off, i.e. normal editing mode is turned on, with the BROWSE OFF command.
The X2 Editor will normally save file information in a file's Extended Attributes, so that the edit view will be restored when next viewing the file. If this is not desired, setting EA OFF will turn off this feature for the current file. The EA feature may be turned off for all files on a disk with the user profile.
The X2 Editor provides the ability to selectively exclude lines from the display, just like the XEDIT editor does on VM. When lines are excluded, a "shadow" line can be displayed in their place, to let you know how many lines have been excluded. The shadow line can be suppressed by turning the SHADOW setting OFF. The default value for new files is ON. The SHADOW setting is unique for each file in the ring.
When searching for text, sometimes text will be split across multiple lines of the file. Setting SPAN to ON will cause searches to span as many lines as necessary to find text. SPAN is always ON when viewing a file in hex mode, and may be turned on with the SPAN command for other files. It is OFF by default for text files since it causes search performance degradation.
Normally the status line is updated whenever the cursor is moved within a file. This slows down the editor, particularly when using a slow PC. In these cases, performance gains can be made by turning off the status line. Entering STATUS OFF will turn the status line off, and STATUS ON can be used to restore it. The STATUS setting is global for every file in the ring.
If any expand_keyword lines are found in the profile, they will be converted to expand_replace lines in response to the space character. This syntax assistance feature is not always desired, so it can be turned on and off with the SYNTAX command. Entering SYNTAX OFF will turn syntax assistance off, and SYNTAX ON will turn it back on. The SYNTAX setting is unique for each file in the ring.
For locating text, it is often useful to locate the text even if it is located above the current position. If a search reaches the end of the file without finding the text, it will continue from the top of file to the current position if the WRAP setting is ON (the default). Setting WRAP to OFF will terminate an unsuccessful search at the bottom of the file. The WRAP setting is unique for each file in the ring.
If WRAP is set ON and a search wraps around the top or bottom of the file, a message is displayed informing the user. WRAP will also cause a backwards (towards top of file) search to wrap around to the bottom of the file.