george@rebel.UUCP (George M. Sipe) (07/24/87)
In article <3574@oberon.USC.EDU> blarson@castor.usc.edu (Bob Larson) writes: >In article <384@rebel.UUCP> george@rebel.UUCP (George M. Sipe) writes: >>...quotes my comments from the patch posting > >Are you unaware of MicroGnuEmacs (mg)? mg 1b is available for ftp from >jade.berkeley.edu in pub/mg/mg1b.tar.Z (compressed tar). (mg 1a >appered in mod.sources, and should be avaiable from archive sites.) Mg >is a small, portable, emacs-like (no extention language) editor >designed to act as much as practical like GNU Emacs, and has no direct >association with the GNU project. I am aware of it. In fact, it has been up and running since it was publicly available on the two Unix machines I use. I even liked it. However, when it became necessary for me to use PCs (of the IBM variety) I was surprised to learn that it did not support them. Undaunted, I began doing the port myself (using MSC 4.0). It became clear that a significant amount of work (or at least more than I was interested in doing) would be required so I mailed an inquiry to each author identified in the documentation to see if the port had already been done. It had not, although interest was expressed in having PC support (at least in the only reply I received). This caused me to look for an alternative. What I found was MicroEMACS. Compared to MicroGnuEmacs, it runs on a wider variety of systems including the PC (also including varied monitor support), HAS more features INCLUDING an extension language (I don't consider the lack of one a feature), IS actively supported, with bug fixes and new features (with an emphasis on compile-time selection in order to allow for extra small executables - although with everything included, it is still small and fast). >Mg was based on v30 rather than Laurence's 3.6 because we felt that a >clean, mostly bug-free base was more important than the few additional >features 3.6 offered. (This was the consensus of the short-lived >microemacs mailing list, the major decenting opinion was Dave Laurence. >The original mg autors met via that list.) Since then, mg and >Laurence's microemacs have diverged. > >** Personal opinion, Asbestos suit on ** >From what I have seen about the number of patch versions of Dave >Laurence's microemacs, he still needs better beta testing (does he >have any?) on a wider variety of machines. We did at least 4 beta >distributions of mg before releasing either version. >** normal mode on ** Keep in mind that actively supported (read enhanced) software frequently carries an on-going bug control effort as the price tag. This is not unusual or unreasonable (refer to GNU Emacs, for example). You should express your views here directly to Daniel M. Lawrence. I just use the thing. Perhaps you would be willing to be a beta site. >If you are interested in doing development/support of mg, send a note >to mg-support@ucbvax.berkeley.edu . (Several people have expressed an >interest in having a version for messydos, but so far nobody has >volenteered to do the work.) In my opinion (you are entitled to yours), MicroEMACS a better editor. Furthermore, I hope to allow limited GNU compatibility via a compile time option vs. yet another micro GNU Emacs. I also think the code is cleaner (again, your opinion may differ). Therefore I have abandoned MicroGnuEmacs and will direct all my energies at making MicroEMACS suit my own tastes (and I'll bet many others' too). My only complaint is the lack of compatibility with GNU. For me, it will be compatible enough when the keyboard bindings are generally the same and the function names are generally the same (important when you HAVE an extension language). I've already done 99% of this work (although have yet to post it). I don't demand a proper subset. I think we both want the same thing: a GNU Emacs subset editor for use where the real thing is not possible or where frequent execution is necessary. If GNU Emacs could run on everything and start-up quickly, all my problems would be solved. A micro GNU emacs is a good alternative for those situations. My vote is for MicroEMACS - with my GNU compatibility patches - because (in summary): (1) it operates on more hardware, particularly on the PC, (2) appears to be more widely used, (3) has more features, and (4) has very active support. Since my patches will add a compile-time option and not change the current functionality, Daniel has agreed (in principle) to include them in some future release. I think this is a big plus, in that future enhancements to MicroEMACS will - by definition - be available in it's GNU compatible version. -- George M. Sipe, Phone: (404) 662-1533 Tolerant Systems, 6961 Peachtree Industrial, Norcross, GA 30071 UUCP: ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!rebel!george
jpn@teddy.UUCP (John P. Nelson) (07/24/87)
>In article <3574@oberon.USC.EDU> blarson@castor.usc.edu (Bob Larson) writes: >>Are you unaware of MicroGnuEmacs (mg)? >> In article <838@rebel.UUCP> george@rebel.UUCP (George M. Sipe) writes: >I am aware of it. ... However, when it became necessary for me to >use PCs (of the IBM variety) I was surprised to learn that it did not >support them. I have written a MSDOS version of "mg" for MSC4.0 (mg 1a, the mod.sources version). It uses the bios rather than direct hardware writes (for portability). I implemented all the features that made sense and that were reasonable to implement using bios functions (including ALT key (as META) support, Timeout prompts, function keys, etc). I have sent mail to the mg maintainers, but have not recieved any response as yet. I suppose that either my mail or theirs got eaten. I needed five lines of assembly language to bypass a flaw in the MSC library. My next version of mg will use TurboC, where such hacks are not necessary.
blarson@castor.usc.edu (Bob Larson) (07/25/87)
In article <838@rebel.UUCP> george@rebel.UUCP (George M. Sipe) writes: >In article <3574@oberon.USC.EDU> blarson@castor.usc.edu (Bob Larson) writes: >>Are you unaware of MicroGnuEmacs (mg)? >I am aware of it. In fact, it has been up and running since it was >publicly available on the two Unix machines I use. I even liked it. O.k., I just wanted to be sure you were not doing duplicate effort out of ignorance. >However, when it became necessary for me to use PCs (of the IBM >variety) I was surprised to learn that it did not support them. >Undaunted, I began doing the port myself (using MSC 4.0). It became >clear that a significant amount of work (or at least more than I was >interested in doing) would be required so I mailed an inquiry to each >author identified in the documentation to see if the port had already >been done. It had not, although interest was expressed in having PC >support (at least in the only reply I received). What did you determine was needed besides the (fairly minor) changes documented in systty.mod to the v30 msdos support? >This caused me to look for an alternative. What I found was >MicroEMACS. Compared to MicroGnuEmacs, it runs on a wider variety of >systems including the PC (also including varied monitor support), HAS >more features INCLUDING an extension language (I don't consider the >lack of one a feature), IS actively supported, with bug fixes and new >features (with an emphasis on compile-time selection in order to allow >for extra small executables - although with everything included, it is >still small and fast). I guess you have a different definition of "wider variety" than I do. Last I knew, Laurences microemacs didn't support either os9/68k (other than a commercially available port of 3.6) or primos. Mg 1b includes support of 9 operating systems. Mg is also activly supported. Mg is small and fast. An ms-dos port is now being done. New features are being added to mg. More portions of mg are being made compile-time deselectable so it can run on smaller systems. Don't let the fact that we don't give public distribution to our test versions fool you. I don't consider the fact that Dan Laurence releases his microemacs without testing it on every system "supported" a feature. (I don't consider the lack of an extention language a feature either -- I mentioned it mainly because Richard Stallman made a complaint about the name of MicroGnuEmacs -- It is not associated with the GNU project and is not (by his definition) a "true" emacs.) >Keep in mind that actively supported (read enhanced) software >frequently carries an on-going bug control effort as the price tag. >This is not unusual or unreasonable (refer to GNU Emacs, for example). (GNU activly labels their not-completely tested "beta" versions as such, even if they don't restrict redistribution of them. I still think they have too many versions floating around.) >You should express your views here directly to Daniel M. Lawrence. I >just use the thing. Perhaps you would be willing to be a beta site. Dan Lawrence (appologies for getting his name wrong in my previous message) knows not everyone agrees with him. His attitude, when he was on the microemacs mailing list, was (paraphrased, I didn't save the messages) "I'm going to do things my way, if you don't like it do your own version." >In my opinion (you are entitled to yours), MicroEMACS a better editor. I agree that you are intitled to your opinion. Mg suits my needs better. (I do occasionaly add features, which should be in mg2a.) I don't think keybindings and function names are the only issues in compatability. I've got trouble going between different versions of emacs mainly because of other diffences: which characters ^T twiddles, what can be done one prompt input, etc. Bob Larson Arpa: Blarson@Ecla.Usc.Edu Uucp: {sdcrdcf,seismo!cit-vax}!oberon!castor!blarson "How well do we use our freedom to choose the illusions we create?" -- Timbuk3
aaron@rruxh.UUCP (Akman) (07/25/90)
Does anyone have a startup file for MicroEmacs that makes it look as reasonably like GnuEMACS as possible? -- ----------- Aaron Akman, 201-699-8019, bellcore!rruxh!aaron, RRC 4D-728