Fix read1 and readln in the ui.listener
#2778
Conversation
|
I've now fixed |
|
Progress:
|
|
Well, that required a lot more re-writing than I expected. But, I think it should all be done. The only part I'm not confident about is the change to It's behavior in the CLI Listener is to read each line as one quote. However, it's behavior in the UI Listener is to read all lines then evaluate them. So, I had to implement a means to check which mode Another reason I'm not fully happy with these changes is... : set-from-listener? ( -- ? )
get-callstack callstack>array second \ listener-step = ; inline...reading the call stack feels about as leaky as abstractions can get. |
|
This PR seems to completely break As for |
|
Typically contents are ended with Ctrl-D for EOFOn Aug 20, 2023, at 1:18 PM, Aleksander Sabak ***@***.***> wrote:
This PR seems to completely break read-contents on the interactor, which in all fairness makes it somewhat consistent with the cli listener. It doesn't react to the enter key alone (newlines can still be inserted with shift+enter), and there doesn't seem to be a way to end the input.
As for readln: the input is removed from display after enter is pressed if more input is requested.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
These changes should fix
read1andreadlnin the UI Listener. I've added specializedinteractor-read*-finishandinteractor-read*words to handle the actual behavior orread1andreadln. This should leave any word that depends on existing implementation ofinteractor-readunchanged.Marking this as draft as I have to make changes to
readas well. Currently,n read n read ...exhibits the same bug. Should be able to apply the same fix, but I need to take a break for today. Feel free to offer feedback.