RFC569 - NETED: A Common Editor for the ARPA Network

Network Working Group                                   Mike PadlipskyRFC569/ NET-USING Memo 1                                    NET-USINGNIC # 18972                                           October 15, 1973             NETED: A Common Editor for the ARPA NetworkBACKGROUNDAt the recent Resource Sharing Workshop, there was a somewhatsurPRising degree of consensus on what I had anticipated would theleast popular aspect of the my "Unified User-Level Protocol" proposal:A number of the attendees agreed without argument that it would bea good thing to have "the same" context editor available on allServers -- where "the same" refers, of course, to the user interface.We even agreed that "NETED" seemed to be a plausible common name.  Inview of the fact that the rest of the proposal didn't seem to captureanybody's imagination, though, it seemed to be a useful notion toseparate out the common editor and make it the subject of astand-alone proposal.My resolve to come up with the following was further strengthened atthe the organizing meeting of the Network User Interest Group, whichfollowed the Workshop.  Being primarily concerned with user issues,this group was downright enthusiastic about the prospect of a commoneditor.  Indeed, this proposal has been reviewed by the group and isendorsed by it.REASONSThe need for a common editor might well be obvious to many readers.They are encouraged to skip this section, which is for the benefit ofthose who don't already see the light.In the first place, it's almost axiomatic that to use a time-sharingsystem, you have to be able to create files (/"datasets"/"segments").Even if you're only using the Network to send "mail", you'd still liketo be able to create a file separately, so as to be able to edit itbefore sending.  And if you want to write a program -- or even make a"runoff" source file -- you simply must be able to use some editorcommand on the system at hand.Unfortunately, there are even more editors than there are systems;and each one has it own conventions and peculiarities.  So "Networkusers" (who use several Servers, as opposed to those who use theNetwork only to access a particular system all the time) are facedwith the unpleasant chore of developing several sets of incompatiblereflexes if they want to get along.  This can certainly be done.  Ithas been by a number of members of the Network Working Group.NETED SPEC                                                        p.2The real kicker, however, comes when we consider the needs of thoseusers -- who are coming into the Network community in ever-increasingnumbers -- who are not professional programmers.  They just want toget some work done, "on the Net" (that is, irrespective of which
                         Operating system they might be talking to).  They are likely to beappalled rather than amused by having to learn a dozen ways of gettingto first base.  Therefore, it seems clear than not only do we need acommon editor, but we also need a simple common editor.CHOICESSimplicity is not the only criterion for rejecting the apparently"obvious" choice of either TECO or QED.  (That it is a strong factoris indicated by the old test of "Consider eXPlaining it to a naivesecretary -- now consider explaining it to a corporation president.")Perhaps even worse is the problem of "dialects".  That is, featuresvary across implementations, and settling on a common set of features(or dialect) is likely to be a very hard task, for programmers tend toget very fond of their familiar goodies.  Besides, both TECO and QEDhave their own strong (/fanatic) advocates, who's probably never bewilling to settle for the other one.  Further, not every system hasboth, and implementing the other is a fairly large job even if the NWGcould agree on which (and how mUCh).At any rate, the difficulties seem overwhelming when it comes tochoosing a high-powered editor as the common editor.  Therefore, Itried to think of a nice low-powered editor, and it suddenly occurredto me that I not only knew of one, but it was even fairly welldocumented (!).  The editor in question is known on Multics as "eds"(the same member of the "ed" family of editors which started onCTSS), a line-oriented context editor (no "regular expressions", butalso no line numbers).  It is used as an extended example ofprogramming in the Multics environment in Chapter 4 of the MulticsProgrammers' Manual, which gives an annotated PL/I listing of theactual working program.  It is simple to learn and should be quiteeasy to implement,  PL/I version serves as a detailed model with onlyequivalent system calls and choice of language to worry about.  I urgeits adoption as the common Network editor, to be known on allparticipating Servers as "NETED" and/or "neted".DOCUMENTATIONIn view of the fact that if "eds"/NETED is adopted only perhaps adozen members of the NWG will actually have to implement one, it seemswasteful to distributed some 30 pages of the MPM to everyone --especially since most of the parties concerned have access to an MPMalready.  (Another problem solved by not including it here is that ofwhether I'd be violating copyright by doing so.)  The exact referenceis pp. 24-54 of Chapter 4 of Part I of the Multics Programmer'sManual.NETED SPEC                                                        p. 3Anybody who needs a copy can let me know.  Although the emphasis inthe document is, naturally enough, on the Multics-specific aspects, I
                         believe that the listing is clear enough to serve as a model toimplementors without any great difficulty.  If we do get to theimplementation stage, I'll be glad to try to explain any non-obvioussystem calls, either individually or in a follow-up memo.  But eventhough we "initiate" where you "open", or we " call los_$read_ptr"where you "IOT TTY" (or something), it shouldn't cause much trouble.For that matter, some implementers might prefer to ignore the existingprogram and simply work from the function specifications (below).LIMITATIONSIt became abundantly clear during the course of the review of thisdocument by the User Interest Group that the limitations of NETED mustbe acknowledged (even insisted upon) and explained here.  In the firstplace, it must be emphasized that it is not being proposed as "THE"Network editor.  Rather, it is an insistently simple-minded editor fortwo major reasons:  1) it is meant for use mainly by non-professionalprogrammers, and 2) more important still, it is meant to be extremelyeasy to implement.  Therefore, it seems far more important to go withthe published program, with all its warts, than to specify theaddition of new, undebugged features.  The idea is to make itimplementable in man-days by an average to average-plus programmerinstead of in man-weeks by a superstar programmer.In the second place, the very act of adding new features is fraughtwith peril.  To take some examples from the comments I received duringthe review phase:  In the first draft, I inadvertently failed todocument the mechanism by which the ability to "go backwards" (i.e.,to reverse the direction of the current-line pointer described below)is actuated.  Several reviewers argued strongly for the inclusion ofsuch a mechanism; but, not knowing it was already "in" the code Iargued -- successfully -- for leaving it out, on the grounds that weshould stick to what's in the existing code, which is known to work aspublished.  Even what to call such a new request would have beendebatable -- should it be "-" and become the only non-alphabetic name?should it be "b" for "bottom"?  should "n" (for "next") become "+"?And so on.  Although this particular issue turned out be a falsealarm, I've left it in to emphasize the sort of pitfalls we can getinto by haggling over particular "features".  Another familiar featureis some sort of "read" request so that the file name need not bespecified as an argument to the command.  Then, of course, one wouldalso want a "create" or "make" request.  And perhaps a file deleterequest?  It keeps going on and on.  The point, I think, is that if weallow ourselves to go into "tinker mode" we could spend as many yearsstriving to achieve consensus on what features to add as we've spenton Telnet or FTP ... and still not please everyone.  Therefore, I urge
                         the NWG to accept the contention that having a working model to use asNETED SPEC                                                     p. 4a pattern is more  important than any particular additional features(even  though I myself find "=" for "what's the current line'snumber?" annoying to live without).RESPONSESFor the benefit of those who don't want to plow through the functionalspec, this seems to be a good spot to indicate what appropriateresponses to this proposal would be.  Ideally, I'd like to hear from aresponsible system programmer at, say, TENEX, CCN, UCSD, UCSB,AMES-67, one of the DEC 10/50 Hosts, and from any of the experimentalServers who happen to be interested, that they think it's a fine ideaand why don't I log in next week to try their NETEDs.  Next mostdesirable would be agreement in principle followed by specificinquiries about "eds".  I would hope that haggling over specificfeatures wouldn't occur (as we're not trying to do a definitiveeditor, just an easy, commonly implemented one based on an existingimplementation), but unfortunately I can't legislate such haggles outof existence.  At the very least, I'd hope to either hear or seereasoned arguments why it's not worth doing.  As usual, phone, mail"mail" ("map.cn" in sndmsg, or "map cn" in "mail" on Multics) or RFC'sare the assumed media for responding.USAGE(The following is intended to serve double-duty, as both a functionalspec now and -- with the addition of some examples -- a "users'manual" later.  So if it seems to "tutorial", I'm sorry.  And if itdoesn't seem tutorial enough -- assuming the addition of examples --please let me know.)As is typical of "context editors," the NETED command is used both forcreating new files and for altering already existing files -- where"files" are named collections of character encoded data in the storagehierarchy of a time-sharing system.  Consequently, NETED operates intwo distinct "modes" -- called "input mode" and "edit mode".When NETED is used to create a file (that is, when it is invoked fromcommand level with an argument which specifies the name of a filewhich does not already exist in the user's "working Directory"), it isautomatically in input mode.  It will announce this fact by outputtinga message along the lines of "File soandso not found.  Input."  Untilyou take explicit action to leave input mode, everything you type willgo into the specified file.  (Actually, it goes into a "working copy"of the file, and into the real file only when you indicate a desire tohave that happen.) To leave input mode, type a line consisting of onlya period and the appropriate new-line character:  ".<NL>", where <NL>is whatever it takes to cause a Telnet New-Line to be generated fromyour terminalNETED SPEC                                                        p. 5
                         After leaving input mode, you are in edit mode.  Here, you may issuevarious "requests" which will allow you to alter the contents of the(working) file, re-enter input mode if you wish, and eventually causethe file to be stored.  Note that edit mode is entered automaticallyif the argument you supplied to NETED specified an existing file.Regardless of how it was entered, being in edit mode is confirmed byNETED's outputting a message of the form "Edit".  Editing is performedrelative to (conceptual) pointer which specifies the current line, andmany requests pertain to either moving the pointer or changing thecontents of the current line.  (When edit mode is entered from inputmode, the pointer is at the last line input; when entered from commandlevel, the pointer is at the "top" of the file.)NETED's edit mode requests follow, in order intended to be helpful.Two important reminders:  the requests may only be issued from editmode, and each one "is a line" (i.e., terminates in a new line /carriage return / linefeed is appropriate to the User Telnet beingemployed).  SYNTAX NOTE:  If the request takes an argument, there mustbe at least one space (blank) between request's name and the argument.1.  n mFor unsigned m, the n(ext) request causes the pointer to be moved"down" m lines.  If m is negative, the pointer is moved "up" m lines.If m is not specified, the pointer is moved one line.  If the end ofthe file is reached, an "End of file reached by n m" message is outputby NETED; the pointer is left "after" the last line.2.  l stringThe l(ocate) request causes the pointer to be moved to the net linecontaining the character string "string" (which may contain blanks);the line is output.  If no match is found, a message of the form "Endof file reached by l string" will be output (and the pointer willhave returned to the top of the file).  The search will not wraparound the end of the file; however, if the string was above thestarting position of the pointer, a repetition of the locate requestwill find it, in view of the fact that the pointer would have beenmoved to the top of the file.  To find any occurrence of the string --rather than the next occurrence -- it is necessary to move the pointerto the top of the file before doing the locate (see followingrequest).3.  tMove the pointer to the top of the file.NETED SPEC                                                       p. 64.  bMove the pointer to the bottom of the file and enter input mode.5.  "."Leave the pointer where it is and enter input mode.  (First new linegoes after current old line.)6.  i stringThe i(nsert) request cause a line consisting of string (which willprobably contain blanks) to be inserted after the current line.  Thepointer is moved to the new line.  Edit mode is not left.7.  r stringThe r(eplace) request causes a line consisting of string (probablycontaining blanks) to replace the current line.
                         8.  p mThe p(rint) request causes the current line and the succeeding m - ilines to be output.  If m is not specified, only the current line willbe output.  End of file considerations are the same as with "n".9.  c /s1/s2/ m gThe c(hange) request is quite powerful, although perhaps a bit complexto new users.  In the line being pointed at, the string of characterss1 is replaced by the string of characters s2.  If s1 is void, s2 willbe inserted at the beginning of the line; if s2 is void, s1 will bedeleted from the line.  Any character not appearing within eithercharacter string may be used in place of the slash (/) as a delimiter.If a number, m, is present, the request will affect m lines, startingwith the one being pointed at.  All lines in which a change was madeare printed.  The pointer is left at the last line scanned.  If theletter "g" is absent (after the final delimiter) only the firstoccurrence of s1 within a line will be changed.  If "g" (for "global")is present, all occurrences of s1 within a line will be changed.  (Ifs1 is void, "g" has no effect.)  NOTE WELL:  blanks in both stringsare significant and must be counted exactly.  End of fileconsiderations are the same as with "n".10.  d mThe d(elete) request causes m lines, including the current one, to bedeleted from the working copy of the file.  If m is not specified, onlythe current line is deleted.  The pointer is left at a null line abovethe first undeleted line.  End of file considerations are the same aswith "n".NETED                                                           p. 711.  wWrite out the working copy into the storage hierarchy but remain inNETED.  (Useful for those who fear crashes and don't want to lose allthe work performed.)12.  saveWrite out the working copy into the storage hierarchy and exit fromNETED.Additional specs:a.  On Multics, type-ahead is permitted.  This approach is recommendedfor all versions of NETED, but is of course not required as variousServers' NCP Implementations may prohibit it; however:b.  If an error is detected, the offending line is output, and pendingtypeahead (if any) must be discarded (to guard against the possibilityof the pending request's being predicated on the success of erroneousrequest).c.  The command is not reinvokable, in the sense that work is lost ifyou "quit" out of it via the Telnet Interrupt Process command or itsequivalent; indeed, quitting out is the general method of negatinglarge amounts of incorrect work and retaining the original fileintact.(When the time comes, I'll be glad to furnish examples for the users'manual version; but for now, that's all there is.)NOTEIt really does work, unsophisticated though it may be.  I think thatit's sufficient to get new users going, and necessary to give them afighting chance.  It would even be of utility within the NWG, forthose of us who don't like having to learn new editors all the time.
                         If anybody wants to try it, I'll make a version available to"anonymous users" (see the Multics section in the Resource Notebook ifyou don't already know how to get in our sampling account), under thename "neted".  (*) (If you do try it, please delete files when donewith them.)______________(*)  Knowledgeable Multics users with their own accounts can insteadlink to >udd>cn>map>neted.  It is also there under the names "eds" ifyou want to save typing a couple of characters.