* Madhu [2010-10-22 11:50] writes:
- 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.
??? 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