Apparatti and Computer Program Products for Integrating Editors With Applications

The subject matter of this application is related to the subject matter of application Ser. No. 08/530,595, pending, entitled, "METHOD AND APPARATUS FOR LINKING COMPILER ERROR CODES TO RELEVANT INFORMATION" filed concurrently herewith by Achut P. Reddy, Daniel J. O'Leary, Robert B. Jervis, Robin Jeffries and Evan W. Adams and having the same assignee as the present invention and is incorporated herein by reference in its entirety.

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

The present invention relates to computer software, and more specifically to the integration of editors with applications.

Editors are widely used in the computer field. Many editors are text editors which display text on a computer screen and allow a user to modify the appearance or the content of the text. Many editors allow the user to make such changes through the use of an editor-specific command structure of key sequences, menus or both. Many application programs, such as electronic mail programs or debugger programs, include a text editor to allow the user of the application program to change the content of data used by the application. Typically, each application contains its own unique editor to allow the user to input or change the content of data. Because the editor commands in each of these editors are often editor-specific, a user must learn several different command structures in order to use the several editors contained in the application programs he or she uses. Although for word processing purposes a user may select an independent editor, i.e. an editor that is not contained in the word processing program, many applications such as electronic mail or debuggers require the use of an editor specific to that application in order to integrate the editor with the application. An integrated editor and application work together to provide such features as the display by the editor of parts of an application source file along with the display of application specific icons. Thus, each application provider desiring an editor with integrated functionality must write and include an editor for use with the application, thereby extending the development time for producing the application. Additionally, the user of a document text editor or editors integrated with various applications must learn several command structures because the applications do not allow the user to utilize the same editor across applications and the editors included with one application may operate differently from the other editors.

Many editors are integrated with the associated application program to allow the editor and the application program to communicate. This communication allows the editor to control the application program, the application program to control the editor, or both. For example, many compiler debuggers contain an integrated editor which allows the user to communicate with the debugger via commands typed to the editor. For example, the integrated debugger contained in the Delphi compiler available commercially from Borland International of Scotts Valley, Calif. allows the user of the editor to instruct the editor to instruct the compiler to set a breakpoint. Additionally, when the compiler detects an unrecoverable error, it automatically runs the editor, which displays the file and displays an icon indicating the approximate location of the code containing the error and another icon indicating nearby breakpoints.

Some applications allow a user to select an editor to create and modify text which is subsequently used by the application. While this approach allows a user to use the most desirable editor, the selected editor is not truly integrated with the application in the manner according to the present invention.

One approach which has attempted to eliminate the requirement that a user learn several editors is similar to the common user interface standard previously offered by International Business Machines of Armonk, N. Y. This common user interface standard allowed the operating system manufacturer to set standards for commonly used commands such as "File Open" to allow all application programs to perform the task of opening files and other commonly used commands to operate in a similar manner. However, because the number of commands in an editor is significantly more than the number of commands which were defined by the standards, the problem of learning multiple command sets continues.

It is desirable to allow a user to integrate an editor of the user's choosing with an application, allowing a user to use a single editor for more than one application.

An integrator is used as an intelligent translator to communicate between one or more applications and one or more independent editors to allow the independent editors to provide integrated functionality with the applications. The integrator intercepts commands from one or more applications and adapts the commands for operation by an editor designated to operate with the application. Thus, the applications may communicate with the editors without the knowledge of the commands or formats that the editors require to carry out the desired action. The editor may be configured to send commands to the integrator for transmission to the application. Thus, an editor may provide integrated functionality with the application. The user may use one or more editors with multiple applications which provide functionality integrated with the editor. Thus, the benefits of an integrated editor may be realized without requiring the development or use of an application specific editor.

FIG. 1A is a block schematic diagram of a conventional computer system.

FIG. 1B is a block schematic diagram of an integrator coupled to multiple applications and multiple editors according to a first embodiment of the present invention.

FIG. 1C is a block schematic diagram of an integrator coupled to multiple applications and multiple editors according to a second embodiment of the present invention.

FIG. 2A is a flowchart illustrating a method of registration according to one embodiment of the present invention.

FIG. 2B is a flowchart illustrating a method of removing an item from registration according to the present invention.

FIG. 3A is a flowchart illustrating a method of associating an editor with one or more applications according to one embodiment of the present invention.

FIG. 3B is a flowchart illustrating a method of integrating an application with an editor according to one embodiment of the present invention.

FIG. 4A is a flowchart illustrating method of processing editor messages according to one embodiment of the present invention.

FIG. 4B is a flowchart illustrating a method of processing editor messages according to a second embodiment of the present invention.

