[slime-devel] (slime-compilation-finished) doesnt help solving stated goal.

[Helmut Eller]

* Tobias C Rittweiler [2010-10-22 16:24] writes:

> In article <m37hha9w0v.fsf at leonis4.robolove.meer.net>,
>  Madhu <enometh at 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:
>
>   1) 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.
>
>
>   2) 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.
>
>
>   3) 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
> 1) 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