emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Problem: Moving rows in a table changes vsum start and end


From: Torsten Wagner
Subject: Re: [O] Problem: Moving rows in a table changes vsum start and end
Date: Sun, 30 Sep 2012 16:30:55 +0900

Hi Carsten,

> Thorsten, if you look at the manual, there are ways to write this limits of 
> vsum etc in a way that they are relative to the table boundaries or to 
> horizontal lines.  This is robust agains changes of rows.

Yes I know, thanks for pointing to it. It is just an dangerous culprit
since people might not be aware of the fact that the formular changes
along with row-moving operations.  Esp. if you use vsum or other range
based operations (with a start and end), one might expect that there
should be no change.

I can only speak for myself, however, as great as it is to use
org-tables, I always have this little paranoid fear that certain cells
did not get updated correctly, might it be due to wrong inputs from my
side or because of a hidden bug. For really critical parts, esp.
during the set-up of a new table, I find myself checking the numbers
by hand again to make sure its going to be ok.
Another problem I faced sometimes is the fact that after a while I
forgot that a certain cell is addressed by a formular. I do changes by
hand and just the next press of C-u C-c C-c might overwrite them
accidentally without my notice.

Having overlays or any sort of highlighting might be very helpful (and
as the nature of emacs, people might just decide to turn them on and
off if they get annoyed).
I was thinking of:
+ Mark all cells/numbers which depend or are part of a formular (kind
what we have already in the formular editor but for all and every
forms)
+ Mark all cells which were updated by  C-u C-c C-c (as the above but
in addition being now different compared to the previous result)
+ Mark the parts of the formulars which using the cell in which the
pointer is currently placed (reverse compared to the already existing
formular highlighting)
+ Mark all cells which have by formulars some relation to the cell in
which the pointer is currently placed (use two colors to indicate
inputs and outputs)

Those would give me a much more confidence, e.g., that all the fields
are updated correctly, that I did not overwrite by accident an
calculated value and it would help me to understand quickly the
relation of cells even months after writing down the formulars.

Greetings

Torsten



reply via email to

[Prev in Thread] Current Thread [Next in Thread]