phil@uxg.cso.uiuc.edu (03/20/89)
I would like to find other versions of EMACS to "play" with. GNUEMACS is already available here. I've tried UniPress "Emacs" and am not interested in that bitter flavor. A previous posting mentions JOVE and ELLE. In particular I'd like to get my hands on a portable C source version of a minimal EMACS, perhaps MicroEmacs. It doesn't have to have any macro capability since I am intersted in hacking the source in C. Any pointers to anon-FTP places? Thanks. --phil
bet@dukeac.UUCP (Bennett Todd) (03/23/89)
In article <2200001@uxg.cso.uiuc.edu> phil@uxg.cso.uiuc.edu writes: > >I would like to find other versions of EMACS to "play" with. GNUEMACS is >already available here. I've tried UniPress "Emacs" and am not interested >in that bitter flavor. A previous posting mentions JOVE and ELLE. > >In particular I'd like to get my hands on a portable C source version of a >minimal EMACS, perhaps MicroEmacs. It doesn't have to have any macro >capability since I am intersted in hacking the source in C. I'd also be interested. All the EMACS-style editors I've seen are big enough to attempt to stand as complete, useful editors on their own two feet. I'd like to have a teeny, tiny editor that could reasonably be dropped into larger programs as a function for acquiring or modifying small chunks of text. For this sort of thing, a featureful, powerful, high-performance system is exactly what you don't want. Rather, simplicity, clear, portable coding, and minimal size are the concerns. Maybe I'll have to write one. Here's what I'd really love to see in an emacs(3): char *emacs(buff, fp, rows, cols, gotoxy) char *buff; /* buffer to be edited, lines separated w/ \n, may be realloc()-ed */ FILE *fp; /* file pointer for terminal I/O */ int rows; /* height of terminal or window */ int cols; /* width of terminal or window */ void (*gotoxy)(int x, int y); /* scoot to x, y */ Any takers? -Bennett bet@orion.mc.duke.edu
daveb@gonzo.UUCP (Dave Brower) (03/24/89)
In article <1307@dukeac.UUCP> bet@orion.mc.duke.edu (Bennett Todd) writes: >Here's what I'd really love to see in an emacs(3): > > char *emacs(buff, fp, rows, cols, gotoxy) > char *buff; /* buffer to be edited, lines separated w/ \n, may be > realloc()-ed */ > FILE *fp; /* file pointer for terminal I/O */ > int rows; /* height of terminal or window */ > int cols; /* width of terminal or window */ > void (*gotoxy)(int x, int y); /* scoot to x, y */ Since you aren't providing a TERM, and it's already going to have to do fileno(fp) games to set the tty modes, then you don't need to provide rows and cols. What is the gotoxy function supposed to do? My god, are you saying that the screen output primitives are 'position cursor' and 'write chars?' Eek! how about: int editbuf( buf, len ) char **buf; int *len; Buf and len are input/output parameters. The function can move the buffer and change the length of what is there. (Real EMACS can edit binaries with embedded '\0' characters, ya know.) The controlling terminal is presumed to be on fd's 0 and 1, which is presumed to be in the "normal" state. The function evaulates TERM as appropriate. This is trivially implemented: /* I didn't compile this, I just typed it in. ** Beware the nearly total lack of error checking! */ int editbuf( buf, len ) char **buf; int *len; { char fn[] = "/tmp/EbXXXXXX"; char cmd[ 80 ]; FILE *fp; struct stat sb; mktemp( fn ); fp = fopen( fn, "w" ); fwrite( *buf, len, 1, fp ); fclose( fp ); sprintf( cmd, "emacs %s\n", fn ); if( system( cmd ) ) /* token error check */ return 1; stat( fn, &sb ); if( sb.st_size > len ) { free( *buf ); *buf = malloc( sb.st_size ); } fp = fopen( fn, "r" ); fread( buf, sb.st_size, 1, fp ); fclose( fp ); *len = sb.st_size; return 0; } Is the :-) really necessary? -dB PS, don't completely laugh it off. On many systems, substituting "mg" or "jove" for "emacs" would be fast enough, preventing you from having to maintain your own editor. -- "I came here for an argument." "Oh. This is getting hit on the head" {sun,mtxinu,amdahl,hoptoad}!rtech!gonzo!daveb daveb@gonzo.uucp
phil@uxg.cso.uiuc.edu (03/24/89)
> I'd also be interested. All the EMACS-style editors I've seen are big enough > to attempt to stand as complete, useful editors on their own two feet. I'd > like to have a teeny, tiny editor that could reasonably be dropped into larger > programs as a function for acquiring or modifying small chunks of text. For > this sort of thing, a featureful, powerful, high-performance system is exactly > what you don't want. Rather, simplicity, clear, portable coding, and minimal > size are the concerns. Maybe I'll have to write one. I may end up writing one. I had ideas similar to this. I wanted to plop it into a terminal program on a micro. When I invoked it on the mainframe, the two would share data changes and I get the instant local response of editing a file on my pc while really applying the changes to the mainframe and minimizing the line traffic as well. But first I just wanted to get a toy emacs to play with and experiment doing source customizing. --phil
jans@tekgvs.LABS.TEK.COM (Jan Steinman) (03/25/89)
<...I'd like to have a teeny, tiny editor that could reasonably be dropped into larger programs as a function for acquiring or modifying small chunks of text...> For a one-line Emacs, look at the ksh clone recently posted to alt.sources by Dave Clemans. It includes a seperable libreader.a, which does the command line editing. I've used an earlier version of this several times -- now if I could only roll it into the tty driver! :::::: Jan Steinman - N7JDB Electronic Systems Laboratory :::::: :::::: jans@tekgvs.LABS.TEK.COM Box 500, MS 50-370 (w)503/627-5881 :::::: :::::: jsteinma@caip.RUTGERS.EDU Beaverton, OR 97077 (h)503/657-7703 ::::::
kgk@cs.brown.edu (03/27/89)
This discussion reminds me of something I've always wondered about. Version 8 or version 9 Unix is supposed to have had some sort of streams mechanism. Does anybody know if it's possible to put an input editor filter over a terminal I/O stream (or dynamically merge input editor capability into an I/O stream, as may be the case)? I guess a quick answer would be ``Why would they develop ksh if they could do that?'', but I'm still curious. Keiji Kanazawa kgk@cs.brown.edu
bet@dukeac.UUCP (Bennett Todd) (03/28/89)
In article <618@gonzo.UUCP> daveb@gonzo.UUCP (Dave Brower) writes: >In article <1307@dukeac.UUCP> bet@orion.mc.duke.edu (Bennett Todd) writes: >>Here's what I'd really love to see in an emacs(3): >> >> char *emacs(buff, fp, rows, cols, gotoxy) >> char *buff; /* buffer to be edited, lines separated w/ \n, may be >> realloc()-ed */ >> FILE *fp; /* file pointer for terminal I/O */ >> int rows; /* height of terminal or window */ >> int cols; /* width of terminal or window */ >> void (*gotoxy)(int x, int y); /* scoot to x, y */ > >Since you aren't providing a TERM, and it's already going to have to do >fileno(fp) games to set the tty modes, then you don't need to provide >rows and cols. What is the gotoxy function supposed to do? My god, are >you saying that the screen output primitives are 'position cursor' and >'write chars?' Eek! I guess I should have said more (or less:-). Yup, the only screen output primatives are 'position cursor' and 'write chars'. I don't care about editing binary files, or multiple files, or any of that; emacs(3) shouldn't put up a status line, it needn't support multiple windows or buffers or file I/O; it is just to allow field data entry for multiple-line free-format text fields using a possibly familiar set of full-screen editing commands. In this context I really don't think performance is an issue, just simplicity. To pop up a separate EMACS to edit the text, you need to either turn over the whole screen, or implement a full pty-based subwindow with screen control. To interface to the above routine all you need to do is set aside a rectangular subset of the screen and implement gotoxy() -- vastly simpler. What I am hoping for here is something slightly more pleasant to type at than fgets(), and little more complicated to add to an application. -Bennett bet@orion.mc.duke.edu
guy@auspex.UUCP (Guy Harris) (03/28/89)
>Version 8 or version 9 Unix is supposed to have had some sort of >streams mechanism. Yes, it did - or does (I don't know if the Tenth Edition of the manual is out yet or not). So does System V Release 3, although it doesn't use streams for all its terminals. SunOS has the S5R3 streams mechanism, and *does* use it for all its terminals. >Does anybody know if it's possible to put an input editor filter over a >terminal I/O stream (or dynamically merge input editor capability into >an I/O stream, as may be the case)? Well, it depends. The standard "tty driver" line disciplines or streams modules *do* include an input editor; it just happens to be an extremely *primitive* input editor, that supports only commands such as "delete last character of line", "delete entire line", and "delete last space-separated token on the line" in some cases. Putting a more powerful editor below that module on a stream makes that editor incapable of using the facilities (input and output mapping of various sorts, for instance) that the "tty driver" module provides; it also means that it would have to know about the existing editor on the module above. Putting it above the "tty driver" module might work better, although it'd have to make sure that module stayed in "uncooked" mode and didn't do its own editing of input. Of course, you can, if you really want, put a fancier input editor into a system that *doesn't* use streams, as long as you have enough information to enable you to write a line discipline to replace the standard one. >I guess a quick answer would be ``Why would they develop ksh if they >could do that?'', Because: 1) there's a lot more to "ksh" than just input line editing; 2) "ksh" works on systems that *don't* support streams; and, perhaps most important, or more germane, 3) putting an editor such as that into the kernel might not be the best idea. The idea "let's make a streams module that does command-line editing" seems to occur to a lot of people when they hear about streams. It sounds great; the down side is that, since streams modules run in the kernel, the editor in question would run in kernel mode, which: 1) puts it in an environment often much less hospitable to it; 2) often requires root privilege to replace the editor; 3) often requires a *reboot* to replace the editor; 4) adds a fair bit of both code and policy to the kernel. Me, I'd prefer to take the current level of editing *out* of the kernel, and *out* of the tty driver, and run some more powerful editor such as EMACS in user mode in its place. A reasonable pseudo-tty mechanism lets you do that; you can even do it with a less-than-wonderful pseudo-tty mechanism such as exists in many contemporary UNIXes - one problem with the current mechanism is that it can't detect "ioctl"s done on the pseudo-tty, so that your editor can't figure out that a program running from the pseudo-tty has turned echoing or input canonicalization off and act appropriately - some systems sort of let you do this, but the mechanism isn't reliable. S5R4's pseudo-tty mechanism will probably fix this.
fischer@iesd.dk (Lars P. Fischer) (03/29/89)
In article <618@gonzo.UUCP> daveb@gonzo.UUCP (Dave Brower) writes: >In article <1307@dukeac.UUCP> bet@orion.mc.duke.edu (Bennett Todd) writes: >>Here's what I'd really love to see in an emacs(3): >> >> char *emacs(buff, fp, rows, cols, gotoxy) >Since you aren't providing a TERM, and it's already going to have to do >fileno(fp) games to set the tty modes, then you don't need to provide >rows and cols. What is the gotoxy function supposed to do? My god, are >you saying that the screen output primitives are 'position cursor' and >'write chars?' Eek! Having the "emacs" function grab the whole screen might not be what you want. Some application might have an emacs in some part of the screen, with other info displayed at the same time. Hence "rows" and "cols". A position (x,y) would also be needed. /Lars -- Lars Fischer, fischer@iesd.dk, {...}!mcvax!iesd!fischer Dept. of Math. and Comp. Sci., University of Aalborg Strandvejen 19, DK-9000 Aalborg, DENMARK Any suffiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke