I'm trying to specify and implement a more fancy "shell integration" protocol. See this draft protocol proposal and a (draft) blog article that discusses (with screenshots) some features and problems. (The latter link also has instructions for trying out the implementation.)
A mostly-working fish script is here. However, I have one problem - how to distinguish two scenarios:
-
The user types ctrl/c during input editing, canceling the command. In that case we want to display the partial input line, followed by ^C, followed by the prompt for the next command.
-
The user resizes the window during input editing. Fish receives a SIGWINCH and repaints the input line(s). In that case we want the terminal to clear out the input area, and replace the current command.
How can I reliably distinguish these cases? In neither case is fish_command_not_found or fish_preexec or fish_postexec called.
I can use heuristics: Did the user type ctrl-c? Did the windows size change? However, this seems ugly and lacks robustness.
I'm trying to specify and implement a more fancy "shell integration" protocol. See this draft protocol proposal and a (draft) blog article that discusses (with screenshots) some features and problems. (The latter link also has instructions for trying out the implementation.)
A mostly-working fish script is here. However, I have one problem - how to distinguish two scenarios:
The user types ctrl/c during input editing, canceling the command. In that case we want to display the partial input line, followed by
^C, followed by the prompt for the next command.The user resizes the window during input editing. Fish receives a SIGWINCH and repaints the input line(s). In that case we want the terminal to clear out the input area, and replace the current command.
How can I reliably distinguish these cases? In neither case is fish_command_not_found or fish_preexec or fish_postexec called.
I can use heuristics: Did the user type ctrl-c? Did the windows size change? However, this seems ugly and lacks robustness.