CTRL+C and CTRL+D kill tbp

[John-Robbins]

Right now I'm not handling CTRL+C or CTRL+D at the tbp prompt (tbp:>) or the debug prompt (DEBUG[111]:>). Should I be? What is the best practice for this kind of approach?

In the Python REPL, CTRL+C is reported as a KeyboardInterrupt but does not kill the process, were CTRL+D does.

I should note that I'm already handling CTRL+C and CTRL+D in the INPUT statement.

tbp:>input a
[A]? Error #350: Aborting RUN from INPUT entry.
tbp:>input a
[A]? ^DError #350: Aborting RUN from INPUT entry.
tbp:>

What's the overall plan for these keystrokes? Should INPUT be different like it is now?

[John-Robbins]

I did some thinking and playing with the Python REPL to come up with how I think CTRL+C and CTRL+D should be handled.

Reminder:

• CTRL+C generates a KeyboardInterrupt exception.
• CTRL+D generates a EOFError exception.

Right now my helpers.read_input method is eating both exceptions. That will obviously have to change. These two exceptions need to be handled in Driver.party_like_it_is_1976 where the main prompt loop resides.

The handling will be based on the state of the Interpreter, which will be read by the exception handler in Driver.party_like_it_is_1976. Here's how each state will be handled. See the Interpreter.State enum for the meaning of each state.

LINE_STATE or BREAK_STATE:

• CTRL+C: Nothing (may require a newline, will check)
• CTRL+D: Exit's tbp back to the shell with exit of 1.

RUNNING_STATE:

• Note that this is when executing code or sitting at an INPUT prompt.
• CTRL+C: Call Interpreter.initialize_runtime_state.
• CTRL+D: Call Interpreter.initialize_runtime_state.

FILE_STATE or ERROR_FILE_STATE:

• These states are when loading and parsing files.
• CTRL+C will call Interpreter.initialize_runtime_state and Interpreter.clear_program.

[John-Robbins]

The Plan

• Change helpers.read_input to return a string and not eat the exceptions. Update the callers in Driver and Interpreter.
• Prototype a test where I Monkey Patch helpers.read_input and come up with a way to pump in text and raise the exceptions for full testing.
• Add a current_state property or method to Interpreter that returns the Interpreter.State enum. Remove the Interpreter.at_breakpoint and change callers to use the current_state property.
• Make the changes to the Driver.party_like_it_is_1976 method to do the exception handling outlined in the previous comment.