* Marco Baringer [2007-04-09 18:06+0200] writes:
i'm sorry, but i fail to see how that is possible without having the editor (be it emacs or something embedded in the compiler) tell the compiler what text has been written/edited and what hasn't.
or do you mean we should save all the files and then tell the compiler to re-read them all and infer what needs to be done? if that's what you're saying then i'd still like this feature if just for the emacs buffer listing the changes before the source code (which may or not be valid) is read/compiled.
Yes, I'm saying the compiler, not SLIME, should find changes and figure out what needs to be compiled.
the emacs side of eli keeps track of what files have been modified and passes the original and the new version to allegro who'd then do a smart diff. what i'm suggesting here is a slightly smarter version of that, why bother diff'ing if we can learn what's different as the changes get made?
Because it's more precise and needs less complicated code in Emacs. Why re-implement half of the compiler in Emacs?
As far as I can see, this feature tries to work around slow compilers. Why not fix the compiler instead?
this feature serves two purposes:
make emacs keep track of all the code i've edited since the last compile. even without actually being able to compile the code i find the list-changed-forms buffer very useful. often i'll be working on a single piece of functionality which is speard across multiple files (one file has the db class definition, another the corresponding xml-api implementation and a third has the core code itself) it's a pain to remeber all the pieces i've touched. maybe i've saved the buffers, so i can't just use buffer-modified-p, maybe i haven't saved the buffers, so 'svn stat' doesn't help, maybe i've edited the documentation and i don't care about those files. in this case it really is nice to ask emacs for a list, in a single buffer, of all the lisp forms i've been working on rencently.
being able to order and compile these forms is really just icing on the cake. i could just as well walk down the buffer and hit c on each form to compile them manually in whatever order i want.
That wouldn't work for me because I press C-x C-s and C-c C-c every few seconds anyway.
- work around projects where build times are 20 minutes or more. you can only speed up the compiler so far, some projects are just big and there's nothing you can do about it.
That's what a incremental compiler is for: small changes to big programs can be compiled instantaneously.
now, having said all that there's no way, given an arbitrary set of changed lisp forms and an arbitrary set of existing definitions in the image, to properly infer what order they need to be compiled in without compiling and executing them. this last step is going to error if you get the order wrong, since you have to this to get the ordering right you're screwed in the general case.
That's true, but getting the order right on a per file basis instead on a per form basis doesn't sound very difficult. Most of the time, the order of the files is defined by some kind of Makefile/asdf definition. Instead of tracking forms in the editor, you could give the compiler an (ordered) list of files to watch. If one file changes the compiler could figure out which form changed and recompile only the necessary parts. (This would also allow proper error messages for those parts which haven't changed but are affected by the changes.) Writing such a compiler isn't easy, but adding those feature to the editor is IMO the wrong place.
in practice the 80% solution is helpful, but i'll drop if it seems like bloat.
I think this is bloat. We should instead encourage Lisp implementors to write smarter compilers with proper dependency tracking. Or write a tool to properly analyze CL source code, but I doubt that you want to do that in Emacs Lisp.
A "changed definition" feature like this was discussed here before and at that time we concluded that C-c C-k is fast enough for most purposes.
Helmut.