Where should the type information be: in tags and descriptors 470

Nick Maclaren are would not (Sorry Nick, I'll get to your point later. I'm really replying to two separate but related items here.)

Actually, the 3270 interface was an *obstacle* to doing the above well. The benefits you list are due to the combination of three things: (1) A full-screen display, (2) a clear concept of current position, and (3) program access to (2) sufficient to write reliable procedures, i.e. knowing the context of operations, and whether they succeeded or failed. Most modern text editors have (1), fewer have (2), and even fewer have (3). The reason the 3270 was an obstacle is because it was unable to implement (1) properly: it was ok for separate display (write-only, though still limited in its code sets) and input (a dedicated "input area", with all its limitations), but would suffer from intractable bizarreness when used in full-screen input mode, because the program did not have access to the sequence of keystrokes that had generated the modified screen image. Oh, it works well in simple common cases, which is why editors like Xedit work reasonably well in practice. As a programmer it bothered me, however, because I couldn't get it to the the right thing in all cases, or even notice that the wrong thing happened.

Actually, item (2), current location, needs two components: a location in the object being edited (including which is the current object among several), and the location of a user-controlled pointer on the visible screen -- plus means for a macro to translate between the two, or notice that no mapping exists. On a real 3270 the second capability was usually awkward, but an emulated 3270 often permits the mouse to be used effectively to provide this function.

Btw, at Research we tried to overcome the limitations of the 3270 by taking advantage of the fact that, by the late 1980s, most real 3270s had been replaced by terminal emulators. A colleague of mine (Paul Kosinski) took full advantage of this with a modified version of the Multiplexed Yorktown Terminal Emulator (Myte -- I hope I remembered the words behind the acronym), in an alternative version of the experimental OS that I'm still running. At that time I was working on other things, and stuck with the more primitive separate input area (except when I have access to a full-duplex keyboard interface, as I had on the 37T -- in that case he job *can* be done right).

Well, there is a generic DO edit macro whose argument string is interpreted as if the whole thing was an in-line Rexx program, entered on the fly to do simple repebreastive tasks. It is also quite easy to edit a new macro, then use it right away -- no need to "link" it into the editor in some way.

There's a fourth feature of editors that I have come to see as indispensable: a full-function and general multi-level UNDO mechanism. Xedit sadly lacks that. Emacs has it for the content of its "buffers" (basically individually edited files). The editor I use has UNDO for the editor's state as a whole, which includes settings, and can undo ALL effects of a macro executed as one unit, even if the macro changed settings, or involved multiple files (e.g. move this from here to there), and this is a qualitative step beyond what Emacs offers. It basically makes mistakes very easy to recover from, which is particularly important if one programs "on the fly". I've gotten so used to this that I tell my editor to treat any invalid command as input at the current location, so that I never have to enter an explicit "input" mode distinct from "command" mode. Emacs users use syntactic means to distinguish commands from input; Xedit uses explicit modes; Vi uses a mishmash of both, and so do I -- but with the important distinction that if a string intended as input happens to match an obscure but valid command, I can recover with a single keystroke (a PF key that invokes a macro to undo the last command, retrieve the string from the history log, and insert it as input). Yes, I know I am exposed to commands that have external side-effects (e.g. CP LOGOFF) -- but I keep those few in number so I can remain aware of them.

Michel.