Re: Colored-character displayed on CTRL-C ?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 23,  3:00pm, Phil Pennock wrote:
} Subject: Re: Colored-character displayed on CTRL-C ?
}
} On 2013-09-23 at 13:02 -0700, Bart Schaefer wrote:
} > This should do it for you:
} > 
} >     autoload -Uz colors
} >     colors
} >     handle-interrupt() {
} >       print -n "$bg_bold[yellow]${(V)KEYS:-^C}$reset_color"
} >       zle -I && zle .kill-buffer
} >     }
} >     zle -N handle-interrupt
} >     TRAPINT() { zle && zle handle-interrupt }
} 
} This seems to interact poorly with vared

Hm, I wondered about that.  You can change the zle line in handle-interrupt
to read

    zle -I && zle .kill-buffer && zle .send-break

and maybe get better behavior that way.

} Also, in bck-i-search (^R) the prompt is re-shown,
} and the mode is still in bck-i-search (although the current selected
} value is blanked out, but typing continues the search).

I think send-break will help there, too, but in case not:

} It seems that handling these requires the TRAPINT to return non-zero,
} but doing so interacts with the widget above to double-prompt (badly).

You can check for [[ $CONTEXT == vared ]] in the TRAPINT function and
return nonzero when appropriate.  (It'll normally be unset outside of
ZLE.)

} Ideally, I'd be able to set $? after this, so a manual invocation of
} precmd would correct the prompt variables, since precmd() isn't invoked
} normally, given that widget, whereas it is with a straight Ctrl-C
} without TRAPINT (albeit with $? set to 1).

"zle .send-break" sets the internal error flags so normally it's just
like invoking "return 1" ... but you can use an "always" block to get
around that.