From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: [bug?] Copy content from one to another table changes the content Date: Mon, 15 Jul 2013 09:36:03 -0400 Message-ID: <877ggseyik.fsf@gmail.com> References: <874nbxizti.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uyiwu-00026A-A6 for emacs-orgmode@gnu.org; Mon, 15 Jul 2013 09:36:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uyiws-00054X-3c for emacs-orgmode@gnu.org; Mon, 15 Jul 2013 09:36:20 -0400 Received: from plane.gmane.org ([80.91.229.3]:49988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uyiwr-00054C-TM for emacs-orgmode@gnu.org; Mon, 15 Jul 2013 09:36:18 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Uyiwo-0003qd-9q for emacs-orgmode@gnu.org; Mon, 15 Jul 2013 15:36:14 +0200 Received: from pool-108-7-96-134.bstnma.fios.verizon.net ([108.7.96.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jul 2013 15:36:14 +0200 Received: from ndokos by pool-108-7-96-134.bstnma.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jul 2013 15:36:14 +0200 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 Torsten Wagner 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 calc, which ends up in funny different results. > I do not understand what was the intention of letting the code be parsed by calc but it seems to cause trouble. > As I said, I don't know much about the implementation of tables, but I think passing every entry in the table through calc is by design. And it does not need to cause trouble either: (calc-eval "abc, def") ---> "abc, def" So trying to selectively *not* pass a cell through calc seems to be the wrong way to go. > Will test to comment how to get around it > > Thanks > Torsten > > On 15 July 2013 11:43, Torsten Wagner wrote: > > 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 just struggle with exactly those imaginary numbers and now there names > became a imaginary number itself... ;) > > Thanks for the tip, I will see if some search and replace helps me to create a intermediate solution. > > Thanks > > Torsten > > On 14 July 2013 05:29, Nick Dokos wrote: > > Torsten Wagner 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 formular I receive > > "lastname + firstnames i" > > > > I have totally no clue what is the reason for that.... a bug?! > > Happens within Org-mode version 8.0.3 > > > > I tried it (on a single table too - no remote) and I get the same > behavior. I can't pretend to understand how anything in org-table.el > works, but I think this is a clue: on line 2678, > org-table-make-reference is called. If I call it by hand like this > >   (org-table-make-reference "a, b" nil nil nil) --> "(a, b)" > > Then on line 2706, calc-eval is called. If I call it by hand on the > value above > >   (calc-eval "(a, b)") --> "a + b i" > > I think it's trying to do arithmetic on complex numbers... > -- > Nick > -- Nick