Subject: changes not in sequence

From: [email-masked]
Date: Tue, 25 May 1993 23:48:47 -0400

rhubarb rhubarb.  it's just a bug that i never saw my way through to fix.

what the message means is that you've generated a list of changes to
be made atomically that don't occur in increasing non-overlapping
addresses in the file.  this is hard to do unless you put addresses inside
commands, e.g.
	x/./ -d
this particular example is an error - it will delete the same line many times -
but there are more complex examples that should work but don't.

the bug should be easy to fix, but it's not.
in principle, you (that is, i) just sort the transcript list and execute it in order.
(if the changes occur out of order, the address arithmetic in the update
routine will screw up.)  the problem is that, for vital efficiency, nearby changes
are folded together so many small adjacent modifications can be done in
one disk i/o (say), which makes it impossible to keep them separate in order
to be able to sort them.  hence the message.  i always intended to fix the
problem; i never saw how.

i have a whole new system now that contains much more efficient code to do
all this stuff, obviating the need for the extra level of cache and hence making
it possible to sort the changes (as in fact i do in this new system).  the code
could be retrofitted but it's a huge job and i think my time and others' is
better spent on other things, such as getting this new system working.

apologies.

-rob

---

From: "Ozan S. Yigit" <[email-masked]>
Date: Wed, 26 May 1993 16:18:37 -0400

> i have a whole new system now that contains much more efficient code
> to do all this stuff, obviating the need for the extra level of cache
> and hence making it possible to sort the changes (as in fact i do in
> this new system). the code could be retrofitted but it's a huge job ...

are there any other improvements in the new system we can borrow for
sam? the message protocol between the term and the editor proper? any
new commands and/or interface ideas?

oz