al@gtx.com (0732) (07/12/88)
Ksh is a wonderful thing, no argument about that, and the best thing
about it is the history/command line editing feature. I can't help
wondering, though, if the shell is the best place for it (the editing
feature). Putting it in the kernel (e.g. stty vi, like stty cooked)
would give a uniform interface to all programs. I know, it is contrary
to the "UNIX Philosophy" to put user interface in the kernel, but that
would be sooo nice and the stty features have been creeping in that
direction anyway.
Alternatively, a library might be provided, like curses, that gave the
user a routine to fetch the next (history-edited) input line. This solution is
more of a pain to the programmer, since he has to look up the calling
sequence, explicitly program it in, etc. and the user can't depend on
it being done uniformly everywhere.
Comments, flames? Anybody done it, meant to do it, thought about it,
rejected it?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
( Alan Filipski, GTX Corp, 8836 N. 23rd Avenue, Phoenix, Arizona 85021, USA )
( {ihnp4,cbosgd,decvax,hplabs,amdahl,nsc}!sun!sunburn!gtx!al (602)870-1696 )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~karl@loquat.cis.ohio-state.edu (Karl Kleinpaste) (07/13/88)
al@gtx.com writes:
[line editing as in ksh is mighty neat, but might be better done
in the kernel, notwithstanding arguments against user interfaces
being implemented there. Alternate suggestion is to create a
library such as curses, but has the drawback of requiring explicit
programming to put it to use.]
Comments, flames? Anybody done it, meant to do it, thought about
it, rejected it?
I did it once. I created a thing called liblinedit.a, which consisted
of a few files which made up my own incarnation of a line editor.
This was the editor which I attached to csh lo these many years ago.
It was written very generally so as to be able to attach it to
anything that wanted to do line-at-a-time input. Due to my inability
to distribute the thing, it never got much exposure outside local
systems where I supported my csh. Paul Placeway (cf. tcsh) has
occasionally made noises about turning the tcsh editor into a linkable
library, but I don't think he's ever actually done it.
It's very doable, not particularly tough, really no big deal once
you've taken care of a few details. Just make sure that it has a
single entry point that looks, feels, and smells like an ordinary
read() call except that it does whizbang things inside. I started
from Ken Greer's tenex stuff originally distributed in October 1984.
It occurs to me that ksh's editing library may even include a way to
build a libedit.a suitable for such usage.
--Karlries@trwrb.UUCP (Marc Ries) (07/14/88)
In article <143@loquat.cis.ohio-state.edu> karl@loquat.cis.ohio-state.edu (Karl Kleinpaste) writes: [al@gtx.com writes: [ [line editing as in ksh is mighty neat, but might be better done [ in the kernel, notwithstanding arguments against user interfaces [ being implemented there. Alternate suggestion is to create a [ library such as curses, but has the drawback of requiring explicit [ programming to put it to use.] [ [I did it once. I created a thing called liblinedit.a, which consisted [of a few files which made up my own incarnation of a line editor. [This was the editor which I attached to csh lo these many years ago. [It was written very generally so as to be able to attach it to [anything that wanted to do line-at-a-time input. Due to my inability [to distribute the thing, it never got much exposure outside local [systems where I supported my csh. Paul Placeway (cf. tcsh) has [occasionally made noises about turning the tcsh editor into a linkable [library, but I don't think he's ever actually done it. [ [It's very doable, not particularly tough, really no big deal once [you've taken care of a few details. Just make sure that it has a [single entry point that looks, feels, and smells like an ordinary [read() call except that it does whizbang things inside. I started [from Ken Greer's tenex stuff originally distributed in October 1984. [It occurs to me that ksh's editing library may even include a way to [build a libedit.a suitable for such usage. [ [--Karl There is a libedit.a make directive in the KSH sources, and the documentation alludes to this ability. However, in my case, I needed the ability to preload the edit-line with a prompt and/or default "to-be-edited" data. I had to modify the actual sources to achieve a stand alone one-line-editor interface (ie, set the defaults up and do a read() to the libedit.a read() routine). The ability to offer vi or emacs modes is icing on the cake. I made the principals (David Korn and P.D. Sullivan) aware of the changes, and was told they would be incorporated into an upcoming release (thanks, guys). -- Marc A. ries@trwrb.TRW.COM sdcrdcf!---\ ihnp4!------\----- trwrb! --- ries
henrik@blblbl.UUCP (Larry DeLuca) (07/14/88)
While it's not going to help the ile people much, it still seems the best place for a line editor of some sort is still the tty driver (ioctl's can be used to set characters or toggle between modes). The most simple line editing commands (rubout, line delete, and co.) are there already, and it is the only way to guarantee that they will be uniformly supported. The major complication, of course, is that this requires intelligence in the tty driver about terminal escape sequences. ITS (Incompatible Time Sharing, developed at MIT) has excellent support in this regard (the tty driver knows how to do operations like clear the screen, and is also aware of what's on the screen at any given time, so can repaint it after a send, for example). larry...
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (07/14/88)
In article <143@loquat.cis.ohio-state.edu>, karl@loquat.UUCP writes: > al@gtx.com writes: > [line editing as in ksh is mighty neat, but might be better done > [...] > > I did it once. I created a thing called liblinedit.a, which consisted > [...] > It occurs to me that ksh's editing library may even include a way to > build a libedit.a suitable for such usage. Yes, it does, and it's used internally at AT&T. In fact something like this was available as a package from The Store!, a free dial-up uucp service for owners of AT&T UNIXPC machines. I'm not sure if this actually taken from the Ksh, or if it was public domain, but stuff like this is out there. Isn't Ksh source is always available from the Tool Chest? BTW, I wrote such a package in college (for vi compatable line editing inside a shell which we were writing [we hadn't heard of the Ksh yet]), and it was pretty straight-forward. -- Christopher J. Calabrese AT&T Bell Laboratories ulysses!cjc
gpasq@picuxa.UUCP (Greg Pasquariello X1190) (07/15/88)
In article <593@blblbl.UUCP> henrik@blblbl.UUCP (Larry DeLuca) writes: > >While it's not going to help the ile people much, it still seems the best >place for a line editor of some sort is still the tty driver (ioctl's >can be used to set characters or toggle between modes). > >The most simple line editing commands (rubout, line delete, and co.) are >there already, and it is the only way to guarantee that they will be >uniformly supported. One of the problems with putting it there is that now every driver must incorporate it. This was one of the problems that SYSV STREAMS solved. Rather than putting it in the driver, put it in a pushable module that can be chosen by the application. I would suggest a well documented interface so that anyone can create their own editors to work with the driver. Now, applications (ergo users) are able to select their own line editing, or no editing, or whatever. -- ========================================================================= Greg Pasquariello AT&T Product Integration Center att!picuxa!gpasq 299 Jefferson Rd, Parsippany, NJ 07054 =========================================================================
fst@mcgp1.UUCP (Skip Tavakkolian) (07/17/88)
al@gtx.com writes: > [line editing as in ksh is mighty neat, but might be better done > in the kernel, notwithstanding arguments against user interfaces > being implemented there. Alternate suggestion is to create a > library such as curses, but has the drawback of requiring explicit > programming to put it to use.] > > Comments, flames? Anybody done it, meant to do it, thought about > it, rejected it? Fortune System's port of the BSD4.X UN*X, which is called For:Pro, can perform a lot of fancy editing on input lines. This would not be apparent to the applications which do not use RAW mode. So far as I can remember, the individual editing functions were requested/installed through specific IOCTL/SGTTY calls. Perhaps some of the people that worked on this could elaborate. Sincerely -- Fariborz ``Skip'' Tavakkolian UUCP ...!uw-beaver!tikal!mcgp1!fst
bvs@light.uucp (Bakul Shah) (07/18/88)
In article <1457@mcgp1.UUCP> fst@mcgp1.UUCP (Skip Tavakkolian) writes: > >Fortune System's port of the BSD4.X UN*X, which is called For:Pro, can perform >a lot of fancy editing on input lines. This would not be apparent to the >applications which do not use RAW mode. So far as I can remember, the >individual editing functions were requested/installed through specific >IOCTL/SGTTY calls. Perhaps some of the people that worked on this could >elaborate. For:Pro is V7 with some 4.1 BSD hacks. And no, it doesn't do input line editing beyond what the 4.1 BSD tty driver did. Fortune added scrolling controls (scroll {page, half page, line}) because the built-in display was much too fast (about 20 KBYTES per second) for reading scrolling text. Once activated these controls can be disabled/enabled from the keyboard. -- Bakul Shah <..!{ucbvax,sun,uunet}!amdcad!light!bvs>
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/29/88)
Terminal input editing belongs where the input is being done, namely the terminal. Rob Pike explained this to us at a USENIX a few years ago; that's how my terminal operates and it works great. Neither the kernel nor the application programs are aware of my editing (which can combine pieces from several windows, typically snarfed with the mouse). Foo on complicating the I/O multiplexor, er, operating system!
jfh@rpp386.UUCP (John F. Haugh II) (07/31/88)
In article <8263@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Terminal input editing belongs where the input is being done, >namely the terminal. absolutely. my favorite terminal is a 3270 running in block mode on an IBM 3090 running CMS. ;-) -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- apologizes to Dennis O'Connor
net@tub.UUCP (Oliver Laumann) (08/01/88)
In article <8263@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > Terminal input editing belongs where the input is being done, > namely the terminal. I don't know if this really the place where it belongs. Consider the line editing function `delete word' (control-w in the Berkeley tty-driver). Ideally, the operation carried out by `delete word' should depend on the type of text being input. For instance, the way it is defined in the Berkeley tty-driver is useful for plain english text, while I would like the character `/' act as a delimiter in addition to white space when typing commands in the shell (so that I can easily correct typos in pathnames), and `-' should be an additional delimiter when I enter Lisp expression in a Lisp interpreter. The terminal does not know what a `word' is. I can't suggest an ideal solution; I just wanted to point out that putting line editing into the terminal is certainly not ideal. In addition, I don't quite understand why the fact that the terminal is the place ``where the input is being done'' is a reason why line editing should be belong there. -- Oliver Laumann net@TUB.BITNET net@tub.UUCP
peter@ficc.UUCP (Peter da Silva) (08/02/88)
First, how the hell does one get mail to gwyn@brl-smoke.ARPA??? In article <8263@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > Terminal input editing belongs where the input is being done, > namely the terminal. How IBM mainframe of you. How about putting file editing in the terminal as well? If you put the smarts in the O/S, then it benefits everyone... including the people on dumb terminals. If you put the smarts in the program, then you can provide selective context (like, why does ksh care about all those ed commands????). There are valid arguments for all these things... why not do all of them? -- Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter. "You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?" "Well, I couldn't afford another deLorean." "But how do you ever get it up to 88 miles per hour????"
davest@sequent.UUCP (Dave Stewart) (08/02/88)
In article <8263@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Terminal input editing belongs where the input is being done, >namely the terminal. I was talking with a coworker once who described how badly this was implemented in VMS. In particular, the tty driver in some version of VMS allows one to move around on the history list, much as one is able to do in ksh, ie, strike a particular character and the previous line typed is displayed. (One might see history manipulation as a form of input editing). One example of where this failed in VMS was that one could run a "lock" program, type a passwd at it, and walk away. Some other user could then walk up, step back in the history and see exactly what password was typed, and then be able to "unlock" the terminal. (I would not be surprised if this same problem is inherent with some of the input line editing programs I have seen lately on the net). I think it is a mistake to make a blanket statement about where input line editing should be done. Some input editing should be closely bound with the applications domain, and some may be allowed some distance. -- David C. Stewart tektronix!sequent!davest Sequent Computer Systems, Inc. davest%sequent.UUCP@tektronix.TEK.COM
gwyn@smoke.ARPA (Doug Gwyn ) (08/02/88)
In article <611@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes: >The terminal does not know what a `word' is. So teach it. If you can't put editing in your terminal, then put it in a stream module as near to your terminal as possible, so it can apply to all processes being operated on the host. It is also probably a good idea not to switch the editing "commands" between applications, since that can get confusing and at least slow down the user (who has to pause briefly to recall what to do). >In addition, I don't quite understand why the fact that the terminal >is the place ``where the input is being done'' is a reason why >line editing should be belong there. To keep lines of communication as short as possible and thereby enhance interactivity. Last Friday, while helping one of the programmers here track down an EXTREMELY obscure bug, I really exploited the dickens out of my 630's ability to support local editing. I estimate that it would have been at least twice as much work to have had to use an ordinary dumb terminal for that debugging session. And I wasn't even in layers (multi-window) mode. (If I had been, I could have tapped into "sam"'s powerful editing command language and saved even more time.)
gwyn@smoke.ARPA (Doug Gwyn ) (08/02/88)
In article <3827@sequent.UUCP> davest@crg2.UUCP (David C. Stewart) writes: -In article <8263@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: ->Terminal input editing belongs where the input is being done, ->namely the terminal. - I was talking with a coworker once who described how badly this -was implemented in VMS. VMS is not a terminal, but in any case the implementation you cited was certainly deficient, whether or not it had been done in a terminal. That doesn't mean that it's a bad idea if properly done.
aegl@root.co.uk (Tony Luck) (08/03/88)
In article <1188@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: > >How IBM mainframe of you. How about putting file editing in the terminal >as well? > Its been done before (sort of) with a micro as the terminal running a screen editor which kept some of the file locally and chatted to a line editor on the main frame to request new lines from the file, and to request the changes. Not too great if you use your screen editor for browsing (as if you jump about the file to different places you keep having to wait for lines of data to be down loaded to the micro). But its terrific for entry of new text as the micro only disturbs the mainframe's slumber once per screen full (or more) of data. -Tony Luck
davest@sequent.UUCP (Dave Stewart) (08/04/88)
In article <8298@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >VMS is not a terminal, but in any case the implementation you cited was >certainly deficient, whether or not it had been done in a terminal. >That doesn't mean that it's a bad idea if properly done. The point is that the VMS terminal driver knows nothing about the application being run, similar to the way a terminal normally doesn't know anything about the application domain. This problem is not particular to the application, but is universal when application-specific actions are taken in a context which is too unlinked from the applications domain. You can certainly fix this characteristic of interaction by giving the terminal special knowledge about the application running, but that sounds like a very non-general approach - there are always new applications which come along. This does not imply that *all* line editing should be linked with the applications domain. For example, one could argue that cut-and-paste between windows is a sort of line editing, and this works fine to have implemented on the terminal. Seems to indicate that some of these functions should be bound to the applications domain, and others need not be. -- David C. Stewart tektronix!sequent!davest Sequent Computer Systems, Inc. davest%sequent.UUCP@tektronix.TEK.COM
fst@mcgp1.UUCP (Skip Tavakkolian) (08/04/88)
In article <8296@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: > In article <611@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes: > >The terminal does not know what a `word' is. > So teach it. I will take this opportune moment to drag this discussion in a new direction. I have been thinking about possible solutions to a similar problem after I heard a keynote speech by Steve Johnson at a Usenix conference a few years ago. He asked what would pipes be (take the place of pipes) in the context of icons. I believe some of that is being answered with the wide acceptance of C++. I also believe it would require another data abstraction, perhaps as widely accepted as the 8-bit-byte, that would have the ability to carry more information about a phenomenon or an entity. Maybe it is time to start thinking about what kind of standard that could be. Sincerely -- Fariborz ``Skip'' Tavakkolian UUCP ...!uw-beaver!tikal!mcgp1!fst UNIX is a registered trademark of AT&T
peter@ficc.UUCP (Peter da Silva) (08/04/88)
In article <3903@sequent.UUCP>, davest@sequent.UUCP (Dave Stewart) writes: > This does not imply that *all* line editing should be linked > with the applications domain. For example, one could argue that > cut-and-paste between windows is a sort of line editing, and this works > fine to have implemented on the terminal. Ideally, though, cut and paste should be done by the application too. The application is the only one that knows what a particular cut object *is*... for example, the thing on your window might really be part of a bitmap image, or it might be part of a CAD drawing. If you cut it as a bitmap (which is all the windowing package knows about), then you lose a lot of detail. If the thing is a section of a musical score or an audio waveform, then that's what should be stuffed into the clipboard or save file or whatever. -- Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter. "You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?" "Well, I couldn't afford another deLorean." "But how do you ever get it up to 88 miles per hour????"
iwm@asun3.ic.ac.uk (Ian Moor) (08/05/88)
In <3827@sequent.UUCP> davest@sequent.UUCP (Dave Stewart) says: >>Terminal input editing belongs where the input is being done, >>namely the terminal. > I was talking with a coworker once who described how badly this >was implemented in VMS. In particular, the tty driver in some version >of VMS allows one to move around on the history list, much as one is >able to do in ksh, ie, strike a particular character and the previous >line typed is displayed. (One might see history manipulation as a form >of input editing). > One example of where this failed in VMS was that one could run >a "lock" program, type a passwd at it, and walk away. Some other user >could then walk up, step back in the history and see exactly what >password was typed, and then be able to "unlock" the terminal. The only way that I can think this might happen is that the lock program did a read with echo followed by a clear-screen instead of a read without echo. (I think lock programs are antisocial and rarely secure.) I think line editing should be as near the front end as possible, we use tcsh with its line editing and I get frustrated when using another program like dbx and not being able to use the same keys to get back previous commands. After all the terminal driver already understands several special keys -- what would life be like if each application had to do its own input editing ? Lets see this is ed so I type ^H, oops its sed I should have used delete ...
peter@ficc.UUCP (Peter da Silva) (08/05/88)
In article <1495@mcgp1.UUCP>, fst@mcgp1.UUCP (Skip Tavakkolian) writes: > He asked what would pipes be (take the place of pipes) in the context > of icons. Pipes should work just fine with icons. Better, even. You should just be able to grab your file, awk, grep, hook them together with rubber band lines, and hit "go". I'm amazed that nobody has implemented this yet. > C++. I also believe it would require another data > abstraction, perhaps as widely accepted as the 8-bit-byte, that would have > the ability to carry more information about a phenomenon or an entity. Why? What are your reasons for deciding pipes are insufficient. What facility is missing with pipes? Am I missing something major here? I don't want to know about sockets and streams. I'm already aware of them. I just don't see why the byte-stream model is suddenly obsolete just because of a graphic user interface. Especially since nobody seems to have even tried to implement graphic pipes. It's not like nobody has thought of them. I brought the subject up about 4 or 5 years ago. Since then I've occasionally seen someone on comp.windows or comp.graphics bring it up... > Maybe it is time to start thinking about what kind of standard that could > be. Places to look: Macintosh clipboards. Amiga IFF files. The IPC discussion on comp.sys.amiga.tech. Smalltalk objects. Macintosh resource files. -- Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter. "You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?" "Well, I couldn't afford another deLorean." "But how do you ever get it up to 88 miles per hour????"
allbery@ncoast.UUCP (Brandon S. Allbery) (08/08/88)
As quoted from <1220@ficc.UUCP> by peter@ficc.UUCP (Peter da Silva): +--------------- | In article <1495@mcgp1.UUCP>, fst@mcgp1.UUCP (Skip Tavakkolian) writes: | > He asked what would pipes be (take the place of pipes) in the context | > of icons. | | Pipes should work just fine with icons. Better, even. You should just be able | to grab your file, awk, grep, hook them together with rubber band lines, | and hit "go". I'm amazed that nobody has implemented this yet. +--------------- See below. +--------------- | > C++. I also believe it would require another data | > abstraction, perhaps as widely accepted as the 8-bit-byte, that would have | > the ability to carry more information about a phenomenon or an entity. | | Why? What are your reasons for deciding pipes are insufficient. What | facility is missing with pipes? Am I missing something major here? +--------------- I think he means he'd like to see a new socket domain which passes packets which would be the equivalent of Macintosh resources (which are what are stored in the clipboard and the scrapbook and even on the system heap, as well as in the resource forks of files). The best one can do with pipes is implement the equivalent of MacBinary protocol on top of them, which is doable but slows things down and makes the code bigger. Besides, if one puts them in the kernel then one can assign *and check* user/group IDs and permissions on resources, allowing programs to pass resources around that they can't access but *can* pass on to something else that can access them, without producing a security problem. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
bpendlet@esunix.UUCP (Bob Pendleton) (08/09/88)
In article <1188@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: > >How IBM mainframe of you. How about putting file editing in the terminal >as well? Anybody remember the UTS400, or UTS4010 terminals for the UNIVAC 1100 series mainframes? They had all sorts of local editing features. Including local files, local printing, on the 4010 a local text editor, and if that wasn't enough you could program them in UTS-Cobol. Why you could declare the screen as a 24x80 array of characters, open the host as a record oriented file and do anything you wanted with characters coming from the keyboard. Now days my terminal is a Sun 3/50 running SunOs 3.4 and X windows. Ile gives me local input line editing, GNU emacs gives me local text editing, NFS lets me open and access files on the host computer, and I can program it in C. Of course some people call it a workstation. Another turn on the wheel of incarnation. Bob P. -- Bob Pendleton @ Evans & Sutherland UUCP Address: {decvax,ucbvax,allegra}!decwrl!esunix!bpendlet Alternate: utah-cs!esunix!bpendlet I am solely responsible for what I say.
kevin%kalli@Sun.COM (Kevin Sheehan (Consulting Poster Child)) (08/09/88)
This may be SunOS specific, but I think it applies to SYSV as well - why not just pop the STREAMS modules in place, and put in your own that does the line editing?? Programs that need cbreak and raw (and by definition do their own editing) will have to have their expectations changed, but ones that just read normally could certainly use any line-editing features just as they do now... l & h, kev
gwyn@smoke.ARPA (Doug Gwyn ) (08/14/88)
In article <12216@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >How about the AT&T 630? (Doesn't the V8/V9 "sam" editor download parts of >itself to the 630?) Yes, in normal use "sam" starts up its terminal part (which handles bitmap display, mouse, and keyboard interaction) as a process running in the terminal, which for a Blit, 5620, or 630 means downloaded code. (The 630 has the ability to restart from its cache after the first download.) The Blit family of terminals frequently uses such a technique, putting the terminal-specific interactive part in the terminal and running a terminal-independent protocol to communicate with the host part. There are typesetter previewer, drawing tools, statistical data viewers, and lots more applications using this technique. A non-downloaded window ("layer") in a Blit descendant typically runs a "dumb CRT" emulator, with built-in mouse-driven cross-window local text editing. (On the 5620, you need to have replaced the firmware terminal emulation by downloading Rob Pike's "mux" or Dave Prosser's "myx" in order to obtain local text editing.) By the way, Rob recently announced that a more recent version of "sam" (than in the "dmd-pgmg" package, which also contains "myx") is going to be made available any day now through the AT&T UNIX System ToolChest. The current version has terminal parts for SunTools, X-Windows, and the Blit descendants; the host part, while not fully portable, runs on Crays, VAXes, Goulds, Alliants, SGI Irises, Suns, 3Bs, et al. Based on usual pricing, "sam" will probably cost only a couple of hundred dollars for unlimited site-wide use (source code provided). If you want to find out more before ordering, beyond whatever write-up the ToolChest provides, read "The Text Editor sam" in Software--Practice and Experience, Vol. 17(11), 813-845 (November 1987). Rob also gave a brief overview in a posting to comp.unix.questions dated July 14, 1988. "sam" is said to be the main editor in use by the Bell Labs computer science research staff, and it has been adopted by several of us at BRL.
peter@ficc.UUCP (Peter da Silva) (08/15/88)
In article <12109@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: > As quoted from <1220@ficc.UUCP> by peter@ficc.UUCP (Peter da Silva): > | In article <1495@mcgp1.UUCP>, fst@mcgp1.UUCP (Skip Tavakkolian) writes: > | > He asked what would pipes be (take the place of pipes) in the context > | > of icons. > | > | Pipes should work just fine with icons. Better, even. You should just be > | able to grab your file, awk, grep, hook them together with rubber band > | lines, and hit "go". I'm amazed that nobody has implemented this yet. > I think he means he'd like to see a new socket domain which passes packets > which would be the equivalent of Macintosh resources (which are what are > stored in the clipboard and the scrapbook and even on the system heap, as > well as in the resource forks of files). OK, what *he's* talking about is interactive cutting and pasting between windows, which really doesn't have anything to do with icons... after all, there are window systems with no icons. What I'm talking about, instead, is what would take the place of pipes in an icon-based UNIX shell. UNIX is not an interactive environment of the same sort as the Macintosh, and communication between programs takes place at a higher level. To put it another way, unlike the Mac, not all UNIX programs are editors. Clipboards, in UNIX, can just be files. UNIX file I/O is very fast and efficient, thanks to some smart buffering. When you clip something, it can just do a regular save to a file named, oh, ~/clip. Make it an environment variable ($CLIPBOARD=~/clip). This way you don't have to duplicate code, and your clipboards are no longer volatile. What's wrong with his picture? > The best one can do with pipes > is implement the equivalent of MacBinary protocol on top of them, which is > doable but slows things down and makes the code bigger. Why does it make the code bigger? Your program presumably has save and restore capability. Just have it save in IFF. -- Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter. "You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?" "Well, I couldn't afford another deLorean." "But how do you ever get it up to 88 miles per hour????"
allbery@ncoast.UUCP (Brandon S. Allbery) (08/20/88)
As quoted from <1259@ficc.UUCP> by peter@ficc.UUCP (Peter da Silva): +--------------- | Clipboards, in UNIX, can just be files. UNIX file I/O is very fast and | efficient, thanks to some smart buffering. When you clip something, it | can just do a regular save to a file named, oh, ~/clip. Make it an | environment variable ($CLIPBOARD=~/clip). This way you don't have to | duplicate code, and your clipboards are no longer volatile. | | What's wrong with his picture? +--------------- The use of a file implies that only one program is running at a time. This is UN*X, though -- all processes in a pipeline run concurrently. ~/clip would be utterly mangled. I still think pipes/sockets are better. The "clipboard" should exist, but it should be more like the Mac "scrapbook" instead. Including the ability to store multiple resources. +--------------- | > The best one can do with pipes | > is implement the equivalent of MacBinary protocol on top of them, which is | > doable but slows things down and makes the code bigger. | | Why does it make the code bigger? Your program presumably has save and | restore capability. Just have it save in IFF. +--------------- Because MacBinary isn't a save/restore protocol, it's something that currently sits on top of Xmodem and Kermit so they can transmit both resources and data without using multiple files. Can IFF handle CODE resources? I can put one into the Clipboard with ResEdit. Most other Mac programs don't toss machine code around, though -- but imagine an interactive linker under Unix which allowed you to link in subroutines through the clipboard as well as from files. And it could be done dynamically as well, if the resources were handled similarly to shared libraries. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
nate@mipos2.intel.com (Nate Hess) (08/25/88)
In article <4676@rpp386.UUCP>, jfh@rpp386 (John F. Haugh II) writes: >absolutely. my favorite terminal is a 3270 running in block mode on >an IBM 3090 running CMS. ;-) I'd take this over any terminal attached to VMS, though... :-|# --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes ..!{decwrl|hplabs!oliveb|pur-ee|qantel|amd}!intelca!mipos3!nate