Referring now to Figure 1A, a conventional computer system 109 is shown. A processor 101 is coupled to a first storage system 108 such as RAM memory and a second storage system 103, such as a disk storage system. A user communicates with the system 109 using a keyboard 104 and a monitor 105 and in one embodiment, a pointing device 106 such as a mouse. Computer program product reader 107, such as a memory, hard drive, floppy disk drive or CD-ROM drive is coupled to processor 101 to allow computer readable program code devices 97 such as encoded bits of a computer program product 99 such as a memory, hard disk, floppy disk, CD-ROM or other storage device to be input to processor 101 and stored in memory 108 and/or disk storage 103 for use in controlling the operation of the computer system 109 when computer program product 99 is inserted into slot 98 of computer program product reader 107. An operating system is loaded into memory 108 or disk storage 103 or a combination of memory 108 and disk storage 103 and instructs processor 101 to load and execute applications or editors described below. In one embodiment, the computer readable code devices 97 are encoded to cause the computer system 109 to operate as described below.

Referring now to Figure 1B, one embodiment of three applications 110, 112, 114 which may be integrated with any of two editors using an integrator 120 according to the present invention is shown. Applications 110, 112, 114 are coupled to integrator 120 via application communication channels 140. Applications 110, 112, 114 may be any application which can send or receive some or all of the commands described below. Integrator 120 is coupled to editors 132, 134 via editor communication channel 142. Editors 130, 132 may be any editor or text editor, such as GNUEMACS available from Free Software Foundation of Cambridge, Mass., XEMACS available from the University of Illinois of Urbana, Ill. or VI, available commercially from Sun Microsystems of Mountain View, Calif. Communication channels 140, 142 may be established through conventional software parameter-passing techniques using the memory of a computer. In another embodiment, communication channels 140, 142 are established using interprocess communications, such as ToolTalk available commercially from Sun Microsystems, Inc., of Mountain View, Calif. In one embodiment, applications 110, 112, 114, integrator 120 and editors 132, 134 are implemented as computer programs running under the conventional Solaris operating system commercially available from Sun Microsystems, Inc., of Mountain View, Calif. on a conventional SPARCStation 10 microcomputer commercially available from Sun Microsystems, Inc., of Mountain View, Calif.

In the illustrated embodiment of Figure 1B, the integrator 120 is coupled to three applications 110, 112, 114 and two editors 132, 134. However, integrator 120 may be coupled to any number of applications 110, 112, 114, and any number of editors 132, 134, and the number of editor communication channels and application communication channels may be as few as one.

In one embodiment, integrator 120 contains three modules, namely, a registration manager 122, an editor to application communicator (EAC) 126 and an application to editor communicator (AEC) 124. Application to editor communicator 124 contains an information manager 164 for managing certain information received by integrator 120, and editor command assembler 162 for assembling and sending certain commands to editors 132, 134 and the operating system 102. Referring momentarily to Figure 1C, in one embodiment, integrator 120 operates as the illustrated embodiment of FIG. 1B, except the functions of editor command assembler 162 and information manager 164 are dispersed among several modules 166, 167, 168, 169 organized by commands received by, and commands transmitted from integrator 120. Referring again to FIG. 1B, in one embodiment, integrator 120 may be a module contained in one or more of applications 110, 112, 114. In another embodiment, integrator 120 runs as a separate program or process.

In one embodiment, integrator 120 contains a registration manager 122, which in one embodiment, accepts commands described below from applications 110, 112, 114 and editors 132, 134 to allow applications 110, 112, 114 or editors 132, 134 to register with the integrator 120. In one embodiment, registration manager 122 allows the registration of other items, such as the appearance of glyphs, or pictures as described below.

Referring now to FIG. 2A, a method of registering an item is shown. Registration commands are received which contain information about the item being registered 210. The item is registered by storing some or all of the information about the item as described below to provide later availability of the information 212.

Referring to FIG. 2B, a method of removing an item from registration is shown. A deregistration command is received indicating the item to remove from registration 220. The item is deregistered by marking or removing some or all of the information about the item 222.

a. Application Registration Commands.

Referring again to Figure 1B, in one embodiment, integrator 120 operates as software under a Solaris operating system 102 commercially available from Sun Microsystems Inc., of Mountain View, Calif. When the integrator 120 is loaded, for example by typing the path and executable filename of the integrator 120 to the operating system, integrator 120 registers itself with the operating system 102 using the Unix or Solaris "socket" command. When applications 110, 112, 114 are loaded by the operating system 102, applications 110, 112, 114 request a channel 140 to the integrator using the "socket" command of the operating system 102.

