Re: The old backspace/delete problem

[Boyd Adamson <boyd-adamson@usa.net>]

Peter Stephenson <pws@csr.com> writes:

> Boyd Adamson wrote:
>> Someone recently mentioned to me a solution to the old "backspace key
>> sends ^? or ^H" problem that I hadn't heard of, and I thought we here
>> in zsh land might be able to improve on it.
>> [snip]
>> Any ideas on how we could do this sort of auto-detection in zsh?
>
> It's doable; there's a slight catch, but I think I've managed to make it
> almost invisible to the user.  Here's the code first:
>
>
> backward-delete-char-detect() {
>   if (( #KEYS == ##\C-? )); then
>     zmodload -i zsh/sched
>     sched +00:00 "stty erase '^?'"
>   elif (( #KEYS == ##\C-h )); then
>     zmodload -i zsh/sched
>     sched +00:00 "stty erase '^h'"
>   fi
>
>   zle -A .$WIDGET $WIDGET
>   zle .$WIDGET
> }
> zle -N backward-delete-char backward-delete-char-detect
> zle -N vi-backward-delete-char backward-delete-char-detect
>
>
> This code will run the function backward-delete-char-detect the first
> time you type a key bound to backward-delete-char.  If that's either ^?
> or ^h, it will record the fact.  Then it will restore the original
> version of backward-delete-char and perform the normal operation.
>
> The unpleasantness is that we can't run stty inside the editor widget,
> since the terminal setup is explicitly restored on exit from zle and any
> change is lost.  So instead we use "sched" to schedule the stty to run
> immediately, which in practice is the next time the command line is
> executed.  This does seem to work, but the effect consequently isn't
> instantaneous; the first command that runs immediately after you've
> deleted a character doesn't yet have the character remapped, because the
> "sched" event is only examined when control returns to the shell after
> that command.
>
> Alternatively, you could split the stty into the preexec function, but
> then it becomes messier.

Nice work! A great little feature.