Re: sum(A1:A3) and cut/paste A2 or A3

[Jody Goldberg <jody gnome org>]

On Thu, May 15, 2003 at 03:51:19PM -0400, Heath Martin wrote:
> Using a fresh compile of Gnumeric 1.1.17:
>
> If A4 is set to sum(A1:A3) and cells A1 to A3 have numeric values,
> and then cell A2 is cut and pasted to B2, then cell A4 still
> has the old sum.  It is not updated like it should be.

Damn, thanks for noticing.  I must have introduced this in 1.1.x
as part of the streamlining of the recalc semantics.  Seems like I
may have gone too far :-)

> Also, if A3 is cut and pasted to B3, and then cut and pasted back
> to A3, then a #REF! error is raised in the sum.  Bug #106148 states
> that this is expected behavior;  could someone explain why?  If
> this is expected, then shouldn't a #REF! error be raised if
> instead I cut/paste B2 back to A2?  That is, as it stands now,
> a #REF! error is raised only when pasting onto the endpoints
> of the range in the sum().  Really though, I would think that
> pasting onto any part of the range in the sum() should not
> be an error.  After all, I could just manually enter a new value.

Hmm, an interesting perspective.  Frankly I can't remember why it is
supposed to do that.  However, the one thing I've learned in writing
that code is to take time before changing it.  There are lots of odd
semantics.  The core of the issue is likely the precise nature of
'cut'.  The theory is that things that reference a cut cell move
with that cell when its is pasted.

eg  in A1 we have =B1.  When B1 is cut and pasted into C1 the
    expression in A1 changes.

Using that as a base state if we reverse the situation and have =B1
in A1, then cut and paste _C1_ into B1.  It seems reasonable to
consider the content of B1 as having been obliterated in some sense
by the new C1 content.  Hence A1 should become #REF!

Moving the entire start/end col/row of a range should
extend/contract things.  However, my thoughts vear off into a fog
pretty shortly after that.  What does it mean to move or obliterate
a portion of a range ?  It would be interesting to see what other
apps do.

> I've been trying to understand the code well enough to fix these,
> but the relevant logic in expr.c is pretty dense.

There is some rather hairy logic in there, and there is more to
come.  Movement is actually a bit different in the presense of
sorting vs cut&paste vs ins/del col/row.  If anyone has the time to
look at the existing code it could certianly do with some review.
I've tried to comment it fairly densely, but it probably deserves a
paper describing it in more depth.