Hi again,
I think I got a bit more of an idea what is going wrong thanks to Nick.
I use $1 = remote(prf94120_orig, @@#$6)
which reads copy from table prf94120_orig row (@) of the current to be
processed field (@#) column ($) 6 into column ($) 1.
The org-mode manual refers to @# as operator
Hi Torsten
On Tue, Jul 16, 2013 at 12:24 PM, Torsten Wagner
torsten.wag...@gmail.com wrote:
Either, I should use a different way to copy the column or this could be
considered as a bug?!
Some time ago I did some experiments about just copying a field that I
put into the ERT function
Hi Nick,
very good observation. Just wonder are we the first who observe this
problem?!
It seems org-table-make-reference and calc-eval have some sort of an
different idea of the data content.
Yes calc use that notation to deal with imaginary numbers. Funny
coincidence, the students in that list
Hi again,
I can confirm that behaviour for org-mode 8.0 (tested on 7.9.3f) if that
matter.
Furtermore, I tested a lot of alternatives.
lastname, firstname
lastname, firstname
lastname; firstname
etc.
It seems, they all get somehow evaluated by calc, which ends up in funny
different results.
I do
Torsten Wagner torsten.wag...@gmail.com writes:
I can confirm that behaviour for org-mode 8.0 (tested on 7.9.3f) if that
matter.
Furtermore, I tested a lot of alternatives.
lastname, firstname
lastname, firstname
lastname; firstname
etc.
It seems, they all get somehow evaluated by
Hi,
I just notice a strange behaviour within tables. I want to copy a column of
one table into another... using $1=remote(prf94120_orig, @@#$6). The
original content consist of names in the form lastname,firstnames.
However, executing the above formular I receive lastname + firstnames i
I have
Torsten Wagner torsten.wag...@gmail.com writes:
I just notice a strange behaviour within tables. I want to copy a
column of one table into another... using $1=remote(prf94120_orig,
@@#$6). The original content consist of names in the form
lastname,firstnames. However, executing the above
