From xemacs-m  Mon Jun  2 20:58:13 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 UAA12067
	for <xemacs-beta@xemacs.org>; Mon, 2 Jun 1997 20:58:12 -0500 (CDT)
Received: (from hniksic@localhost)
          by jagor.srce.hr (8.8.5/8.8.4)
	  id DAA08323; Tue, 3 Jun 1997 03:57:45 +0200 (MET DST)
To: Martin Buchholz <mrb@Eng.Sun.COM>
Cc: XEmacs Developers <xemacs-beta@xemacs.org>, wing@666.com, jwz@netscape.com
Subject: Re: backspace-or-delete feedback
References: <199706030016.RAA03741@xemacs.eng.sun.com> 	<m267vwjzry.fsf@altair.xemacs.org> 	<kig4tbgsefm.fsf@jagor.srce.hr> <199706030122.SAA03777@xemacs.eng.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: 03 Jun 1997 03:57:44 +0200
In-Reply-To: Martin Buchholz's message of Mon, 2 Jun 1997 18:22:21 -0700
Message-ID: <kigwwocqwh3.fsf@jagor.srce.hr>
Lines: 101
X-Mailer: Gnus v5.4.52/XEmacs 20.2

Martin Buchholz <mrb@Eng.Sun.COM> writes:

> Hrv> Why not, if properly implemented?
> 
> Hrv> Of course, my definition of "properly implemented" is quite strict.
> 
> I agree.  This feature is not yet "properly implemented" (see my
> cc-mode complaint).  However, it is well on its way.
> 
> Steve: I, Ben, and Hrvoje all feel that if and when this feature is
> properly implemented, it should eventually become the default.  I
> even managed to convince jwz (private communication).

Since my name is mentioned, I'll now try to define once and for all
exactly what I mean under "properly implemented".

1) Running under X

   a) If the keyboard has distinct Backspace and Delete keysyms, backspace
      will delete backwards, whereas Delete will delete forward;

   b) Else, the available key (whichever it is) will delete backwards;

   c) In either case, Backspace will generate a correct backspace
      XEmacs event, and Delete will generate a correct delete XEmacs
      event.

2) Running under TTY-s

   a) If TTY settings say that ^H should mean erase, then C-h will
      erase backwards.  Help will be on M-?, and C-? and delete
      (usually \e[3~) will delete forward.

      ### The actual implementation of this is unclear to me; should
      C-h actually be backspace?  Should one be able to differentiate
      between C-? and `\e[3~'?  Yes and yes, probably.

   b) Else, XEmacs will disregard the TTY settings (no, I don't like
      `#' meaning delete-backward on SYSV), and retain the normal C-h
      binding.  `C-?' will then delete backwards.  What `\e[3~' will
      do is open to discussion.

      ### C-? should probably not be hardcoded to Delete.  C-? and
      `\e[3~' should probably be distinguishable.

3) Usage and Implementation

   a) XEmacs should know the proper names of its keys.  For example,
      pressing backspace on a TTY and on X should generate a message
      like: `backspace runs the command delete-backward-char', even if 
      the user pressed C-h.  When the user presses C-? or \e[3~, it
      should not be masqueraded as C-d.

   b) The feature should be implemented in terms of `define-key', if
      at all possible.  The define-key might involve
      `function-key-map', `key-translation-map', or whatever we may
      think of in the future.

   c) If turning the feature on/off requires more than two
      `define-keys', or requires something other than a define-key, it
      should be packed as a separate function, with a minor-mode-like
      toggle functionality.

   d) Either way, the feature should be fully reversible.  The user
      should be able to change the behaviour of all the relevant keys
      (which may include backspace, delete, C-h, C-?, \e[3~) in a sane 
      way.  I leave the definition of sane to your imagination.

   e) The feature should be created in such a way to require little
      or no change in the Lisp code.  Old Lisp code should work
      correctly, if at all possible.  This includes packages like
      Viper.

      The change should be clean, and accompanied with a feature to
      test against, so we can change the Lisp code compatibly; we may
      even try to convince RMS that this is good, so that all the
      packages Out There comply.

4) Installation

   a) Even with all of this implemented, we are not perfect.  Make the 
      feature default to "off" at first.  Then we see how users and
      package authors react.

   b) After a positive reaction, make it default to "on".


These are the features I think are required for it to be the default
XEmacs behavior.  If not, we'd better stick to the kludges we have
now.  I believe all of this is possible to implement with some effort.
It's certainly not easy to do correctly.

If someone thinks I'm asking too much, please remember: I am only
making it clear what I mean by the "proper implementation", which I
mentioned in a previous mail.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
You'll notice that perl is not itself written in Perl.
                                                 -- The Perl FAQ

