CST305 System software
MODULE 6
Text Editors and Debuggers
Text Editors : Overview of Editing, User Interface, Editor Structure.
Debuggers : Debugging Functions and Capabilities, Relationship with other parts of the system, Debugging
Methods- By Induction, Deduction and Backtracking.
An Interactive text editor has become an important part of almost any computing environment. Text
editor acts as a primary interface to the computer for all type of ―knowledge workers‖ as they compose,
organize, study, and manipulate computer-based information.
An interactive debugging system provides programmers with facilities that aid in testing and
debugging of programs. Many such systems are available during these days. Our discussion is broad in
scope, giving the overview of interactive debugging systems – not specific to any particular existing system.
I.
Text Editors
A text editor allows you to edit a text file (create, modify etc…). For example the Interactive text editors
on Windows OS - Notepad, WordPad, Microsoft Word, and text editors on UNIX OS - vi, emacs , jed, pico.
Normally, the common editing features associated with text editors are, Moving the cursor, Deleting,
Replacing, Pasting, Searching, Searching and replacing, Saving and loading, and, Miscellaneous(e.g.
quitting).
1. Over view of editing
An interactive editor is a computer program that allows a user to create and revise a target
document. Document includes objects such as computer diagrams, text, equations tables, diagrams, line
art, and photographs. In text editors, character strings are the primary elements of the target text.
Document-editing process in an interactive user-computer dialogue has four tasks:
i.
Select the part of the target document to be viewed and manipulated
ii.
Determine how to format this view on-line and how to display it
iii.
Specify and execute operations that modify the target document
iv.
Update the view appropriately
The above task involves traveling, filtering and formatting. Editing phase involves – insert,
delete, replace, move, copy, cut, paste, etc…
Traveling – locate the area of interest
Filtering - extracting the relevant subset
Formatting – visible representation on a display screen
There are two types of editors. Manuscript-oriented editor and program oriented editors.
Manuscript-oriented editor is associated with characters, words, lines, sentences and paragraphs.
Dept. of CSE, AISAT
Page 1
CST305 System software
Program-oriented editors are associated with identifiers, keywords, statements. User wish – what he
wants – formatted.
2. User interface
The user of an interactive editor is presented with a conceptual model of the editing system.
Conceptual model of the editing system provides an easily understood abstraction of the target document
and its elements, with a set of guidelines describing the effects of operations on these elements. Besides
the conceptual model, the user interface is concerned with the input devices, the output devices and the
interactive language of the system.
i.
Input Devices
The input devices are used to enter elements of text being edited, to enter commands, and to
designate editable elements. These devices, as used with editors, can be divided into three categories:
a. Text Devices
Text or string devices are typically typewriter-like keyboards on which a user presses
and releases keys, sending a unique code for each key. All current computer keyboards are of the
QWERTY variety. Several alternative keyboard arrangements have been proposed, however
none of these seems to be widely accepted in the near future because of the retraining effort that
would be required.
b. Button Devices
Button or choice devices generate an interrupt or set a system flag, usually causing
invocation of an application-program action. Such devices typically include a set of special
function keys on an alpha numeric keyboard or on the display itself.
c. Locator Devices
Locator devices are two-dimensional analog-to-digital converters that position a cursor
symbol on the screen by observing the user’s movement of the device. The most common such
devices for editing applications are the mouse and the data tablet. The data tablet is a flat,
rectangular, electromagnetically sensitive panel. Text devices with arrow keys can be used to
simulate locator devices.
ii.
Output Devices
The output device lets the user view the elements being edited and the results of editing
process. The first output devices were tele-typewriters and other character printing terminals that
generated output on paper. Next glass teletypes based on CRT technology used the CRT screen
to simulate a hard-copy tele-typewriter. Modern personal computers support multiple
proportionally spaced character fonts to produce realistic facsimiles of hard-copy documents.
Thus the user can see the document portrayed essentially as it will look when printed on paper.
Dept. of CSE, AISAT
Page 2
CST305 System software
iii.
Interaction language
The interaction language of a text editor is generally one of several common types. The
typing-oriented or text-command oriented method is the oldest of the major editor interfaces.
The user communicates with the editor by typing text strings both for command names and for
operands. Typed specification often requires the user to remember the exact form of all
commands. The function key interface addresses this deficiency. Here each command has
associated with it a marked key on the user’s keyboard.
Typing oriented systems require familiarity with the system and language, as well as
some expertise in typing. Function key oriented systems often have either too few keys, requiring
multiple-keystroke commands, or have too many unique keys, which results in an unwieldy
keyboard.
The menu-oriented user interface is an attempt to address these problems. A menu is a
multiple-choice set of text strings or icons, which are graphic symbols that represent objects or
operations. The user can perform actions by selecting items from the menu.
3. Editor structure
Most text editors have a structure similar to that shown in the following figure.
Command language Processor accepts command, uses semantic routines – performs functions
such as editing and viewing. The semantic routines involve traveling, editing, viewing and display
functions.
Dept. of CSE, AISAT
Page 3
CST305 System software