In one embodiment, software such as ToolTalk, available commercially from Sun Microsystems of Mountain View, Calif. handles the communication between applications 110, 112, 114 and integrator 120. ToolTalk intercepts the operating system request for communication, and arranges the communication channel 140. If the integrator 120 is not loaded when the application 110, 112, 114 requests the communication, ToolTalk instructs the operating system 102 to load and execute the integrator 120.

In one embodiment, when an application 110, 112, 114 voluntarily disconnects from the operating system 102, for example by sending a socket command, or if the operating system aborts the application 110, 112, 114 or detects that the application 110, 112, 114 has aborted operation, operating system 102 disconnects the channel 140 and removes some or all of the information associated with the application 110, 112, 114 or channel 140.

b. Editor Registration Commands.

In one embodiment, editors 132, 134 register with the registration manager 122 of the integrator 120 to establish the editor communication channel 142 and the type of commands the integrator 120 must use to communicate with the particular editor 132, 134. In one embodiment, editors 132, 134 send registration commands and information to the registration manager 122. In one embodiment, editor information includes the editor type and information about the editor communication channel 142 used to communicate with the editor 132, 134 being registered. The registration manager 122 stores the editor information in an editor registration table 121 for later use.

In one embodiment, when an application 110, 112, 114 first sends a command to the integrator 120 as described herein, integrator 120 prompts the user to select an editor 132, 134 from those registered with the integrator 120. In one embodiment, the selected editor 132, 134 is used for all applications 110, 112, 114, and the user is only prompted as a result of the first command from an application 110, 112, 114. The selected editor 132, 134 is noted by integrator 120 in application registration table 123. In another embodiment, the user is prompted to select an editor 132, 134 for each application 110, 112, 114 as a result of the first command from each application 110, 112, 114 to the integrator 120. Editor information may be stored by integrator 120 in application registration table 123 in this embodiment, to associate the selected editor 132, 134 with each application 110, 112, 114.

Referring now to FIG. 3A, one embodiment of a method of associating an editor with one or more applications is shown. An editor designator is received from a user 302. The editor associated with the designator is associated with one or more applications 304, either by allowing the user to identify one or more applications with which the editor is to be associated, or by associating the selected editor with all of the applications the user uses.

Referring again to FIG. 1B, in one embodiment, editors 132, 134 may disconnect from the integrator 120 by sending a disconnect command to the registration manager 122. In one embodiment, the registration manager 122 removes the information about the editor which sent the command from the editor registration table 121. In another embodiment, the registration manager 122 marks the information in the editor registration table 121 to indicate deregistration of the editor.

c. Defining Glyphs.

Glyphs are small picture or icons which are used to create a visual indicator on a screen and are often used with integrated editors such as those integrated with debuggers to show the location of a breakpoint or program counter. In one embodiment, integrator 120 allows glyphs defined as described below to be used in the same manner. In one embodiment, glyphs are registered by registration manager 122 or redefined to allow for easy reuse as described below. In one embodiment, registration manager 122 receives a command to define a glyph from an application 110, 112, 114 via application communication channel 140. In one embodiment, the command is received via an operating system call to execute a registration module in registration manager 122. In one embodiment, registration manager 122 receives from application 110, 112, 114 via application communications channel 140 a character string containing the type of the glyph, which is a unique name for the glyph assigned by the application 110, 112, 114 registering it, a character string which holds the filename of the file containing the glyph, a boolean value which determines whether the glyph is to be highlighted using a color and an X-Windows color code containing the color used to highlight the glyph.

In one embodiment, glyph registration information received by registration manager 122 is stored in a glyph table 176 which holds the glyph type, a handle to the file containing the glyph, a bit representing whether the glyph is highlighted, and a code containing the highlighting color in each entry, one entry for each glyph registered. In one embodiment, glyphs are identified by a glyph handle obtained as described below. A handle is a token which identifies an item. Thus, the handle to a file contains the operating system identifier used to locate the file.

In one embodiment, after a glyph has been registered, a handle for the glyph may be located and returned for later use by an application 110, 112, 114 by sending to integrator 120 a command code for MarkTypeToIX and the type assigned by the application 110, 112, 114. Registration manager 122 uses the type to locate the glyph, and returns an integer handle for the glyph to the application 110, 112, 114.

Once the glyph is registered, it may be used and reused by several marks. In one embodiment, once a glyph is registered, it remains registered until integrator 120 terminates.

In one embodiment, an application 110, 112, 114 may direct the integrator 120 to instruct one or more editors 130, 132 to perform an operation using one or more editor integration commands. An editor integration command is a command for altering the display of an editor to correspond with the operation of an application to allow the editor to appear integrated with the application.

