* David Korn <[email protected]> [2012-01-17 23:01]: > cc: [email protected] > Subject: Re: Re: Re: [ast-users] Ksh93 quivalence of Vim mapping `inoremap jj > <ESC>'? > -------- > > > That is a pretty nice hack which solves the original poster's > > problem. However, it seems limited to key combinations which > > result in printable characters without special meaning to the > > shell editor that can be removed from .sh.edtext via backspace. > > So it is e.g. not possible to bind "^Uj" in emacs mode to an > > action with this method because the "^U" has side effects on > > .sh.edtext. This is actually relevant when one tries to handle > > character sequences emitted by terminal emulators like xterm > > for certain keys or key combinations like Home, End, Ctrl+Left > > etc. Handling such arbitrary character sequences would > > necessitate the use of a temporary buffer which can hold an > > incomplete, ambiguous character sequence without side effects. > > E.g. in order to bind the sequence "^Uj" to a certain action the > > "^U" would need to be stored in the temporary buffer until the > > next key is pressed and it becomes unambiguous whether the action > > associated to "^Uj" can should be executed or the "^U" can be > > passed to .sh.edchar. Basically this is the approach I've been > > using for a while to bind arbitrary character sequences to > > actions (see the attached script). What's missing here is the > > ability to have a timeout after which the contents of the > > temporary buffer are appended to .sh.edtext mostly because > > .sh.edtext is only accessible from within a KEYBD trap. > > More generally it would be nice if there was an easier way in ksh > > to edit keybindings. > > -- > > Guido Berhoerster > > > > With a few changes I should be able to add a timeout to a future > ksh93 release. > > You should be able to do something like the follwing when ^U arrives: > if read -n1 -t.5 c && [[ $c == j ]] > then # process ^Uj > else .sh.edtext=^U$c > fi > for a half second timeout after the ^U is entered. > > This doesn't work now, but I think that can modify read so that > it works in a future release.
That would be nice. The only issue I see with it is that read echoes the received character and thus messes up the input line, would it be possible to add an option to the read builtin to prevent that (e.g. like the "-s" option of the bash read builtin) without having to fiddle with stty? -- Guido Berhoerster _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
