From xemacs-m  Wed Jun  4 18:25:24 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 SAA28780
	for <xemacs-beta@xemacs.org>; Wed, 4 Jun 1997 18:25:21 -0500 (CDT)
Received: (from glynn@localhost) by cerise.sensei.co.uk (8.8.5/8.8.2) id AAA01342; Thu, 5 Jun 1997 00:05:06 +0100
Date: Thu, 5 Jun 1997 00:05:06 +0100
Message-Id: <199706042305.AAA01342@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: <kighgfejhf5.fsf@jagor.srce.hr>
References: <bcipvu2pbof.fsf@corp.Sun.COM>
	<kiglo4qjjgt.fsf@jagor.srce.hr>
	<bciiuzuqjae.fsf@corp.Sun.COM>
	<kighgfejhf5.fsf@jagor.srce.hr>
X-Mailer: VM 6.31 under 20.3 XEmacs Lucid (beta3)


Hrvoje Niksic wrote:

> >       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.
> 
> I'm not sure I like this.  I'd like to hear others' opinions regarding
> this particular point.

Okay then. My opinion, FWIW:

We decide on a keysym that always deletes forward. Use either the
existing `delete' keysym, or create a new `delete-forward'
keysym. Packages bind forward deletion functions to this key (as well
as to C-d if desired), and backward deletion functions to `backspace'.

The user is provided with a mechanism to configure whether the delete
keysym gets translated into backspace or delete(-forward).

This could be a pair of functions (delete-deletes-forward,
delete-deletes-backward) which modify the appropriate keymap, probably
key-translation-map, so that any `\e[3~ -> delete' mapping in
function-key-map is handled correctly.

This seems cleaner than requiring any function which is bound to
delete to check a variable at run-time.

The downside is that you can't have delete == backspace in some modes
and delete != backspace in others, although I'm not even sure if such
an option is desirable.

> > 	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.
> 
> I still think we should remove all the cruft from Fcharacter_to_event
> and move the `C-i' -> tab, C-j -> newline and others to
> `function-key-map'.  According to whether `tty-erase-char' is set to
> ^H or not, the C-h setting in this map would be bound to C-h or to
> backspace.
> 
> If `tty-erase-char' is ^H, some other function would bind M-? to
> help-command, but that's hardly a problem.
> 
> Any problems with this scheme?

Seems eminently sensible.

> > >   - 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)
> 
> Please explain the \177 <-> delete discrepancy.
> 
> > 	(define-key my-mode-map 'backspace 'my-other-unholy-function)
> 
> OK.
> 
> > 	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.
> 
> I could accept that.

Me too.

> BTW, I'm not particularly fond of the command named
> `backspace-or-delete' and binding delete (or \177?) to it.  How would
> you defend it?  Is it a temporary solution, or do you consider it a
> final design decision?

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.

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