Editing operations are specified explicitly by the user and display operations are specified
implicitly by the editor. Traveling and viewing operations may be invoked either explicitly by the
user or implicitly by the editing operations.
In editing a document, the start of the area to be edited is determined by the current editing
pointer maintained by the editing component. Editing component is a collection of modules
dealing with editing tasks. Current editing pointer can be set or reset due to next paragraph, next
screen, cut paragraph, paste paragraph etc..,.
When editing command is issued, editing component invokes the editing filter – generates a new
editing buffer – contains part of the document to be edited from current editing pointer. Filtering
and editing may be interleaved, with no explicit editor buffer being created.
In viewing a document, the start of the area to be viewed is determined by the current viewing
pointer maintained by the viewing component. Viewing component is a collection of modules
responsible for determining the next view. Current viewing pointer can be set or reset as a result of
previous editing operation.
When display needs to be updated, viewing component invokes the viewing filter – generates a
new viewing buffer – contains part of the document to be viewed from current viewing pointer. In
case of line editors – viewing buffer may contain the current line, Screen editors - viewing buffer
contains a rectangular cutout of the quarter plane of the text.
Viewing buffer is then passed to the display component of the editor, which produces a display by
mapping the buffer to a rectangular subset of the screen – called a window.
The components of the editor deal with a user document on two levels: In main memory and in
the disk file system. Loading an entire document into main memory may be infeasible – only part
is loaded – demand paging is used – uses editor paging routines.
Documents may not be stored sequentially as a string of characters. It uses separate editor data
structure that allows addition, deletion, and modification with a minimum of I/O and character
movement.
4. Case study : VI Editor
There are a number of different UNIX file editors that you can use to create and modify files.
Although not always the easiest to learn, the vi editor is one of the most versatile. The default editor that
comes with the UNIX operating system is called vi (visual editor).
While using vi, at any one time you are in one of three modes of operation. These modes are
known as "command mode," "insert mode," and "last line mode."
When you start up vi, you are in "command mode." This mode allows you to use certain
commands to edit files or to change to other modes. For example, typing "x" while in command mode
deletes the character underneath the cursor. The arrow keys move the cursor around the file which you're
editing. Generally, the commands used in command mode are one or two characters long.
Dept. of CSE, AISAT
Page 4
CST305 System software
You may actually insert or edit text within "insert mode." When using vi, you'll probably spend
most of your time within this mode. You start insert mode by using a command such as "i" (for "insert")
from command mode. While in insert mode, you are inserting text into the document from you current
cursor location. To end insert mode and return to command mode, press ESC key.
"Last line mode" is a special mode used to give certain extended commands to vi. While typing
these commands, they appear on the last line of the screen (hence the name). For example, when you
type ":" from the command mode, you jump into the last line line mode, and can use commands such as
"wq" (to write the file and quit vi), or "q!" (to quit vi without saving changes). Last line mode is
generally used for vi commands which are longer than one character. In last line mode, you enter a
single-line command and press ENTER key to execute it.
To create or edit a file:
vi [filename]
$ vi test
vi opens the file you specify in filename unless it does not exist. If the file does not exist, vi
opens a new file which will be called filename.
II.
Debuggers
An interactive debugging system provides programmers with facilities that aid in testing and
debugging of programs. Many such systems are available during these days. Our discussion is broad in
scope, giving the overview of interactive debugging systems – not specific to any particular existing
system.
1. Debugging Functions and Capabilities
One important requirement of any IDS is the observation and control of the flow of program
execution. Setting break points – execution is suspended, use debugging commands to analyze the
progress of the program, résumé execution of the program. Setting some conditional expressions,
evaluated during the debugging session, program execution is suspended, when conditions are met,
analysis is made, later execution is resumed.
A Debugging system should also provide functions such as tracing and trace back.
 Tracing can be used to track the flow of execution logic and data modifications. The
