Hello, Derek Feichtinger <dfe...@gmail.com> writes:
> When I use this formula > > #+TBLFM: $1= @-1 + 1:: @2$1=1 > > Then org will first fill this part of the table (starting at cell <at>2$1) > > | N | | > |---+---| > | | | > | 1 | | > | 2 | | > | 3 | | > #+TBLFM: $1= <at>-1 + 1:: <at>2$1=1 > > Then it will execute the second formula, which sets the value in row 2: > > | N | | > |---+---| > | 1 | | > | 1 | | > | 2 | | > | 3 | | > > Only upon a second evaluation of the whole table, it will arrive at > > | N | | > |---+---| > | 1 | | > | 2 | | > | 3 | | > | 4 | | > > So, this is one of the cases where one needs to carry our iterations until > the table stays constant (can use org-table-iterate). > > I also tried the same with changing the order of the two formulas. Seems > that the row formula always is executed first. So, at least this is > consistent. Why it starts at row 3 one would need to look up in the > source... Field formulas bind stronger than column formulas. First, all cells with an associated field formula are marked as read-only. Then column formulas are evaluated. Eventually, fields formulas are evaluated. This was introduced in Org 5.01, AFAICT. Before, the "read-only" part would not happens, i.e, fields formulas would overwrite column formulas. I think the idea behind this is that formulas are applied to the current state of the table, not some intermediate one, with some formulas applied and others not. Regards, -- Nicolas Goaziou