In one embodiment, as will be described below, applications 110, 112, 114 do not need to know the format and content of the editor-specific commands which will provide the integrated functionality. The information contained in application registration table 123 contains an identifier of one or more editors 132, 134 associated with the application 110, 112, 114. Integrator 120 uses the information stored in application registration table 123 to determine which editor or editors 132, 134 to send editor commands based upon the commands received from a particular application 110, 112, 114, or in one embodiment, which application 110, 112, 114 to send application commands based upon the commands received from a particular editor 132, 134. Integrator 120 uses the editor registration information stored in editor registration table 121 to convert the editor integration commands received from applications 110, 112, 114 to the format and content required by each editor 132, 134.

Referring now to FIGS. 1B and 3B, one embodiment of a method of integrating an application with an editor is shown. Symbol display information is stored for later use 308. An editor integration command identifier, such as a code for a command described below, and associated parameters are received 310 and the editor's command syntax required to implement the command received is identified 312. The parameters received may optionally be stored 311. Such identification allows integrator 120 to provide integrated functionality between an application 110, 112, 114 and more than one editor. In one embodiment, the command identifiers are procedure calls to a module in the AEC 124 which directs the operation of the integrator 120 as described below. If additional information or any stored parameters are required to complete the editor's command syntax, such information is optionally located and retrieved from storage 313, 314. This information and additional information may be adjusted to reflect any new status information which may be inferred by the operation of the command 315, 316. The editor command required to implement the command received is assembled 318 and then sent 320 to the editor for execution. In another embodiment, the assembly step 318 is omitted and parts of the command are sent to the editor as they are identified.

In one embodiment, some command identifiers require a response. If such a command is received, one or more return parameters are sent to the application which sent the command identifier or to another application.

Referring again to FIG. 1B, in one embodiment, the above method is performed by an application to editor communicator 124, or AEC. The AEC 124 is coupled to the application communication channel 140 to allow the AEC 124 to receive commands sent by the applications 110, 112, 114. In one embodiment, the AEC 124 identifies the editor command syntax to be sent in response to the receipt of a command using a table of commands 160. The table of commands contains a list of many of the command identifiers and the syntax of the corresponding editor command for each editor 132, 134 with which the integrator 120 communicates. The table of commands 160 contains the editor commands and format of any common parameters which must be sent to the editor to perform the editor commands passed from the application 110, 112, 114 to the editors 132, 134 by integrator 120 as described below. The table of commands 160 need not be stored in AEC 124 in a table format, as the information may be interspersed in various memory locations. An editor command assembler 162 assembles the information described below to generate an editor command in a format according to the table of commands 160 allowing the command to be processed by an editor 132, 134. The editor command assembler 162 sends the editor command to editors 132, 134 via editor communication channel 142.

In one embodiment command identifiers are processed by AEC 124 to manipulate files, and process indicators known as marks and markers to provide certain integrated functionality between the applications 110, 112, 114 and editors 132, 134.

a. Editor File Manipulation Commands

In one embodiment, applications 110, 112, 114 may direct integrator 120 to instruct editor 132, 134 to load and display a particular stored computer system file.

In one embodiment, integrator 120 receives a "LoadFile" command identifier and a character string parameter containing the filename of the desired file from an application 110, 112, 114 via an application communication channel 140. For each application 110, 112, 114 communicating with the integrator 120, integrator 120 maintains additional information in a file list 150, 152, 154 containing a list of names of all files encountered by the editor which were used with the application, and handles to each file. Information manager 164 adds the file to a file list 150, 152, 154 of the application 110, 112, 114 which sent the command.

Editor command assembler 162 assembles and sends via editor communication channel 142 the appropriate editor command, such as the command described below, to the editor 132, 134 to instruct the editor to load the file. If the file is not in the file list 150, 152, 154 of the application 110, 112, 114 which initiated the LoadFile command, editor command assembler 162 build and sends to the editor 132, 134 associated with the application which sent the command using the application registration table 123 an editing command to load the file, and information manager 164 places the filename in the file list 150, 152, 154. If the file is in the file list 150, 152, 154, editor command assembler 162 builds and sends an editor command to editor 132, 134 to reload the file by first closing the previously opened and loaded version of the file and then reloading it as described below.

In one embodiment, editor 132 is the conventional XEMACS editor, adapted as described below and the editor command to load a file "filename", is: (eserve-load-file "filename").

In one embodiment, the editor 132, 134 must be adapted to accommodate the commands sent by the integrator 120. In one embodiment, editor 132 is a conventional XEMACS editor, and the sequence of commands listed in Appendix 1 is entered to the editor 132, 134 to allow the editor commands to perform the desired function. In one embodiment, the sequence listed in Appendix 1 is stored into a disk file in directory/home/user1/elisp, in the file ebo.el. The sequence is loaded into the conventional XEMACS editor using the following two XEMACS commands:

