From xemacs-m  Mon Jun 16 14:02:52 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id OAA24895;
	Mon, 16 Jun 1997 14:02:51 -0500 (CDT)
Received: from Corp.Sun.COM ([129.145.35.78]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA15627; Mon, 16 Jun 1997 12:23:38 -0700
Received: from legba.Corp.Sun.COM by Corp.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA16721; Mon, 16 Jun 1997 12:02:16 -0700
Received: by legba.Corp.Sun.COM (SMI-8.6/SMI-SVR4)
	id MAA15575; Mon, 16 Jun 1997 12:02:16 -0700
To: Steve Baur <steve@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: C-h/backspace/etc
X-Attribution: GDF
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Gary.Foster@Corp.Sun.COM (Gary D. Foster)
Date: 16 Jun 1997 12:02:16 -0700
Message-ID: <bcilo4as75z.fsf@corp.Sun.COM>
Lines: 67
X-Mailer: Gnus v5.4.56/XEmacs 20.3(beta6) - "Moscow"

Steve,

While it's true that C-h generates a help binding in tty mode, this is 
because C-h is still bound to help, and not bound to
'backward-delete-char or -untabify or whatever.  I personally think
that the correct way to fix this is not by ripping out all the del/bs
stuff (which fixes a completely different problem) but instead to
remove the binding of c-h to help and bind it to 'backward-delete-char 
or whatever.  I *think* (after re-reading your problem description)
that this is probably what you're running in to.  I'd be willing to
bet a doughnut that the only time you get the spurious help functions
in the minibuffer are in tty mode.  Am I correct?

Here's the quick and dirty rundown:

DEL needs to either delete backwards or forwards.
The backspace key needs to either erase backwards or generate help.

This could be fixed a couple of ways:

1) get the backspace key to not generate c-h in tty mode
	* fat chance... this isn't likely
2) ignore the setting of DEL in tty mode and always erase backwards
	* This would work, but might confuse people who explicitly
	  expect it to erase forwards.
	* However, doing this would sort of be in line with the way we 
	  handle X-mode... if they don't have a backspace keysym we
	  try and protect them by always making DEL erase backwards no 
	  matter what.
	* We already do the opposite in tty mode, though, and
	  allow them to shoot themselves in the foot.  This is
	  not optimal behavior.  This also doesn't fix the "c-h is
	  backspace in tty" problem either, though.
3) globally bind C-h to 'backward-delete-char in tty mode.  We could
   do this a couple of different ways:
	* hard bind it in all cases with a global-set-key and rely on
	  M-h generating help instead of C-h from now on.
	* Only bind it in tty mode by wrappering the help function and 
	  calling backward-delete-whatever if in tty mode.
4) only bind C-h to 'backward-delete-char in prim/minibuf.el and leave 
   the global bindings alone.
	* This is probably the quickest and easiest fix but it is also 
	  one of the least complete ones and still leaves a lot of
	  things unsolved.

It all boils down to the fact that both the 'backspace' and 'delete'
keysyms are being used for dual purposes.  We're expecting DEL to
either erase backwards or forwards and we're expecting backspace to
either generate help (which is stupid in my opinion) or erase
backwards.  Personally, the only way I see to completely solving the
HELP issue is to either get backspace to not generate a C-h
(hah... yeah... and I'll take the winning lottery numbers too, please) 
or get C-h to quit generating a help event.  We can code around it,
but it is going to require some discussion and argument, just like the 
delete erase direction did.

Generating a completely new set of keysyms on pressing backspace and
delete is not going to solve the C-h/help problem, either, because the 
bs key is still going to be interpereted as 'C-h' in tty mode, btw.

The C-h/help problem is a completely different (albeit related) issue
than the delete erasure direction and is going to be just as much of a 
pain in the rear to solve.

Asbestos suit on... and I'm well caffeinated... flame away.

-- Gary F.

