Closed jwoertink closed 7 years ago
Ok, update on this. I'm now setting a state on each command added to the command stack. The idea is when catching ^C, I can look at the command stack, and pop off the end all commands that are in a err
state.
The issue I'm running in to now is that unexpected_eof errors don't push to the command stack immediately. So for these ones, I don't know their state. If I push these to the stack, then a lot of other weird things start to happen. I'll keep plugging away.
ICR stucks when I am pressing Ctrl+C
after opening a class:
icr(0.20.5) > class A
icr(0.20.5) > ^C
icr(0.20.5) > ^C
icr(0.20.5) > exit
icr(0.20.5) > quit
icr(0.20.5) > ^C^Z
[5]+ Stopped ---- Ctrl+Z
I get the same result. It's something to do with the Readline library that's causing that. If I switch to using a simple gets
, it's fine. But then we run in to other issues like not being able to use arrow keys and such. I asked in the crystal gittr channel, and the best info I got was something with the Crystal event loop. I have to dig more in to it.
Just wanted to update on this (I haven't ditched it). I found a bug in crystal. Or, at least I'm thinking it's a bug....
I think there's a lot more Readline can do for us in this to make things a lot easier, but Crystal is missing a lot of what the readline lib has.
I would prefer not to implement/merge this. ICR currently is full of tricks and glitches. And this PR only complicates things.
Yeah, I agree. Crystal needs a bit more added to the Readline library to do this properly. I'll close this out for now, and we can touch back on it later.
This PR isn't ready yet, but as an initial start I wanted to get your thoughts and input on some stuff.
Before this, ^C and ^D were caught by the same
process_input
which would just exit the console. Now, ^D will exit (just like IRB), but ^C is caught. The next step will be to create a state, and manage the state of the input. Then using ^C to reset the state to the last known clean state.Related: #33