From xemacs-m  Wed Jun  4 14:06:46 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 OAA21508
	for <xemacs-beta@xemacs.org>; Wed, 4 Jun 1997 14:06:43 -0500 (CDT)
Received: from Corp.Sun.COM ([129.145.35.78]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA10678 for <xemacs-beta@xemacs.org>; Wed, 4 Jun 1997 12:24:44 -0700
Received: from legba.Corp.Sun.COM by Corp.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA08377; Wed, 4 Jun 1997 12:07:06 -0700
Received: by legba.Corp.Sun.COM (SMI-8.6/SMI-SVR4)
	id MAA14070; Wed, 4 Jun 1997 12:07:05 -0700
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: cc-mode delete behavior [PATCH]
References: <bcipvu2pbof.fsf@corp.Sun.COM> <kiglo4qjjgt.fsf@jagor.srce.hr>
X-Attribution: GDF
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: 04 Jun 1997 12:07:05 -0700
In-Reply-To: Hrvoje Niksic's message of 04 Jun 1997 20:45:06 +0200
Message-ID: <bciiuzuqjae.fsf@corp.Sun.COM>
Lines: 71
X-Mailer: Gnus v5.4.55/XEmacs 20.3(beta3)

Hrvoje Niksic <hniksic@srce.hr> writes:

> Since I have acted as Advocato Diabolo (pardon my Danish) in this
> case, can you please write a short paragraph which explains how your
> solution works.  Yes, I can read the source, but I want to hear it
> from you.  Here is my interpretation:
> 
>   - XEmacs works right by default.

	No, it doesn't work right by default.  The delete key deletes
	backwards, and only backwards, "by default".  Lots of modes
	overrode the behavior to do weird things, and there wasn't a
	consistent behavior across modes unless you specifically
	addressed the idiosyncracies.  Now, with one variable changed,
	it will either delete backwards or forwards depending on how
	you desire it.  Before, unless the USER did specific things,
	he/she couldn't rely on consistent behavior of the DEL key.
	Now, unless the MODE WRITER does something special, behavior
	is consistent across all modes.

	Old way:  DEL and BS were tied together, both bound to the
	function 'backward-delete-char-untabify

	New way: DEL no longer mapped to BS, both keys completely
	separate.  BS bound to 'backward-delete-char (-untabify
	removed, but can be put back in pretty easily).  DEL bound to
	'backspace-or-delete which is just a function that checks the
	status of 'delete-erases-forward and does a delete-char in the 
	appropriate direction depending on the setting.

>   - Modes that want to provide its own backspace and delete functions
>     should bind delete to `backspace-or-delete'.  What should they
>     bind backspace to?

	Not exactly.  Modes that don't want to provide a custom DEL
	key behavior don't bind anything to "\177" and just simply
	leave it alone.  If they want something like c-electric-delete 
	(from cc-mode), they simply:

	(define-key my-mode-map "\177" 'my-delete-function)

	and then inside the delete function check whether
	delete-erases-forward is t or nil and delete in the direction
	that the user expects.

	Backspace already works as everyone expects it to (in X mode,
	anyway, there's still quite a bit of arguing going on over TTY
	mode though) therefore the only thing modes need to worry
	about right now is the delete key since that's the only key
	that I modified the behavior of.  Once the dust settles on the
	TTY mode debates over BS we can revisit and flesh that part
	out.

>   - What should modes that want to use backspace and delete for
>     various unholy purposes (such as scrolling in Gnus) do?

	(define-key my-mode-map "\177" 'my-unholy-function)
	(define-key my-mode-map 'backspace 'my-other-unholy-function)

	This is what my trivial change to VM did...  the relevant
	lines were:

	(define-key map "\177" 'vm-scroll-backward)
	(define-key map 'backspace 'vm-scroll-backward)

	The biggest change in this case is the fact that mode writers
	shouldn't rely on DEL and BS being translated into the same
	thing by default and calling for it explicitly in their
	mode-map definitions as above.

-- Gary F.

