Hi Wu Feng, thank your for this rather clear bug report, even including the correct analysis. And Christian, thanks for confirming that this is a bug.
As already suggested by Wu Feng, this error is caused by a premature expansion of @>$1, while still inside the context of table 2. In that context, @>$1 expands to @2$1 and then accesses the wrong field in table 1. This should be fixed now, please verify. Thanks! - Carsten On 26.10.2011, at 10:47, Wu Feng wrote: > Hello, > > First, please check below simple example, I defined two tables (T1 and > T2). In table-2, I remotely refer to the @>$1 (last row, column 1) and > $LR2 (last row, column 2) of T1. > > #+TBLNAME: T1 > | 11 | 12 | > | 21 | 22 | > | 31 | 32 | > > #+TBLNAME: T2 > | xxx | xxx | xxx | xxx | > | # | 21 | 32 | | > #+TBLFM: @>$3=remote(T1,$LR2)::@>$2=remote(T1,@>$1) > > Obviously, the expected results are: > > - remote(T1,@>$1) is replaced by 31 > - remote(T1,$LR2) is replaced by 32 > > But I got 21 for remote(T1,@>$1). The $LR version works perfectly > (though the manual says $LR is out-dated) > > Below are debug info when evaluating remote(T1,@>$1). Looks like @> in > the remote reference is mapped to the last row of the current table, not > of the remote table. > > Substitution history of formula > Orig: remote(T1,@2$1) > $xyz-> remote(T1,@2$1) > @r$c-> (21) > $1-> (21) > Result: 21 > Format: NONE > Final: 21 > > Emacs : GNU Emacs 23.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.6) > of 2011-09-13 on shirley > Package: Org-mode version 7.7 >
