Date: Tue, 19 Mar 1996 13:30:48 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@sri.MT.net (Nate Williams) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, kuku@gilberto.physik.rwth-aachen.de, jdp@polstra.com, nate@sneezy.sri.com, freebsd-hackers@freebsd.org Subject: Re: GAS question Message-ID: <199603192030.NAA24685@phaeton.artisoft.com> In-Reply-To: <199603192021.NAA04845@rocky.sri.MT.net> from "Nate Williams" at Mar 19, 96 01:21:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > not so much the Emacs command set, per se, as the fact that it's a > > huge memory pig. > > And VC++ isn't? I can run Emacs IDE in a smaller memory footprint than > VC++ if I leave out X. VC++ has a 2-4M footprint... or, actually, "Microsoft Developer Studio" has that footprint. My machine that it's installed on has 16M, but 12 of that is for Windows 95 and the broken VCACHE code for cache utilization backoff (that isn't fixed, even in their most recent update, publically available soon). If I run an FFS FS under Win95 (which I do) and crank the VCACHE parameters down, I can run in 8M. But like GCC, 8M slows the compiles down compared with 16M. > > I guess I could live with unguessable command syntax (how do you > > exit microEmacs, anyway?) if I had printed documentation. Which > > I have for VC++. > > For $150 + shipping, I could print out all of the XEmacs docs for > you. :) No thanks; i'm only interested in the IDE part. I'd like to substitute the editor for "vi" (like I do using the Microsoft tools). Of course, since my FFS on Win95 has my change in it, I get IFSFN_FCNNEXT and IFSFN_FCNCLOSE notifications on my directories, so the IDE knows that I modified the files, and reloads them automatically. 8-). > > Hell, I'd even be willing to pay the same several hundred dollars > > I paid for VC++ just to get a comparable environment with printed > > documentation. > > $VC++ 4.0 is $495 w/out documentation. Docs are another $150 + > shipping, and are now superceded by the pending VC++ 4.1 release. This is retail price. This is not what you pay for an MSDN Level 2 SDK/DDK/VC++ subscription. > Because the development team and OS team are completely separate, and > have completely different release schedules. It makes no sense to have > force the OS development group to rush/delay their release to sync up > with the compiler group. No, but vive-versa makes sense: after all, I really want the compiler that compiled the OS, not some bastard version that might in fact be unable to compile the OS properly (not like anyone tests these things anyway, if the process is decoupled). I've had the "examples" fail to build too many times to thing that decoupling the OS and compiler releases is a good idea from anything but a "marketing to fools" standpoint. > You're arguements against using Emacs apply as well to VC++, so are > moot. Not so. I can click Icon's and menus without having to remember it. Sure, I'll be less productive than someone who knows the command sets inside and out, but I'll be a hell of a lot more productive from the time they drop me in front of the machine until the time I reach parity by learning all the secrets than someone dropped naked in front of Emacs (or vi, or into writing a makefile, for that matter). And the learning curve is the name of the game. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603192030.NAA24685>