In one embodiment, editor 134 is a conventional VI editor and the command to open a file "filename", is :e filename, and the command to close the current file is :q.

In one embodiment, if an application 110, 112, 114 directs integrator 120 to load a file, and no editor is loaded, integrator 120 prompts the user to select an editor, and editor command assembler 162 builds an operating system command to run the editor selected and sends the command to the operating system 102 using Operating System communication channel 144 to instruct the operating system to run the editor 132, 134 selected. The editor 132, 134 run is registered by registration manager 122 as described above.

In one embodiment, the operating system 102 is the Solaris operating system commercially available from Sun Microsystems of Mountain View, California, the editor 132 selected is a conventional XEMACS editor and the AEC calls the operating system to load XEMACS using the command,

In one embodiment, an application 110, 112, 114 may instruct the editor to save or close a file using a "SaveFile" or "CloseFile" command. The application 110, 112, 114 sends the integrator 120 the command identifier and a text string parameter containing the filename via application communications channel 140, and the command assembler 162 builds and sends via editor communications channel 142 to an editor 132,134 associated with the application using the application registration table 123 the close file command as described above. In one embodiment, if a file is closed, information manager 164 adjusts the stored information by removing the file from the appropriate file list 150, 152, 154.

Some editors 132, 134 do not allow a file that has been changed to be closed without asking the user whether to save the file before closing it. In one embodiment, the application 110, 112, 114 can instruct the integrator 120 via a parameter to instruct editor 132, 134 to force the file to be closed even if it is not saved, without prompting the user, by sending the CloseFile command along with this parameter. Editor command assembler 162 builds the editor command as described below and information manager 164 removes the file from the file list 150, 152, 154. In one embodiment, editor 132 is a conventional XEMACS editor, adapted as described above, and an editor command to close a file "filename", without prompting the user to save is:

Some editors 132, 134 allow multiple files to be opened and displayed on cascaded windows, with the currently active document displayed in front of the others. The conventional XEMACS editor allows this feature, but the conventional VI editor does not. A file may be moved to the front with the "Front" command. An application 110, 112, 114 may instruct the integrator 120 to move a file to the front by sending to integrator 120 via editor communications channel 142 the command identifier and a text string parameter containing the file to place in front. The information manager 164 verifies the file is in the File List 150, 152, 154 and if so, editor command assembler builds and sends the appropriate command code and file identifier to the editor 132, 134 via editor communications channel 142. In one embodiment, editor 132 is a conventional XEMACS editor, adapted as described above and the editor command to move the file "filename", to the front is: (eserve-front-file "filename").

In one embodiment, if the file is not open, the integrator 120 first opens it as described above. In another embodiment, if the file is not open, the integrator 120 may indicate an error to the application 110, 112, 114 which sent the Front command by sending an error code to the application 110, 112, 114 via the application communication Channel 140. In another embodiment, if the file is not open integrator 120 will indicate an error to the user.

In one embodiment, the application 110, 112, 114 can instruct the integrator 120 to display a particular line in a file using a "GoToLineNo" command. An application 110, 112, 114 sends via editor communications channel 142 to the integrator 120 the command identifier, a text string parameter containing the filename and a text string or integer parameter indicating the line number of the file to be displayed. Editor command assembler 162 builds and sends the appropriate editor command to the editor 132, 134 to cause the indicated line number and a portion of text before or after the indicated line number to be displayed to the user as described below. In one embodiment, if the indicated file is not presently displayed in front of the other windows as described above, the "front" command described above is assembled and sent to the editor 132, 134, by the editor command assembler 162 to place the file in the front window.

In one embodiment, editor 132 is a conventional XEMACS editor, adapted as described above and the editor command to go to a line number nnn in the file "filename" is (eserve-goto-line "filename" nnn).

b. Marks

It is often desirable to allow for the display of indicators in a file, in addition to the text which is present. Such indicators are referred to as marks. In one embodiment, marks remain adjacent to specified text. If the adjacent text is deleted, some editors delete the mark, but other editors, such as the VI editor, place the mark at the top of the file. As other text is inserted or deleted in front of the mark, the mark will move along with the adjacent text. In one embodiment, marks are used to display small pictures, or "glyphs" to indicate to the user of the editor 132, 134 the location of a particular item. For example, a user of a debugger application 110, 112, 114 may see the location of one or more breakpoints in a file while the user edits the file using editor 132, 134.

In one embodiment, a mark may have an appearance, such as invisible, or highlighted, may have a glyph, or small picture to indicate its location, and may even have a text portion displayed nearby, such as in a footer of the display. In one embodiment, these properties are displayed only when the portion of the file near the mark is displayed.

