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

[Helmut Eller]

* Madhu [2010-10-22 11:50] writes:

> * Helmut Eller <m2mxq6buaf.fsf at common-lisp.net> :
> Wrote on Fri, 22 Oct 2010 08:44:56 +0200:
> |> when (slime-compile-and-load-file) notices harmless Warnings during
> |> compilation, it prompts with
> |>   (y-or-n-p "Compilation failed.  Load fasl file anyway? ")
> |>
> |> There is no way for the user to scroll the *slime-compilation* window
> |> to see if the warnings are harmless or not, before he can answer `y'
> |>
> |> I would suggest giving the user an option like like in the appended
> |> patch,
> |
> <snip>
>
> |> and would find it simpler to add a new keymap for this situation,
> |> with new functions to scroll the buffer and also remap [next-line] and
> |> [previous-line] to the new functions so any user level override without
> |> modifying slime.el is impossible.
> |
> | Perhaps not quit that, but it seems that changing y-or-n-p to
> | yes-or-no-p would solve the problem more elegantly than introducing a
> | customization variable.
>
> The tradeoffs aren't that simple for emacs users with experience:
>
> - In the face of (fset 'yes-or-no-p 'y-or-n-p) which saves a few
>   microseconds of developer time.

???  You mean there are people who execute (fset 'yes-or-no-p 'y-or-n-p)?
Whoever does that deserves to lose.

> - Implementations like lw and ccl refuse to find source via
>   M-. (sldb-`v', etc) unless the file is compiled  --- (C-M-x or C-c C-c
>   will not cut it).

That's true for C-M-x but not for C-c C-c.  Both CCL and Lispworks
handle C-c C-c and C-c C-k similarly: in both cases we use COMPILE-FILE
but for C-c C-c we give an extra parameter to say from which file it
came from.

>   So if one wants M-. to work with slime, one is
>   forced to compile that form in a file and load it, even if one knows
>   that large parts of the file contain errors and will not be work or be
>   called.

So what are you criticizing? that you need to use C-c C-k or that you
can't be bothered to press y?

>   Refactoring one's work to a traditional C-style
>   edit-compile-load cycle already hits development speed which lisp's
>   Incremental Development supposedly provides.  Now this `feature' adds
>   another distraction during the "development-cycle", requiring more
>   cognitive processing cycles and time on the part of the developer.
>
> I don't disagree with what you said, but this, (like other features)
> does not pass the cost/benefit.

You mean, pressing y on false positives is more distracting than landing
in the debugger on true positives?  Or what "feature" are you taking
about?

Helmut