From xemacs-m  Wed Jun  4 14:29:33 1997
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id OAA22164
	for <xemacs-beta@xemacs.org>; Wed, 4 Jun 1997 14:29:32 -0500 (CDT)
Received: (from hniksic@localhost)
          by jagor.srce.hr (8.8.5/8.8.4)
	  id VAA05674; Wed, 4 Jun 1997 21:29:19 +0200 (MET DST)
To: Gary.Foster@Corp.Sun.COM (Gary D. Foster)
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> <bciiuzuqjae.fsf@corp.Sun.COM>
X-Attribution: Hrv
X-Face: Mie8:rOV<\c/~z{s.X4A{!?vY7{drJ([U]0O=W/<W*SMo/Mv:58:*_y~ki>xDi&N7XG
        KV^$k0m3Oe/)'e%3=$PCR&3ITUXH,cK>]bci&<qQ>Ff%x_>1`T(+M2Gg/fgndU%k*ft
        [(7._6e0n-V%|%'[c|q:;}td$#INd+;?!-V=c8Pqf}3J
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 04 Jun 1997 21:29:18 +0200
In-Reply-To: Gary.Foster@Corp.Sun.COM's message of 04 Jun 1997 12:07:05 -0700
Message-ID: <kighgfejhf5.fsf@jagor.srce.hr>
Lines: 89
X-Mailer: Gnus v5.4.52/XEmacs 20.2

Gary.Foster@Corp.Sun.COM (Gary D. Foster) writes:

> 	No, it doesn't work right by default.  The delete key deletes
>       backwards, and only backwards, "by default".

Now, or in a future XEmacs that "does it right"?

Do you want to say that once we fixed all modes, we'll be able to get
the desired behaviour?  Until then, we play it safe and set
`delete-erases-forward' to nil.

> 	New way: DEL no longer mapped to BS, both keys completely
> 	separate.

Please use the `delete' and `backspace' terminology.  In Emacs, DEL is
most often used as an alias for ?\177.  If we remove the C code
forcing \177 to `delete' and put it to `function-key-map' instead,
then DEL and `delete' will suddenly become totally different thing
(only equal by default).

> >   - 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.

I thought I was clear in "that want to provide their own backspace and 
delete functions"?

>       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.

> 	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?

> >   - 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.

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?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm sure they'll listen to reason! -- Neal Stevenson, _Snow Crash_