control flow can be traced at different levels of detail – procedure, branch, individual
instruction, and so on…
 Trace back can show the path by which the current statement in the program was
reached. It can also show which statements have modified a given variable or
parameter. The statements are displayed rather than as hexadecimal displacements
Dept. of CSE, AISAT
Page 5
CST305 System software
Program-Display capabilities
A debugger should have good program-display capabilities.
 Program being debugged should be displayed completely with statement numbers.
 The program may be displayed as originally written or with macro expansion.
 Keeping track of any changes made to the programs during the debugging session.
Support for symbolically displaying or modifying the contents of any of the variables and
constants in the program. Resume execution – after these changes.
To provide these functions, a debugger should consider the language in which the program being
debugged is written. A single debugger – many programming languages – language independent. The
debugger- a specific programming language– language dependent. The debugger must be sensitive to
the specific language being debugged.
2. Relationship with other parts of the system
The important requirement for an interactive debugger is that it always be available. Must appear
as part of the run-time environment and an integral part of the system.




When an error is discovered, immediate debugging must be possible. The debugger must
communicate and cooperate with other operating system components such as interactive
subsystems .
Debugging is more important at production time than it is at application-development time.
When an application fails during a production run, work dependent on that application stops.
The debugger must also exist in a way that is consistent with the security and integrity
components of the system.
The debugger must coordinate its activities with those of existing and future language
compilers and interpreters
User-Interface Criteria:







Debugging systems should be simple in its organization and familiar in its language, closely
reflect common user tasks.
The simple organization contribute greatly to ease of training and ease of use.
The user interaction should make use of full-screen displays and windowing-systems as much
as possible.
With menus and full-screen editors, the user has far less information to enter and remember.
There should be complete functional equivalence between commands and menus – user where
unable to use full-screen debugging systems may use commands.
The command language should have a clear, logical and simple syntax.
command formats should be as flexible as possible.
Any good debugging systems should have an on-line HELP facility. HELP should be
accessible from any state of the debugging session.
Dept. of CSE, AISAT
Page 6
CST305 System software
3. Debugging Methods
3.1. By induction
It should be obvious that careful thought will find most errors without the debugger even going
near the computer. One particular thought process is induction, where you move from the particulars of
a situation to the whole. That is, start with the clues (the symptoms of the error, possibly the results of
one or more test cases) and look for relationships among the clues. The induction process is illustrated in
Figure
i.
ii.
iii.
iv.
v.
The steps are as follows:
Locate the pertinent data. A major mistake debuggers make is failing to take account of all
available data or symptoms about the problem. The first step is the enumeration of all you
know about what the program did correctly and what it did incorrectly
Organize the data. Remember that induction implies that you‘re processing from the
particulars to the general, so the second step is to structure the pertinent data to let you observe
the patterns.
Devise a hypothesis. Next, study the relationships among the clues and devise, using the
patterns that might be visible in the structure of the clues, one or more hypotheses about the
cause of the error.
Prove the hypothesis. A major mistake at this point, given the pressures under which
debugging usually is performed, is skipping this step and jumping to conclusions to fix the
problem. However, it is vital to prove the reasonableness of the hypothesis before you proceed.
If you skip this step, you‘ll probably succeed in correcting only the problem symptom, not the
problem itself.
Fix the Error. If hypothesis is proved successfully then go on to fix the error else repeat steps 3
and 4
Dept. of CSE, AISAT
Page 7
CST305 System software
3.2. By Deduction
The process of deduction proceeds from some general theories or premises, using the processes
of elimination and refinement, to arrive at a conclusion (the location of the error). See the
Figure
i.
ii.
iii.
iv.
The steps are as follows:
Enumerate the possible causes or hypotheses. The first step is to develop a list of all
conceivable causes of the error. They don‘t have to be complete explanations; they are merely
theories to help you structure and analyze the available data.
Use the data to eliminate possible causes. Carefully examine all of the data, particularly by
looking for contradictions, and try to eliminate all but one of the possible causes. If all are
eliminated, you need more data through additional test cases to devise new theories.
Refine the remaining hypothesis. The possible cause at this point might be correct, but it is
unlikely to be specific enough to pinpoint the error. Hence, the next step is to use the available
clues to refine the theory.
Prove the remaining hypothesis. This vital step is identical to step 4 in the induction method.
3.3. By Backtracking

