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

[Madhu]

* 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.

- 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). 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.  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.

--
Madhu