From mboxrd@z Thu Jan 1 00:00:00 1970 From: Derek Feichtinger Subject: Re: org table with auto-incrementing numbers in a column Date: Tue, 16 Feb 2016 09:16:38 +0000 (UTC) Message-ID: References: <87a8n1yv6m.fsf@duenenhof-wilhelm.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVbkZ-0002S0-I7 for emacs-orgmode@gnu.org; Tue, 16 Feb 2016 04:16:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVbkW-0005sN-7K for emacs-orgmode@gnu.org; Tue, 16 Feb 2016 04:16:51 -0500 Received: from plane.gmane.org ([80.91.229.3]:51184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVbkV-0005sI-VN for emacs-orgmode@gnu.org; Tue, 16 Feb 2016 04:16:48 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aVbkS-0007pz-RB for emacs-orgmode@gnu.org; Tue, 16 Feb 2016 10:16:45 +0100 Received: from dflt1w.psi.ch ([129.129.194.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Feb 2016 10:16:44 +0100 Received: from dfeich by dflt1w.psi.ch with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Feb 2016 10:16:44 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: emacs-orgmode@gnu.org Hi > > > > Try this > > > > | N | | > > |---+---| > > | | | > > | | | > > | | | > > | | | > > #+TBLFM: $1..>$1= -1 + 1:: 2$1=1 > > Sorry, I had a typo from copying and replacing in my formula should be | N | | |---+---| | 1 | | | 2 | | | 3 | | | 4 | | #+TBLFM: 3$1..>$1= -1 + 1:: 2$1=1 > > I don't know exactly why "N" is *not* erased but the following is > working for me (org 8.2.10). Hmmm... I just tested. Seems that org is treating the cells before the first horizontal separator line as special... nice. But I seem to remember that this was not always like this. This made me now investigate more closely, using the formula debugger (C-c {) for investigating the original formula. 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 2$1) | N | | |---+---| | | | | 1 | | | 2 | | | 3 | | #+TBLFM: $1= -1 + 1:: 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... > > | N | > |-------| > | 1 | > | 2 | > | 3 | > | 4 | > | 5 | > #+TBLFM: $1= #-1 > > > Placing point on the TBLFM line and doing C-c C-c should recalculate the > > whole table. That formula works fine. It's just a difference in functionality.. the above formula calculates a value based on the numeric position of the current row, while the other formula looks up the value above the current row. Cheers, Derek