* Helmut Eller m2mxq6buaf.fsf@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