From xemacs-m  Wed Jun  4 16:03:29 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 QAA24416
	for <xemacs-beta@xemacs.org>; Wed, 4 Jun 1997 16:03:28 -0500 (CDT)
Received: from Corp.Sun.COM ([129.145.35.78]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA01735 for <xemacs-beta@xemacs.org>; Wed, 4 Jun 1997 14:21:31 -0700
Received: from legba.Corp.Sun.COM by Corp.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA23255; Wed, 4 Jun 1997 14:03:53 -0700
Received: by legba.Corp.Sun.COM (SMI-8.6/SMI-SVR4)
	id OAA14295; Wed, 4 Jun 1997 14:03:51 -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> <bciiuzuqjae.fsf@corp.Sun.COM> <kighgfejhf5.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 14:03:51 -0700
In-Reply-To: Hrvoje Niksic's message of 04 Jun 1997 21:29:18 +0200
Message-ID: <bci67vuqdvs.fsf@corp.Sun.COM>
Lines: 128
X-Mailer: Gnus v5.4.55/XEmacs 20.3(beta3)

Hrvoje Niksic <hniksic@srce.hr> writes:

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

Now.  The b3 version has the provisions for "doing it right" now.

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


I have already fixed everything in the lisp/modes directory.  I've
also fixed cc-mode, cperl-mode, and vm.  I'll happily fix anything
else I might have missed, especially when the fixes are so trivial.


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

Right now, with xemacs -q, pressing the little grey key labelled 'del'
on my keyboard (and all the others I've tried) generates a \177
sequence.  If I remove the mapping and move it to function-key-map
instead, I assume that you'll give me credit for enough intelligence
to follow that with a one-line change in keydefs.el also.

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

What are you trying to say here?  If you want to provide your own
backspace or delete function, you do it just exactly like you would
before.  You write:

defun hrvoje-super-delete ...)

and

(define-key hrvoje-map 'hrvoje-super-delete)

How is this *any* different than it was before?  That's *exactly* how
it was before.

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

Uhm... from the original cc-mode, before I touched it:

legba:$ grep "177" /usr/local/lib/xemacs-19.15/lisp/modes/cc-mode.el
  (define-key c-mode-map "\177"      'c-electric-delete)

From the patched cc-mode, after I touched it:

legba:$ grep "177" ~/xemacs-20.3-b3/lisp/modes/cc-mode.el
  (define-key c-mode-map "\177"      'c-electric-delete)

and the only real changes I made were to change the 'c-delete-function
assignment from 'backward-delete-char-untabify to 'backspace-or-delete
and added a simple `if' check into the c-electric-delete function to
delete in the right direction if c-hungry-delete is active.  If you
don't like it, that's fine, but that's the way it's always been and I
am just making use of the stuff already there.

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


I don't have any problems with this, but the backspace handling stuff
is a completely seperate issue from the delete handling stuff and I'd
appreciate it if we could keep them both distinct.

> Please explain the \177 <-> delete discrepancy.

I think I've already explained that in quite enough detail.  When and
if we decide to do the function-key-map change to cause the little
grey key to generate 'delete I'll change everything else too.  Until
then, that funny little key still generates \177.

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

Geez, now I'm being forced to defend what I named a function?  Sheesh,
I think we're descending into the realm of nits here.  I'm not going
to defend it.  It stands on it's own merits, it works, and I consider
it a final design decision.  I think the fact that _it works_ and it
works _well_ is quite enough to enable it to stand on it's own merits.
If it breaks, I'll fix it.  I notice that you haven't complained about
your keyboard being broken in beta 3, so if you're not doing anything
to remap all the stuff around it obviously is working well enough that
you don't notice it and if you're doing a bunch of cruft from before
(like Martin was) to remap all the delete key behavior it also
obviously works well enough that it is transparent to your workarounds
and continues to let them work just fine.  That, my friend, is what
I've been shooting for all along.

-- Gary F.

