Bulletin number: 380 Products affected: D7205A Description: Standard reply to suggestions about F Component: F editor Date: Wed Mar 11 14:43:15 GMT 1992 ----- F editor and the TDS Julian Wilson Jan 14, 1992 1. Introduction This note is intended to be an introduction to the folding editor F. F is based on, and is strongly influenced by, the INMOS Transputer Development System, the TDS. The TDS is a fully integrated development environment for writing software for transputers and has been succesfully used since 1985. The TDS introduced a number of concepts and imposed a number of constraints which resulted in a highly partisan acceptance - i.e. people either loved it or hated it. F takes the well-received concepts from the TDS without imposing the same constraints. The major concept retained is that of folding. Folding, as described later on in this document, is a mechanism which allows as much detail of a file to be concealed or revealed as desired. Users of folding editors find that they are able to focus attention on critical areas of development in a way not possible in a conventional 'flat' editor. An interesting side-effect of this is that folding users gradually rely less and less on paper listings of programs until they cease to use paper altogether. This introduction, however, is not meant to be an introduction to folding, rather an insight into the motives which governed the development of F and hence some suggestions for using F in the most efficient manner. Apart from the TDS, F has hardly been influenced by the design of any other editor which is why features taken for granted in a normal editor may be quite different in F or may not exist at all. The editor is designed at its core level to be simple to use with a minimum number of magic keys. As a user becomes more familiar with the editor, additional features can be used until she has the working set which suits him most. Inmos software tools use a keyboard mapping file to map functions onto keystrokes so that the tools are written in a terminal and system independent manner. F retains and slightly extends this concept. F is expected to be used in three different work environments; firstly, a user who has personalised the interface to the editor, secondly, a user logging into a system wide facility which uses a standardised interface to the editor and thirdly, a user who uses a system-wide facility but wishes to have some degree of personalisation. To acomodate these three modes F assumes default names of information files which can be superceded at a number of levels. The primary information file is the ITERM file which controls the key mappings. The ITERM file can be used to reference an F startup file which controls how F interprets folds in the file being read. The startup file could be system-wide but a user may wish to extend the fold marker set chosen and so can override the refence to the startup file by defining an environment variable to point at a file of his own choosing. The startup file references the name of a command history file. The command history file is opened at the start of an editing session. By default it contains a list of executable commands - commands which operate on files rather than editing commands which operate inside a file. If the command history file is kept as a global reference from a standard startup file it would not be edited by an individual user. The command file can, however, be a reference to a local file in which a user can retain a list of commands that she issues on a regular basis in that environment. For example, a list of all the source files in a particular directory along with a backup command and a call to a make file could be retained in a command history file. The editor is intended to be consistent so that all commands behave in the same manner in all environments. Because of current implementation restrictions, it may be that this is not always the case. These restrictions will be removed as the editor develops. An example of this consistency is shown in the handling of the command file and the help file which both can be navigated using the normal editing facilities. Because the command history file is no different from any other file, all commands which can be obeyed from the command history file can also be obeyed from within a normal text file being edited. As a consequence opening additional files and interacting with the host system can be done with a minimum of keystrokes and special states. Ten keystroke macros are provided to allow users to retain functions which are done regularly between editing sessions. A good example is a replacement for the [MAKE COMMENT] key of the TDS which was used to hide a complete fold from the compiler. Mechanisms for doing this in a language independent manner are not obvious, so a user can implement it as a keystroke sequence which is suitable for his language and attach the sequence to a macro key. Such a sequence might be [START OF LINE][-][-][DOWN] for occam. Future work on the editor will be towards removing inconsistencies and generalising concepts already included. One area of activity will be the search/replace mechanisms which will allow regular expression parsing, multiple file etc. Other features which may be included are an editing mode which allows character overwrite rather than insert, and full [PICK], [COPY PICK], [PUT] facilities for characters as well as lines. Modern editors often have windowing capabilities built in and allow different windows to show different views of the same file. F assumes that a windowing environment will always provide more sophistcated facilities than could be incorporated into the editor and thus provides only the mechanism to switch between files. On a folding editor, multiple positions in a single file are undesirable because the view of the file depends on the state of lines within the file (for example one view could close a fold containing the current position of another view). As a final note it is worth highlighting those areas where f differs from the TDS and some other folding editors and try and justify these differences. The first difference people notice is the absence of filed folds. Filed folds provide a mechanism for navigating between files in a structured hierarchical manner. The ability to file a fold, however, is really provided so that the editor does not have to open huge files when the software is structured as a single monolithic component. This form of software structure was common in the TDS because of its poor cross referencing facilities and is not necessarily suitable for languages other than occam. Where more conventional development systems are employed, software is often better structured into a collection of more loosely connected smaller files which have advantages in compilation speed and file size. If these files cross-reference each other it is quite an inconvenience to have a single point of contact between them as is provided by filed folds. The mechanism provided by f allows the user to have both files open at the point of interest. An additional argument against filed folds is the desire not to have 'magic' markers in the file but leave the text as plain as possible. A second function ex-TDS users request is the [COMMENT] fold. This was provided in the TDS by marking a fold as a special type which would be ignored by the compiler. It is not clear how an equivalent system could be added to f which works for all languages and all development systems. Non-TDS users using f as their first folding editor tend to have a different wish list which is based on the editing paradigm employed by the editor they are familiar with. A typical example of this is the 'mark these areas and then apply this function' editing style. F is line-based and basically all facilities which might be applied to portions of multiple lines conflict with the editor's view of a file especially when a visibly adjacent part of the screen may be hundreds of lines apart in the file. Requests have been received for a simple mechanism for jumping to marked points in any file. This is a nice idea but, because f provides very powerful mechanisms for moving large amounts of data about, both within a file and between files, keeping track of the marks may prove costly. F recognises a large number of keys (68) in spite of the desire to keep the editor simple. As a consequence of this large number, requests which would require more keys are examined very carefully to see if the facilities can be provided by generalising the function of existing keys.