In one embodiment, marks are inserted into a file by applications 110, 112, 114. The application 110, 112, 114 may instruct the integrator 120 to direct the editor how and where to display the mark, may change the appearance of the mark, or may delete the mark.

In one embodiment, editors 132, 134 are capable of displaying only those marks which have been registered by an application 110, 112, 114 using the "AddTermGlyph" command described below.

In one embodiment, a mark is inserted into a file by an application 110, 112, 114 using the "AddMark" function. The application 110, 112, 114 sends the integrator 120 via editor communications channel 142 the command identifier for AddMark, a character string parameter containing the filename of the file into which the mark will be inserted, an integer parameter containing the line number in the file into which the mark is to be inserted, an integer parameter containing the column in the line into which the mark is to be inserted, an integer parameter containing the handle to the glyph, obtained via the MarkTypeToIX command described above, and a character string parameter containing a message to be displayed in a footer or elsewhere. In one embodiment, information manager 164 locates the glyph in the glyph table 176 using the handle parameter received and editor command assembler 162 assembles an editor command to place the mark in the file as described below. Editor command assembler 162 sends the editor commands assembled to the editor 132, 134 via editor communication channel 142. In one embodiment, editor 132 is a conventional XEMACS editor, adapted as described above which inserts a mark having a name "marknamel" having a type marktype, at line number nnn in the file "filename" in response to the following editor command:

The AEC 124 returns a handle to the mark to the application 110, 112, 114 which sent the command identifier via application communication channel 140 for future use as described below.

As described below, in one embodiment, applications 110, 112, 114 refer to marks using a handle, and editors 132, 134 refer to marks using names. AEC 124 translates between the mark name provided used by the editor, and the handle to the mark used by an application 110, 112, 114. In one embodiment, information manager 164 maintains a list of the name of each mark and associated handles for each file in one or more mark lists 172, 174 and each mark list is associated with a file via a pointer in the file list. AddMark causes the information manager 164 to insert a mark entry into the mark list 172, 174.

In one embodiment, an application 110, 112, 114 may direct integrator 120 to instruct an editor 132, 134 to display a portion of a file containing a particular mark added using the Addmark command described above. Such a capability is used in one embodiment where the application 110, 112, 114 is a debugger which stops execution because the debugger application 110, 112, 114 has reached a breakpoint, and wishes to display to the user the breakpoint glyph and the breakpoint code near the breakpoint glyph. In one embodiment, the footer text line associated with the mark is also displayed. The application 110, 112, 114 requests the integrator 120 to display the portion of the file near the mark using the "GoToMark" command. The application sends to integrator 120 via editor communications channel 142 the command identifier for the GoToMark command, and a parameter containing the handle to the mark. Information manager 164 looks up the mark, including the footer text, in the mark list 172, 174 corresponding to any file in the file list 150, 152, 154 for the application 110, 112, 114 which sent the command. Information manager 164 uses the mark list 172, 174 to identify the mark name used by the editor 132, 134, and editor command assembler assembles and sends via editor communication channel 142 named command to instruct the editor 132, 134 to display the mark, including its associated footer text, and a portion of the file adjacent to the mark having such name. In one embodiment, editor 132 is a conventional XEMACS editor, adapted as described above, and the editor command to display the mark named "mark-id" and a footer message "message" is:

However, not all editors possess the ability to embed a glyph and footer text in a mark as described above using the AddMark command. For example, the conventional VI editor does not have the ability to display glyphs and a text footer. In one embodiment, integrator 120 provides this capability through a terminal display filter 192. In this embodiment, editor command assembler 162 inserts a special sequence of characters in place of the mark. In one embodiment, the sequence is an escape sequence, a sequence of characters beginning with the ASCII code for escape, decimal 27. In one embodiment, editor 134 is a conventional VI editor, and the command to insert an escape sequence in a file is the ASCII code for escape, followed by the sequence. In one embodiment, the sequence is ›Gnnn where nnn is the mark identifier.

In one embodiment, information manager 164 stores the sequence of characters after the escape in the mark list 172, 174 to associate the marks represented by escape sequences with the sequence. Display filter 192 has an input 190 coupled to receive the display output of editor 134. When escape code detector 191 of display filter 192 detects the escape ASCII code, it requests the mark information from information manager 164. If the sequence is in the mark list 172, 174, the information to be inserted into the display, including the handle to the glyph file, is returned by information manager 164 to display inserter 193, which substitutes the mark information at the appropriate position in the display filter output 194 to include the desired mark. Display filter output 194 is coupled to the input of a conventional terminal driver 196 which produces the display. If information manager 164 indicates that the escape sequence is not stored in the mark list 172, 174 for the file displayed, display filter does not remove the escape sequence, instead passing it unchanged to display filter output 194 and to terminal driver 196.

