From xemacs-m  Thu Mar 20 20:29:40 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id UAA28720
	for <xemacs-beta@xemacs.org>; Thu, 20 Mar 1997 20:29:39 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQchtp09591; Thu, 20 Mar 1997 21:29:40 -0500 (EST)
Date: Thu, 20 Mar 1997 21:29:40 -0500 (EST)
Message-Id: <QQchtp09591.199703210229@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: RFC undo changes
In-Reply-To: <199703200736.QAA06514@Pentagana.sonic.jp>
References: <199703191545.AAA00194@Pentagana.sonic.jp>
	<QQchon10207.199703191729@crystal.WonderWorks.COM>
	<199703200736.QAA06514@Pentagana.sonic.jp>
X-Mailer: VM 6.20 under 19.15 XEmacs Lucid (beta101)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

P E Jareth Hein writes:
 > What I am proposing to be able to do is to after typing in a string
 > for an asian language, you then 'commit' the string and go through a
 > series of choices to get to the final output. What I WANT to put in is 
 > the ability after commiting a string, doing some further editing, etc, 
 > is have undo back up to the step right before commiting, with the
 > string demarkations, etc all in place. I've got this for the LAST
 > string commited, as I save all that, but I'd like to have as many as I 
 > have undo's.
 > 
 > I realize that putting a general capability of putting functions on
 > undo opens things up to massive abuse, but if we put this in XEmacs,
 > we'll be the only editor with true re-editing for asian text.

All this sounds reasonable to me, although I only fuzzily
understand the input process you're talking about.

Currently if you GC inside Fprimitive_undo, XEmacs may well crash
sometime later due to unGCPRO'd objects being used.  I'm not
keen on introducing more places where Lisp is run from C code
just now, given some unexplained crashes in the garbage
collector.

