From xemacs-m  Thu Jun  5 01:22:40 1997
Received: from cerise.sensei.co.uk (glynn@muvies.demon.co.uk [158.152.66.14])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id BAA25797
	for <xemacs-beta@xemacs.org>; Thu, 5 Jun 1997 01:22:37 -0500 (CDT)
Received: (from glynn@localhost) by cerise.sensei.co.uk (8.8.5/8.8.2) id HAA05979; Thu, 5 Jun 1997 07:05:05 +0100
Date: Thu, 5 Jun 1997 07:05:05 +0100
Message-Id: <199706050605.HAA05979@cerise.sensei.co.uk>
From: Glynn Clements <glynn@sensei.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: cc-mode delete behavior [PATCH]
In-Reply-To: <bci4tbeorrl.fsf@corp.Sun.COM>
References: <bcipvu2pbof.fsf@corp.Sun.COM>
	<kiglo4qjjgt.fsf@jagor.srce.hr>
	<bciiuzuqjae.fsf@corp.Sun.COM>
	<kighgfejhf5.fsf@jagor.srce.hr>
	<199706042305.AAA01342@cerise.sensei.co.uk>
	<bci4tbeorrl.fsf@corp.Sun.COM>
X-Mailer: VM 6.31 under 20.3 XEmacs Lucid (beta3)


Gary D. Foster wrote:

> Glynn Clements <glynn@sensei.co.uk> writes:
> 
> > I think that it's improved upon the previous situation of choosing
> > between a 120 package (delbackspace) which tries to untangle the
> > equivalance assumed by many different packages, and a quick fix
> > (delbs) which has some irritating side effects (like Delete -> EOF).
> > 
> > I still think the neatest solution at the package level is for an
> > author to have a keysym that can have forward deletion functions bound
> > to it unconditionally, via define-key.
> 
> I agree whole-heartedly with this.  That's the whole heart of the
> "\177" versus 'delete discussion between Hrvoje and I, and you've
> managed to cut through all the rhetoric to phrase it much better than
> I could.
> 
> My only concern though, with binding this keysym to the delete _key_ is
> how do you reconcile this with the fact that some people want the
> delete key to erase forwards and others want it to erase backwards?

I don't think that many people want what you or I mean by `the Delete
key' to delete backwards. I suspect that it's more a case of having a
BackSpace key which generates the Delete keysym under X or which
generate \177 on a tty, which is hardcoded to Delete.

My personal favourite solution is for \177 to be mapped to BackSpace,
particularly if it's the tty erase character. I suspect that PC-style
Delete keys are more likely to generate \e[3~.

> Besides, we already (kind of) have a keysym that unconditionally
> erases forward (meaning everyone pretty much expects it, not that it
> can't be overridden).  That would be the C-d key.

I'm aware from reading the documentation that C-d generally deletes
forwards. However, my subconscious is convinced that C-d is EOF (as it
is in term-mode and a large chunk of the Unix environment), and that I
have to press the Delete key to delete forwards (as I have to in any
package running under a certain commercial OS that I find myself
using rather more than I would wish to).

> I think the crux is that everyone pretty much agrees what backspace
> should do (erase backwards) and C-d (erase forwards)

I'd say that that's the case.

> and the real argument stems from what the delete key should do,

Maybe the argument is more about what exactly does person X mean when
they talk about `the delete key'.

The term could refer to the key which generates the X keysym Delete,
the key which generate DEL (a.k.a \177), the key the user expects to
delete backwards, the key the user expects to delete forwards, the key
with Delete printed on it, the key that doesn't have Delete printed on
it but is in the same position as the key that does have Delete
printed on it on the keyboard that the user has at work, ...

Perhaps the intern function could be modified so that XEmacs dumps
core and reboots the machine if you try to intern the symbol `delete' :)

> which in my opinion should be settable to either erase forwards or
> backwards depending on the user preference via a one-liner in .emacs
> and shouldn't be a burden on the user.  It should also break as
> little as possible and play nicely with everyone else, as well as
> carry the setting across all modes.

I would say that the (internal) delete keysym should delete
forwards. If the user doesn't want the key that generates the (X)
Delete keysym to delete forwards, it should to be translated at a
single point before it makes it down into package code, not in several
dozen different packages.

There is a second issue, namely ASCII to keysym translation. This IMO
should be done up in lisp-land, not down in the C guts. I think that
the existing mapping of \e[3~ onto delete is unambiguous (assuming
delete is going to delete forwards). There should be a feature to
control the interpretation of \177 and \010, preferably defaulting to
an auto-selection based on tty-erase-character. Either \177 is
backspace and \010 is help, or \010 is backspace, \177 is delete and
something else is help.

-- 
Glynn Clements <glynn@sensei.co.uk>

