On Thu, Jul 29, 2004 at 07:13:02AM +0200, Edi Weitz wrote:

Now move point back up until you're behind the closing parentheses and hit the return key. I expected this to move me back to current prompt with "(+ 3 4)" copied there ready to be edited (or evaluated by another return key) but I only get "no input at point."

Did I miss a purposeful change or is this is a bug?

I may have broken this. While fixing some input bugs a while ago, I moved the input property end one character further back (before the newline). This was to fix a bug with multi-line text input -- like with (loop repeat 5 collect (read-from-string)). Before, the lines of input all ran together into one, which led to two problems: * Recalling the lines in the future would get them all, when in fact they were separate inputs. * With no prompt, the input actually seemed to expand with the next line of input, which means that when you hit RET even within the current line, it tried to paste in all of the preceeding lines up to the prompt or something horrible like that instead of sending the current line. Sorry, I'm having a hard time explaining this. :) Anyway, moving the end of the input property before the newline fixed all of the above, but may have broken what you're talking about, Edi. Maybe somebody else has an idea on how to fix it without reintroducing the other behaviors. -bcd

Edi Weitz <edi@agharta.de> writes:

Start a new SLIME and in the REPL enter and evaluate a simple expression like, say, (+ 3 4)

CL-USER> (+ 3 4) 7 CL-USER>

Now move point back up until you're behind the closing parentheses and hit the return key. I expected this to move me back to current prompt with "(+ 3 4)" copied there ready to be edited (or evaluated by another return key) but I only get "no input at point."

Brian and I have fixed this now.