An effective method for locating errors in small programs is to backtrack the incorrect
results through the logic of the program until you find the point where the logic went
astray.
In other words, start at the point where the program gives the incorrect result—such as where
incorrect data were printed. At this point you deduce from the observed output what the values of the
program‘s variables must have been.
Dept. of CSE, AISAT
Page 8
CST305 System software
By performing a mental reverse execution of the program from this point and repeatedly using
the process of ―if this was the state of the program at this point, then this must have been the state of
the program up here,‖ you can quickly pinpoint the error.
Debugging By Testing
 Test cases for debugging: purpose is to provide information useful in locating a suspected
error.
 This method is used in conjunction with the induction method
Debugging By Brute Force
 Requires little thought
 Inefficient and generally unsuccessful.
Can be partitioned into three categories:
 Debugging with a storage dump
 Debugging according to the common suggestion to ―scatterprint statements throughout the
program‖
 Debugging with automated debugging tools
4. Case study : gdb
The GNU Debugger, usually called just GDB and named gdb as an executable file, is the
standard debugger for the GNU operating system. However, its use is not strictly limited to the GNU
operating system; it is a portable debugger that runs on many Unix-like systems and works for
many programming languages, including Ada, C, C++, Objective-C,Free Pascal, Fortran, Java and
partially others. gdb is free software, protected by the gnu General Public License (GPL).
gdb can do four main kinds of things (plus other things in support of these) to help you catch bugs in the
act:




Start your program, specifying anything that might affect its behavior.
Make your program stop on specified conditions.
Examine what has happened, when your program has stopped.
Change things in your program, so you can experiment with correcting the effects of one bug
and go on to learn about another.
Getting In and Out of GDB


type ‘gdb’ to start gdb.
type ‘quit’ or \Ctrl-d’ to exit.
Invoke gdb by running the program gdb. Once started, gdb reads commands from the terminal until you
tell it to exit.
Dept. of CSE, AISAT
Page 9
CST305 System software
Questions
Part A ( 3 Marks )
1.
2.
3.
4.
5.
6.
7.
8.
9.
What are the different tasks of document editing process? (Nov 2013)
What is user interface? (May 2013)
Give an overview of text editor.
Steps involved in document editing.
Explain Interaction language used in text editing.
What is debugging ?
Various debugging functions and capabilities.
Explain debugging by induction.
Explain Debugging by deduction.
Part B ( 5 Marks)
1.
2.
3.
4.
5.
6.
7.
Write notes on user interface. (Nov 2013)
Explain debugging functions. (May 2013)
Difference between travelling and filtering.
What does the conceptual model of the editing system represent?
Difference between tracing and trace-back?
Explain the dependency between the language being debugged and the debugging system.
Does optimization affect debugging?
Part C (12 Marks)
1.
2.
3.
4.
5.
6.
7.
Explain the different debugging methods in detail. (Nov 2013)
Explain editor structure in detail with neat figures. (Nov 2013)
Explain different debugging methods in detail. (May 2013)
Give the uses of user interface and with diagram explain the editor structure (May 2013)
Explain Editor Structure with the help of a diagram.
Explain editing process and the dependency between viewing and editing buffer .
What is Debugging ? Explain different types of debugging methods.
Dept. of CSE, AISAT
Page 10