From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yu Subject: Table formulas: Cannot use column names on the left hand side Date: Thu, 16 Feb 2012 16:56:43 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:52748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ry3hz-0003UE-Qb for emacs-orgmode@gnu.org; Thu, 16 Feb 2012 10:57:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ry3hs-0007cp-DL for emacs-orgmode@gnu.org; Thu, 16 Feb 2012 10:57:23 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:44910) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Ry3hs-0007cA-0v for emacs-orgmode@gnu.org; Thu, 16 Feb 2012 10:57:16 -0500 Received: by eaag11 with SMTP id g11so935299eaa.0 for ; Thu, 16 Feb 2012 07:57:13 -0800 (PST) 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: org-mode mailing list Hello! I tried today to use named columns for calculations. While this works on the right hand side of the equation, names don't seem to work for the left hand side -- which is a problem, because a change in column arrangement, that isn't caused by org functions (e.g. manually inserting a column with rectangle-copying) may cause an input column to be overwritten accidentially (e.g. having a formula $4=$3*$2+$1 and then manually inserting a column for line markers as described in "Advanced Features"). Exactly this happened to me recently, forcing me to redo some by-hand evaluation. Here some examples to clarify the problem: ----------------------------------------------------------------------------- Recalculation attempts done each with C-u C-c C-c in the table and with C-c C-c in the formula line, and with C-u C-c *. Works fine: | a | b | a+b | |-----+-----+-----| | 1.0 | 1.0 | 2.0 | | 1.5 | 0.5 | 2.0 | | 0.5 | 0.0 | 0.5 | #+TBLFM: $3=$1+$2;%.1f Doesn't Work: | | a | b | a+b | |---+-----+-----+-----| | | 1.0 | 1.0 | | | | 1.5 | 0.5 | | | | 0.5 | 0.0 | | | ! | a | b | ab | #+TBLFM: $ab=$a+$b Doesn't Work: | | a | b | a+b | |---+-----+-----+-----| | | 1.0 | 1.0 | | | | 1.5 | 0.5 | | | | 0.5 | 0.0 | | | ! | a | b | ab | #+TBLFM: $4=$a+$b Even this doesn't work | | a | b | a+b | |---+-----+-----+-----| | | 1.0 | 1.0 | | | | 1.5 | 0.5 | | | | 0.5 | 0.0 | | | ! | a | b | ab | #+TBLFM: $4=$2+$3 This works again; This is sort of consistent with the specification, that "Unmarked lines are exempt from recalculation with C-u C-c *", but there was no mention, that it affects other methods of causing recalculation too in `(info "(org)")'. | | a | b | a+b | |---+-----+-----+-----| | * | 1.0 | 1.0 | 2. | | * | 1.5 | 0.5 | 2. | | * | 0.5 | 0.0 | 0.5 | | ! | a | b | ab | #+TBLFM: $4=$2+$3 This again does NOT work. | | a | b | a+b | |---+-----+-----+-----| | * | 1.0 | 1.0 | | | * | 1.5 | 0.5 | | | * | 0.5 | 0.0 | | | ! | a | b | ab | #+TBLFM: $ab=$2+$3 Works again. | | a | b | a+b | |---+-----+-----+-----| | * | 1.0 | 1.0 | 2. | | * | 1.5 | 0.5 | 2. | | * | 0.5 | 0.0 | 0.5 | | ! | a | b | ab | #+TBLFM: $4=$a+$b