* Tobias C Rittweiler [2010-10-22 16:24] writes:
In article m37hha9w0v.fsf@leonis4.robolove.meer.net, Madhu enometh@meer.net wrote:
| | So what are you criticizing? that you need to use C-c C-k or that you | can't be bothered to press y?
I wish to use slime-compile-and-load-file to compile and load and a file. Period. If I just want to load a file, I'd use slime-load-file. If I just wanted to see warnings/errors I'd use `slime-compile-file'.
The short discussion which eventually resulted in the current behaviour can be viewed here:
http://thread.gmane.org/gmane.lisp.slime.devel/9905
So there are at least 3 ways of doing things:
C-c C-k compiles and loads the resulting fasl file unconditionally.
You can compile-only a file (C-c M-k), look at warnings and then explicitly load the file (C-c C-l), too.
This kind of was the original behaviour except it was not entirely clear to me that all backends actually really implement that behaviour.
C-c C-k compiles a file, and loads the resulting fasl IF AND ONLY IF the compilation was successful.
You can then look at warnings, and explicitly load the file via (C-c C-l) as an explicit after step.
C-c C-k compiles a file, and loads the resulting fasl IF AND ONLY IF the compilation was successfull.
If compilation failed, the user is queried if the resulting fasl should be loaded, or not.
That's the current behaviour. Using Y-OR-N-P makes it impossible to look at warnings. Using YES-OR-NO-P would kind of allow for that but would still make it a bit awkward (as you're kind of inside a recursive input loop)
Is that an accurate description?
Another way to say it: 1 and 2 are the same except that 1 uses a non-nil fasl file as success indicator and 2 uses the third return value of COMPILE-FILE. There is also an abort restart to return the current compiler messages to Emacs.
Are there more viable options?
Perhaps variant 0: try to load non-existing fasl files when COMPILE-FILE didn't create one.
For me, it's 2) that sounds most reasonable. I don't like
- because I am totally entrenched in using C-c C-k.
OTOH, 2) might annoy people who're deeply used to the unconditionally loading bit -- in which case 3) is a compromise except it makes looking at warnings somewhat unwieldly.
3 does in fact display the warnings buffer; so if the important warning is (one of) the first there's no need to scroll. And of course it's possible to look at warnings simply by pressing n and use C-c C-l later as in 2.
I also find it surprising that C-c C-c does /not/ do the query bit at the moment. Unconditionally loading is annoying in case you're working with precious image state (running application), and then render your application useless (and lose your state) because you recompiled a crucial function with, say, a typo in it.
In my mind C-c C-c means compile-to-memory without fasl file. The compile-to-temp-file meaning probably also makes sense, but it's not what C-c C-c was originally intended for. It's probably also bit tricky to load a temp-file with C-c C-l.
In these precious-state circumstances I seldomly use C-c C-k in the first place, though, but rather use C-c C-c on a few key parts.
What about you?
Make no typos? Don't write crucial apps? Or more realistically: complain to compiler writers not to create/load fasl files for input with read errors?
Helmut