From xemacs-m  Mon Jun  2 22:56:48 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 WAA13240
	for <xemacs-beta@xemacs.org>; Mon, 2 Jun 1997 22:56:47 -0500 (CDT)
Received: from Corp.Sun.COM ([129.145.35.78]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA24648; Mon, 2 Jun 1997 21:14:04 -0700
Received: from legba.Corp.Sun.COM by Corp.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA20128; Mon, 2 Jun 1997 20:56:43 -0700
Received: by legba.Corp.Sun.COM (SMI-8.6/SMI-SVR4)
	id UAA06567; Mon, 2 Jun 1997 20:56:26 -0700
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: Martin Buchholz <mrb@Eng.Sun.COM>,
        XEmacs Developers <xemacs-beta@xemacs.org>, wing@666.com,
        jwz@netscape.com
Subject: Re: backspace-or-delete feedback
References: <199706030016.RAA03741@xemacs.eng.sun.com> 	<m267vwjzry.fsf@altair.xemacs.org> 	<kig4tbgsefm.fsf@jagor.srce.hr> <199706030122.SAA03777@xemacs.eng.sun.com> <kigwwocqwh3.fsf@jagor.srce.hr>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Gary.Foster@Corp.Sun.COM (Gary D. Foster)
Date: 02 Jun 1997 20:56:26 -0700
In-Reply-To: Hrvoje Niksic's message of 03 Jun 1997 03:57:44 +0200
Message-ID: <bci910s7311.fsf@corp.Sun.COM>
Lines: 118
X-Mailer: Gnus v5.4.55/XEmacs 20.3(beta3)

Hrvoje Niksic <hniksic@srce.hr> writes:


> 1) Running under X
> 
>    a) If the keyboard has distinct Backspace and Delete keysyms, backspace
>       will delete backwards, whereas Delete will delete forward;

Done...

>    b) Else, the available key (whichever it is) will delete backwards;

Done...

>    c) In either case, Backspace will generate a correct backspace
>       XEmacs event, and Delete will generate a correct delete XEmacs
>       event.

Done

> 2) Running under TTY-s

Haven't touched this yet, waiting for the dust to settle on X mode
before I hack ttys.  (small steps, small steps).  I think the lack of
a general hue and cry with b3 has shown that the X mode changes are at
least on track, so I'll be delving into the scary TTY world shortly.

> 3) Usage and Implementation
>    b) The feature should be implemented in terms of `define-key', if
>       at all possible.  The define-key might involve
>       `function-key-map', `key-translation-map', or whatever we may
>       think of in the future.

Not sure what you mean by "implemented in terms of `define-key'" but
I'm not going the route of key-translation-map.  It's overrideable via 
define-key or just about any other mechanism you might choose to
rebind your keys.

>    c) If turning the feature on/off requires more than two
>       `define-keys', or requires something other than a define-key, it
>       should be packed as a separate function, with a minor-mode-like
>       toggle functionality.

Turning it on and off will require exactly ONE setting.  That's my
goal and I'm not settling for anything less.  That's the way it's
currently working in b3.

>    d) Either way, the feature should be fully reversible.  The user
>       should be able to change the behaviour of all the relevant keys
>       (which may include backspace, delete, C-h, C-?, \e[3~) in a sane 
>       way.  I leave the definition of sane to your imagination.

I agree fully.

>    e) The feature should be created in such a way to require little
>       or no change in the Lisp code.  Old Lisp code should work
>       correctly, if at all possible.  This includes packages like
>       Viper.

Again, I agree, and that's one of my major design goals.  I'm planning 
on shooting for 100% backward compatibility.

> 
> 4) Installation
> 
>    a) Even with all of this implemented, we are not perfect.  Make the 
>       feature default to "off" at first.  Then we see how users and
>       package authors react.
> 
>    b) After a positive reaction, make it default to "on".


Again, I agree.


> These are the features I think are required for it to be the default
> XEmacs behavior.  If not, we'd better stick to the kludges we have
> now.  I believe all of this is possible to implement with some effort.
> It's certainly not easy to do correctly.


Humph... I've already started fixing that "kludge", and the simple
fact that I didn't break anything and you have yet to try and email me
a punch in the nose (smile) shows that I'm doing a passable job of
maintaining compatibility.  In fact, I've only seen two posts wrt the
DEL issue since b3, one of which was because I forgot to fix the
define-keys in VM, the other a mild complaint that I maintained too
much backward compatibility (to paraphrase Martin's cc-mode comment).

Hell, it even works with the delbs.el _hack_ that we threw together a
couple of months ago, although you can get rid of that cruft and get
the same functionality with core code.

In fact, Martin originally didn't even know the changes had gone into
b3, because all of his personal reconfigurations still continued to
work right through the new DEL handling code.  I'll take that as a
positive step towards hopefully being able to eventually clean out all 
the cruft surrounding this issue.

The only thing *I* am going to ask is that people who write their own
custom super whamodyne spiffy delete features that they want to tie in 
to the DEL key handling take a second to tie it in sanely and CHECK
the user preferences (delete-erases-forward) to see which way the user 
expects editing movements to go.  If, like in VM, you don't intend to
perform an editing chore when the user hits DEL then it obviously
doesn't matter.  However, if you write a custom delete function I'll
happily provide the hooks or whatever else you need but I can't
perform miracles.  Once you (define-key...) it's completely out of my
hands.


> If someone thinks I'm asking too much, please remember: I am only
> making it clear what I mean by the "proper implementation", which I
> mentioned in a previous mail.

I think you're being entirely reasonable.

-- Gary F.