In one embodiment, an application 110, 112, 114 instructs the integrator 120 to delete a mark using the "DeleteMark" command. The application 110, 112, 114 sends via editor communications channel 142 to the integrator 120 the command identifier for DeleteMark, and a parameter containing the handle of the mark, such as the handle received during AddMark described above. Information manager 164 deletes the mark from the mark list 174, 176 and editor command assembler 162 removes the mark from the file by assembling an editor command to locate and delete the mark and sending the command to the editor 132, 134 via editor communication channel 142. In one embodiment, editor 132 is a conventional XEMACS editor, adapted as described above, and the editor command to locate and remove a mark from the file "filename" is: (eserve-delete-mark "filename" markname)

In one embodiment, an application 110, 112, 114 may change the glyph displayed on a mark using the "EditorChangeMarkType" command. The application 110, 112, 114 sends via editor communications channel 142 the Command identifier for the EditorChangeMarkType command to integrator 120 along with parameters containing the handle of the mark to be changed and information regarding the change. In one embodiment, this information includes the glyph type of the new glyph to be displayed at the mark. Information manager 164 locates the mark in the mark list 172, 174 and appropriately adjusts the information in the mark list 172, 174 to accommodate the information changed. The command to update the glyph or character sequence corresponding to the glyph is assembled and sent by editor command assembler 162 to editor 132, 134 via editor communication channel 142 for display to the user. In one embodiment, editor 132 is a conventional XEMACS editor, adapted as described above, and the editor command to adjust the glyph attached to the mark named "markname" in file "filename" to the type "marktype" is: (eserve-change-mark-type "filename" markname marktype).

In one embodiment two types of indicators, marks and markers, may be displayed Marks are not expected to move relative to a position in the file, but may be copied to multiple locations in the file. For example, a debugger breakpoint is rarely moved, and there may be multiple breakpoints in a file. The command structure of marks described above is optimized for glyphs which are copied more often than they are moved. In one embodiment such as that described above, once defined, a mark may be duplicated with a single command, but it takes two commands, one to delete the mark, another to add it to the new location, to move a mark.

Markers are similar to marks, but are expected to move relative to a particular position in the file more often than a mark. In one embodiment, a debugger program counter is a marker, as the program counter would be expected to move around from time to time. While a mark may be moved by first deleting it and then adding it to a new location, a marker may be moved merely by indicating its new location as described below. Thus, in one embodiment the command structure associated with a marker takes only one command to move a marker, but two to copy the marker.

In one embodiment, markers are maintained in the mark lists 172, 174 by information manager 164 just as marks are maintained. In another embodiment, a separate marker list is maintained. The present invention does not require the commands for both marks and markers, though having both sets of commands can make certain applications 110, 112, 114 easier to program and faster to operate.

Glyphs for markers are registered and indexed using the AddTermGlyph and MarkTypeToIX procedures described above. A marker is created using the "NewEditorMarker" command. Applications 110, 112, 114 send to integrator 120 via editor communications channel 142 the command identifier for NewEditorMarker and the type, or application-generated name of the marker as a parameter. AEC 124 inserts a marker in the same manner that AEC 124 inserts a mark as described above.

In one embodiment, markers are deleted using the "DeleteEditorMarker" command. Applications 110, 112, 114 send to integrator 120 via applications communications channel 140 the command identifier for DeleteEditorMarker and the handle to the marker received as described above. Markers are deleted in the same fashion as the deletion of marks described above.

In one embodiment, the location of a marker is defined and changed using the "EditorMarkerSetLocation" command. Applications 110, 112, 114 send AEC 124 via application communications channel 140 the command identifier for EditorMarkerSetLocation and parameters including the handle to the marker, a character string containing the filename in which to move or insert the marker, an integer line number in the file in which to insert the marker, and an integer column number in which to insert the marker. Information manager 164 uses the handle to the marker to identify whether such marker is in the marker list. If a match is found, the previous location of the marker is noted, and editor command assembler 162 assembles a first editor command to remove the marker from the editor. Information manager 164 replaces the old location of the marker with new location of the marker in the marker list and editor command assembler 162 assembles a second editor command to insert the marker in the specified location. In one embodiment, editors 130, 132 require only a single command to adjust the location of the marker. In such embodiment, only this single command is assembled by AEC 124. In another embodiment, AEC must assemble separate commands to delete the old mark and add the new mark as described with the "DeleteMark", "AddMark" and, in one embodiment, "GotoMark" commands, although the Goto-Mark command is not required. The editor command assembler sends via editor communications channel 142 the commands it assembles to the editors 132, 134 associated with the applications 110, 112, 114 as maintained by information manager 162 in the application registration table 123.

