Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!bzs From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Message-ID: <23839@bu-cs.BU.EDU> Date: 13 Jul 88 19:51:23 GMT References: <16456@brl-adm.ARPA> <9666@eddie.MIT.EDU> <10443@ulysses.homer.nj.att.com> <9671@eddie.MIT.EDU> Organization: Boston U. Comp. Sci. Lines: 31 In-reply-to: nessus@wonko.MIT.EDU's message of 13 Jul 88 19:08:32 GMT One thing about fancy input line editing: it should probably be either everywhere or nowhere (I distinguish "fancy" only because Unix, particularly BSD, already has some line editing, such as erase-word.) What I don't like about just putting it into a shell is that it then conflicts with habits when using a simple program which just does reads, a human interface issue. I also like the idea that any programmer's program (even a neophyte's own) tends to work more or less as well as the shell on really visible things like input editing. If there's one criticism I have of TOPS-20's fancy input editing it's that it was incredibly baroque for the programmer, and rarely available to the higher level language programmer in any reasonable way (eg. thru the languages' std input methods, like scanf().) It may have been the cat's meow in some's eyes in effects, but it sure wasn't very well thought out in terms of letting (mortal) applications programmers near it, so vanilla applications tended to look kind of klunky and brain-damaged (and that OS had no particular interest in device independance tho one could code anything if they had the patience to run thru enough JSYS's to get the effect they wanted.) I haven't looked at the Unix COMND routines from, I believe, Columbia, perhaps I (we) should. The other question is, if it's done as an intermediate process how does the process know when to step out of the way because a newly started job is doing its own style of input editing? (yes, I'm bracing myself for the answer...) -Barry Shein, Boston University