search

peterh / liner

Pure Go line editor with history, inspired by linenoise
MIT License
1.04k stars 132 forks source link

Return from Prompt when Ctrl-C is pressed. #30

Closed michaelmacinnis closed 9 years ago

michaelmacinnis commented 9 years ago

Something like this would enable me to abort parsing multi-line commands when Ctrl-C is pressed.

peterh commented 9 years ago

Thanks for the patch.

To be honest, I don't like it. It makes the common[1] case of "single line input only" more complex, as now you have to check for a new magic error that isn't an "exit my program" error, and add a loop[2].

How fancy does multi-line need to be? What do you think of f2c5329900182a89f8d94e9dfd4a391e81219b2b instead? I was debating having CheckContinuation return input-so-far instead of blindly concatenating inside liner, but I don't know if it's desirable (as I don't have any applications that want to use CheckContinuation).

[1] Common for me, anyway. I haven't done a survey of all the users of liner. [2] In at least one case, the empty line is a valid command and I want Ctrl-C to be a noop.

michaelmacinnis commented 9 years ago

I thought you might say that.

CheckContinuation looks interesting and it may be inevitable that the line editing library I'm using know more about the parsing I'm doing but I'd like to avoid that for as long as possible.

I updated my pull request. What do you think? I think these changes address your concerns. By renaming Prompt to AbortablePrompt (for lack of a better name) and having Prompt call AbortablePrompt in a loop that discards ErrPromptAborted the behavior of Prompt with my changes is identical (I believe) to its behavior without them. By exposing AbortablePrompt I can still use liner and support aborting multi-line commands easily.

peterh commented 9 years ago

Sorry to bikeshed, but "Abort on CtrlC" is really just an option. If we add a new entry point for each option, we'll get a combinatorial explosion of entry points.

What do you think of 88bd68c instead?

peterh commented 9 years ago

...with "end input on ctrlC" and "restartPrompt if ctrlC didn't abort" squashed in. I just noticed that I missed that check.

michaelmacinnis commented 9 years ago

Bikeshed away. It is your library and I see your point.

The only thing that is missing is printing some kind of indication that the prompt has been aborted (most shells print ^C). Rather than ctrlCAborts being a bool, could it be nil if Ctrl-C does not abort and the string to print if Ctrl-C does abort? In my case I would set it to "^C".

peterh commented 9 years ago

I'm thinking about printing "^C" in the normal case anyway (since, as you point out, that's what most shells do), so I'd rather not add that as an additional string. Thoughts on 755a832a77562d01aff6a51584db63fefa4acaf1 and its parent?

michaelmacinnis commented 9 years ago

I think that will work for me. I will get a chance to try it out later tonight. Do you still want to close next on CtrlC when ctrlCAborts is false?

michaelmacinnis commented 9 years ago

Looks good! Thanks.

peterh commented 9 years ago

Thanks for the feedback. I've merged my branch.