From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: org table with auto-incrementing numbers in a column
Date: Tue, 16 Feb 2016 17:51:19 +0100
Message-ID: <87io1oppiw.fsf@nicolasgoaziou.fr>
References: <CAFyQvY3qE8TauR3fW=z7_y7ijFwR1ZOWM4nayKezrthYy9bHSw@mail.gmail.com>
	<loom.20160216T071346-143@post.gmane.org>
	<87a8n1yv6m.fsf@duenenhof-wilhelm.de>
	<loom.20160216T095701-420@post.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47748)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mail@nicolasgoaziou.fr>) id 1aVioR-0003E3-8z
	for emacs-orgmode@gnu.org; Tue, 16 Feb 2016 11:49:20 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mail@nicolasgoaziou.fr>) id 1aVioO-0002a5-2R
	for emacs-orgmode@gnu.org; Tue, 16 Feb 2016 11:49:19 -0500
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:55553)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mail@nicolasgoaziou.fr>) id 1aVioN-0002a1-Sd
	for emacs-orgmode@gnu.org; Tue, 16 Feb 2016 11:49:16 -0500
In-Reply-To: <loom.20160216T095701-420@post.gmane.org> (Derek Feichtinger's
	message of "Tue, 16 Feb 2016 09:16:38 +0000 (UTC)")
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
To: Derek Feichtinger <dfeich@gmail.com>
Cc: emacs-orgmode@gnu.org

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