If an s-expr involves multiple-lines (ie. the s-expr is incomplete and RET is typed), Lisp enters the debugger with an EOF error during READ. I observe this problem with both CMUCL and Allegro.
The SLIME info for 'REPL commands' says:
`RET' `slime-repl-return' Evaluate the current input in Lisp if it is complete. If incomplete, open a new line and indent. If a prefix argument is given then the input is evaluated without checking for completeness.
Lynn Quam quam@ai.sri.com writes:
If an s-expr involves multiple-lines (ie. the s-expr is incomplete and RET is typed), Lisp enters the debugger with an EOF error during READ. I observe this problem with both CMUCL and Allegro.
Hmm.. do you mean, you get the error when you send an incomplete expression via C-u RET? In that case, I think entering the debugger is a reasonable response. (RET without prefix argument shouldn't send incomplete expressions.)
Or are you suggesting we should catch reader errors or something else? If so, please give an example of the input and the preferred response.
Helmut.
Helmut Eller replied:
Lynn Quam quam@ai.sri.com writes:
If an s-expr involves multiple-lines (ie. the s-expr is incomplete and RET is typed), Lisp enters the debugger with an EOF error during READ. I observe this problem with both CMUCL and Allegro.
Hmm.. do you mean, you get the error when you send an incomplete expression via C-u RET? In that case, I think entering the debugger is a reasonable response. (RET without prefix argument shouldn't send incomplete expressions.)
Or are you suggesting we should catch reader errors or something else? If so, please give an example of the input and the preferred response.
Helmut.
The problem is with slime-repl-return (RET) , not with C-u RET. I narrowed down the problem further: It occurs with input starting with single-quote and back-quote characters, but not with input starting with optional white-space followed by left-paren.
Looking at slime.el, the problem appears to be in slime-input-complete-p. (looking-at "\s *(") is probably the wrong regular-expression for inputs starting with single-quote and back-quote characters.
Lynn Quam quam@ai.sri.com writes:
Looking at slime.el, the problem appears to be in slime-input-complete-p. (looking-at "\s *(") is probably the wrong regular-expression for inputs starting with single-quote and back-quote characters.
Yes, that's the problem. I changed the regexp to "\s *[`'#]?(". Not sure if something smarter is needed but C-j can always be used as to force indentation.
Helmut.
I think the following change to the regular-expression in (looking-at ...) fixes the problem:
(defun slime-input-complete-p (start end) "Return t if the region from START to END contains a complete sexp." (save-excursion (goto-char start) (cond ((looking-at "\s *\((\|`\|'\|"\)") (ignore-errors (save-restriction (narrow-to-region start end) ;; Keep stepping over blanks and sexps until the end of ;; buffer is reached or an error occurs. Tolerate extra ;; close parens. (loop do (skip-chars-forward " \t\r\n)") until (eobp) do (forward-sexp)) t))) (t t))))
This permits inputs starting with optional whitespace followed by one of ( ` ' " (left-paren, back-quote, single-quote, double-quote). There are probably some other constructs that should be handled too, such as inputs starting with sharpsign reader macros.
-
Helmut Eller -
Lynn Quam