Re: org table with auto-incrementing numbers in a column

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Hello,

Derek Feichtinger <dfeich@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