In one embodiment, the display of a marker may be suspended by the editor yet retained in the marker lists using a "EditorMarkerDeleteMark" command. Applications 110, 112, 114 send the command identifier via application communications channel 140 to AEC 124 along with a handle to the marker as a parameter. Information manager 164 uses the marker handle to identify the marker in the file and indicate its new status as not displayed. Editor command assembler 162 assembles an editor command to delete the marker from the editor 132, 134 associated with the application which sends the command identifier as maintained by information manager 164 in the application registration table 123.

In one embodiment, editors 132, 134 send information to integrator 120. This information is either status messages or user generated commands. An editor to application communicator, EAC 126 receives and processes these messages.

a. Status Messages

Integrator 120 may receive from editors 132, 134 messages regarding the name and version of an editor 132, 134 coupled to the integrator 120 soon after the editor 132, 134 establishes the connection, and a message from an editor 132, 134 once the editor terminates the connection, usually upon response from a command from the user to terminate the connection. Upon receipt of a termination of connection message, EAC 126 utilizes its own information manager 165 to remove the editor from the editor registration table 121. In one embodiment, if a command is later sent by an application associated with the terminated editor, AEC 124 will restart the editor. In one embodiment, editor 132 is a conventional XEMACS version mm.mm editor running protocol version n, which provides a status messages in the following format:

Integrator 120 may receive information about the presently displayed file from each editor 132, 134. Such information includes whether the file was loaded, unloaded or saved, and whether the file was modified. In one embodiment, information manager 165 modifies this information stored in the file lists 150, 152, 154 as required. The formats of the status messages received from a conventional XEMACS editor are as follows:

to indicate a file was loaded;

to indicate that a file was closed. Contrary to the suggestion of the nomenclature, this message is not generally used to indicate the file was deleted;

to indicate the file was saved; and

to indicate the file has been modified. Integrator 120 uses the information received from the first two messages to determine if a file is opened, and the last two messages to identify files which have been modified but not saved, so as to allow integrator 120 to prompt the user if a file is about to be closed for which integrator 120 has received a "modified" status message without receiving a later "savedFile" message.

b. User-Generated Commands

Integrator 120 receives and process messages received from the editors 132, 134 via editor to application communicator 126. Referring now to FIG. 4A, one embodiment of a method of processing editor messages is shown. Editor messages are received 410 and all editor messages received are broadcast to all applications 412. Each application must parse the message to determine if the message was intended for that application. Referring now to FIG. 4B, another embodiment of a method of processing editor messages is shown. Application names are received, stored and associated with an application corresponding to the application name. A message is received from an editor 420, and the message is parsed to locate an application name 422. The application name is located in the stored application names and the application having the name is identified 424. If an application having the name is identified, a portion or all of the message is sent to the identified application 426.

Referring again to FIG. 1B, in one embodiment, integrator 120 receives user generated commands from editors 132, 134 via editor communications channel 142 and transfers the commands to applications 110, 112, 114 via application communications channels 140. Integrator 120 may optionally translate the commands from the format received from editors 132, 134 to that required by the applications 110, 112, 114, but as is shown below, each editor 132, 134 may be configured to send the user generated commands in the proper format and having the proper content for each application 110, 112, 114.

In one embodiment, editors 132, 134 may be configured by the user to allow short keystroke sequences to send a command to integrator 120. In one embodiment, editor 132 is a conventional XEMACS editor and the following command sequences are entered to the editor to configure the editor to send commands to integrator 120:

In one embodiment, the above sequence is stored into a disk file in directory/home/user1/elisp, in the file ipe.el. The sequence is loaded into the conventional XEMACS editor using the following two XEMACS commands:

Two commands are defined with the sequence above by a conventional XEMACS editor 132. One command sends to the integrator 120 via editor communications channel 142 a character string "build.build" when the F4 keyboard function key is pressed by an XEMACS user. The second command sends to integrator 120 the character string "build.next-error" when the f4 keyboard function key is pressed by a user. This information is parsed by the application 110, 117, 114 in one embodiment, and the integrator 120 in another embodiment as described above. The portion of the string to the left of the period contains information about the application for which the command is intended. The portion of the string to the right of the period describes the action desired by the user.

In one embodiment, EAC 126 accepts some of the user-generated commands and itself performs the desired actions. For example, an open-file command may instruct the integrator 120 to insert a new file in a file list 150, 152, 154 after the editor 132, 134 opens the file upon request by the user using another function key. ##SPC1##