From xemacs-m  Wed Jun  4 19:32:03 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 TAA05369
	for <xemacs-beta@xemacs.org>; Wed, 4 Jun 1997 19:32:02 -0500 (CDT)
Received: (from hniksic@localhost)
          by jagor.srce.hr (8.8.5/8.8.4)
	  id CAA09287; Thu, 5 Jun 1997 02:31:59 +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> <kighgfejhf5.fsf@jagor.srce.hr> <bci67vuqdvs.fsf@corp.Sun.COM> <kig67vurrpn.fsf@jagor.srce.hr> <bciwwoaowwz.fsf@corp.Sun.COM> <kig4tberkvf.fsf@jagor.srce.hr> <bcizpt5oqvh.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: 05 Jun 1997 02:31:58 +0200
In-Reply-To: Gary.Foster@Corp.Sun.COM's message of 04 Jun 1997 17:06:10 -0700
Message-ID: <kigwwo9ritd.fsf@jagor.srce.hr>
Lines: 174
X-Mailer: Gnus v5.4.52/XEmacs 20.3(beta3)

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

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > Yes, but \177 is turned to delete.  Which is in turn output as DEL.
> > Look at the source.
> > 
> > > (define-key global-map 'delete 'foo)
> > > 
> > > Doesn't change anything.  I'll gladly accept the fact that the DEL key 
> > > *should* generate a 'delete, and that doing the second define-key
> > > above SHOULD be the proper way to bind 'foo to the DEL key, but it's
> > > not the way it is right now.
> > 
> > Have you tested this example?  In 20.3-b3, the above form makes every
> > pressing of the grey key go beep for me.
> 
> Yep, I have.  After evaluating it, every press of the delete key
> invokes 'backspace-or-delete.

Not for me.  Count it as a bug, if you want to.  The output of
emacs-version:

XEmacs 20.3 [Lucid] (sparc-sun-solaris2.5) of Wed Jun  4 1997 on jagor.srce.hr

> In tty mode, too.

Likewise.  Beeps every time.

> Hmm, if we map \177 to delete by default via the function-key-map, and
> I change all my references from "\177" to 'delete, that should in
> effect do what you're saying here, right?  Or am I misunderstanding?
> I *believe* that what your saying is that pressing the "del" key
> should generate a 'delete keysym, which we then map to 'foo-function
> or whatever instead of mapping "\177"?  If I understand correctly,
> then yes, I agree.

Now you got me.  This is indeed quite complex, and now I'll try to
explain *very* carefully exactly what I am trying to say.  In
different parts of discussion I was hinting at two things (which I now 
realize.)

There are two approaches when tty-erase-char != C-h.  Read them well,
because I will be refering to them at all times.  Also, don't dismiss
them because they talk of TTY.  If we straighten them out, the X
issues will stand at the plate (only `x-keysym-on-keyboard-p' will
take the conceptual role of `tty-erase-char'.)

a)
   1. pressing the key above enter generates \177

   2. character_to_event leaves that as \177

   3. function-key-map translates this to delete

   4. since tty-erase-char != C-h, delete will be bound to
      `backward-delete'

   5. pressing C-h is exactly C-h (help-command)

b)
   1. pressing the key above enter generates \177

   2. character_to_event leaves that as \177

   3. function-key-map translates this to backspace, since
      tty-erase-char != C-h

   4. backspace is, of course, bound to backward-delete


Note that both the approaches involve converting of \177 to anything
in function-key-map, *not* hard-coded in C.  That is what FSF does, I
believe.

The approach b) is better technically, because you can have two
consoles with console-local function-key-maps, one with
`stty erase ^H' and one with `stty erase ^?'.  In both of them
pressing the key above ENTER will be transformed to backspace, and
you'll get backward deletion.

The approach a) achieves a greater compatibility with the old code
that does assumption about what delete is, but loses with more TTY
consoles.


If I understand correctly, you have a third approach which says that:

c)
   1. pressing the key above enter generates \177

   2. character_to_event or function-key-map convert it to delete

   3. delete is bound to `delete-backward-or-forward'

   4. `delete-backward-or-forward' does its magic, according to the
      alignment of the stars, the moon, the sun, tty-erases-forward
      and x-keysym-on-keyboard-p *what* it should really do.


I believe solution c) may be the winning one, although I hate it. :-) 
Seriously, your solution is the compromise between a) and b), which
should make the end user and the Lisp authors happy.

> Well, some people want that and others want the key to the right of it
> to erase backwards as well.  Thus the rwar erupts.  Hell, if that
> weren't the case we could just map the delete key to 'delete-char and
> walk away passively, alas that isn't the case.

No, we couldn't.  It would lose on TTY-s.  It would lose on my X
setup.

I am *not* talking about a religious issue here, but about a real,
non-religious problem.

With my approach b) implemented, I really think we could map the
delete key to 'delete-char.  I am prepared to die.

> > The cited thing.  I just wanted to ask whether such a design is a Good
> > Thing (no, I didn't mean to get personal; I'm not Erik).
> > 
> > I'd prefer delete (or whatever) being bound to delete-forward and
> > backspace to delete-backward, provided I have both keysyms.  Since I
> > don't, the next-of-kin choice is to bind backspace to /dev/null and
> > delete to delete-backwards.
> 
> That would suit me just fine, too, however it doesn't take into
> account those people who want DEL and BS keys to both do the same
> thing,

They define DEL to BS via the function-key-map or key-translation-map.

> nor does it take into account rebinding them to other
> functions.

It does.  The keys are completely separate.

> level and that, fwiw, is a small victory.  We've finally shifted
> from using translations to an argument on what the keys themselves
> should invoke which means we're making progress. :)

Definitely.

> > I notice that your scheme doesn't work that way, and I'd like to ask
> > why -- without *ever* wanting to "cut it to shreds."
> 
> My scheme doesn't do that on a low level, but it does have the same
> end result:

Yes.  I believe I have described well as c).

> If you only have the one keysym you get the default
> backwards-deletion with that keypress.  No if's, and's, or's, or
> but's about it.

Yup.

> But I also make allowances for the fact that the user might WANT both
> keys to be bound to completely weird things or whatever.

So do I.  But this doesn't mean I am against your scheme.

> I think the only thing we really differ on is whether pressing the
> "del" key should generate a 'delete or a "\177".

Define "generate".  I think it should exit character_to_event as
\177.  The default function-key-map will set it to <something> in case 
a) and 'delete in case b).

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

