The old backspace/delete problem

The old backspace/delete problem

[Boyd Adamson]

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.

The solution I saw was for a ksh user:

alias ^?='stty erase ^?'
alias ^H='stty erase ^H'

The idea is that on login, the user types <backspace><enter>. This
will do one of two things:
1. The character sent by the backspace key will match the current tty
   setting. In this case nothing happens except for a new prompt, or,
2. The character sent by the backspace key does not match the current
   tty setting, the alias is expanded and the tty setting is changed
   to match the terminal emulator.

Now this is nice, but it doesn't help those of use who use a superior
shell, since both ^? and ^H are normally mapped to the same function
(something like backward-delete-char). This is nice in the shell, but
potentially leaves us with a broken backspace key in other command
line programs.

Any ideas on how we could do this sort of auto-detection in zsh? What
about the ability to automatically do the stty stuff the first time we
receive a ^H or ^?, even in the middle of the command? Something like
this:

$ cd /usr/liv<backspace>

causes stty erase <whatever> to be run in the background and then
backward-delete-char - and after that fall back to the normal
behavior.

Any thoughts? Is this just crazy? Or has it been done before?

Boyd

Re: The old backspace/delete problem

[Peter Stephenson]

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.
> 
> The solution I saw was for a ksh user:
> 
> alias ^?='stty erase ^?'
> alias ^H='stty erase ^H'
> 
> The idea is that on login, the user types <backspace><enter>. This
> will do one of two things:
> 1. The character sent by the backspace key will match the current tty
>    setting. In this case nothing happens except for a new prompt, or,
> 2. The character sent by the backspace key does not match the current
>    tty setting, the alias is expanded and the tty setting is changed
>    to match the terminal emulator.
> 
> Now this is nice, but it doesn't help those of use who use a superior
> shell, since both ^? and ^H are normally mapped to the same function
> (something like backward-delete-char). This is nice in the shell, but
> potentially leaves us with a broken backspace key in other command
> line programs.
> 
> 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.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: The old backspace/delete problem

[Bart Schaefer]

On Jan 19,  2:22pm, Peter Stephenson wrote:
} Subject: Re: The old backspace/delete problem
}
} Boyd Adamson wrote:
} > alias ^?='stty erase ^?'
} > alias ^H='stty erase ^H'
} > 
} > 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.

That's a pretty cute trick, Peter.  I think it still runs into problems
with "ttyctl -f", though?

I have this little function in my .zlogin file:

    function stty_backspace {
	local bs
	while (( #bs != 8 && #bs != 127 ))
	do
	    print -n 'Press backspace: '
	    read -k 1 bs || return 1
	    print -nP '\r%E'
	done
	stty erase "$bs"
    }

I invoke that (still in .zlogin) if various other tests for the type
of terminal and host operating system fail to intuit the correct value.
(Those tests are dependent on knowledge of hardware/OSs on my LAN, so
it's not useful to post them here.)

This means that I sometimes get an extra prompt on login, but it also
means that I can be sure to run it before ttyctl.

I like your idea better, though.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: The old backspace/delete problem

[Peter Stephenson]

Bart Schaefer wrote:
> That's a pretty cute trick, Peter.  I think it still runs into problems
> with "ttyctl -f", though?

Yes, you'd need to unfreeze it before the stty to be sure.  I suspect
most users haven't got the tty frozen.

pws


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: The old backspace/delete problem

[Boyd Adamson]

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.

Re: The old backspace/delete problem

[Seth Kurtzberg]

[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]

I have ttyctl -f, not because I'm terribly clever, but because it came 
from a sample somewhere in a zsh distribution.

I do see that stty may not be the best solution in some cases, e.g., 
remote logins may need  ^?, while local logins may need ^h, or v.v.  To 
me it is better to detect the source and use stty.  The function 
solution to me is a bit too brittle.  You can make a reasonable argument 
for either solution.

Peter Stephenson wrote:

>Bart Schaefer wrote:
>  
>
>>That's a pretty cute trick, Peter.  I think it still runs into problems
>>with "ttyctl -f", though?
>>    
>>
>
>Yes, you'd need to unfreeze it before the stty to be sure.  I suspect
>most users haven't got the tty frozen.
>
>pws
>
>
>**********************************************************************
>This email and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom they
>are addressed. If you have received this email in error please notify
>the system manager.
>
>This footnote also confirms that this email message has been swept by
>MIMEsweeper for the presence of computer viruses.
>
>www.mimesweeper.com
>**********************************************************************
>
>
>!DSPAM:41f0a0ef160441761677783!
>
>  
>


[-- Attachment #2: Type: text/html, Size: 1773 bytes --]