From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id uODYH2ILjl8EZQAA0tVLHw (envelope-from ) for ; Mon, 19 Oct 2020 21:55:46 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id KC2AG2ILjl/3RQAA1q6Kng (envelope-from ) for ; Mon, 19 Oct 2020 21:55:46 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4FBF19402A9 for ; Mon, 19 Oct 2020 21:55:45 +0000 (UTC) Received: from localhost ([::1]:52760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUd82-00036Y-Kr for larch@yhetil.org; Mon, 19 Oct 2020 17:55:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUd7L-00034p-Im for emacs-orgmode@gnu.org; Mon, 19 Oct 2020 17:54:59 -0400 Received: from grinta.net ([109.74.203.128]:43642) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUd7J-0005lq-A8 for emacs-orgmode@gnu.org; Mon, 19 Oct 2020 17:54:59 -0400 Received: from black.local (unknown [46.165.233.56]) (Authenticated sender: daniele) by grinta.net (Postfix) with ESMTPSA id 6AB29ED1F3 for ; Mon, 19 Oct 2020 21:54:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=2020; t=1603144494; bh=c/9ueo6t3XS4O33vGyqRsKboml1cDa0COJY2DezTSFA=; h=To:From:Subject:Date:From; b=kEoVQAb4FnYOAIklmVvloIKzDmcFNqIqN4UNDYiXFfa80rh/JM71MwOh8RN67Z4zo Nwrikl//5683wU0m2RbS5OUTMy+RPPJQDlPQ4ingySZSSYMrHOi7jagHSC6nGWoiQ2 DYGFqBFQjItlCFnCmuU6mz9zYzyDlLfIwN5RAkrlyCCs3EL95ChVjA54oujpb+6fs+ ce6jl+drndnTTG3J49bgprOQjsbrLyMVhXo9bZ30aV4ZM6RWx/JLZB3FI2SPyx3WpZ ux4hS9+OcuifpGrJXmyiAdAYNDZ2X55q46g9fqW2QNk98HNlfMjEhHhh1d3CA7bMvv y3cobQw1TSJFg== To: Org Mode List From: Daniele Nicolodi Subject: Specification for org-table formula mode string Message-ID: Date: Mon, 19 Oct 2020 23:54:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=109.74.203.128; envelope-from=daniele@grinta.net; helo=grinta.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/19 17:54:55 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=grinta.net header.s=2020 header.b=kEoVQAb4; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.01 X-TUID: 77iBcctnWA2w Hello, I am looking at the parsing of org-table formula mode strings and I find it quite confusing and I have an hard time understanding if it works the way it does by design or by accident. Formula mode strings are documented here https://orgmode.org/manual/Formula-syntax-for-Calc.html#Formula-syntax-for-Calc but the specification is not very strict and the parser implements surprising behaviors. Would it make sense to tighten the specification and the implementation? I think being a bit more strict is what is accepted would help catching typos and mistakes, but I am not sure that having formulas resulting in #ERROR upon an org-mode upgrade is desirable. Also, maybe a specific marker (#INVALID ?) should be used for invalid syntax. The main problem with the current parsing code is that any character that is not recognized as a valid mode flag is used as a value format string. For example: | 1 | 2 | OO3.000 | #+TBLFM: $3=$1+$2;FOO%.3f Is this by design? If so, what is the use case? Thus is slightly more surprising: | 1 | 2 | 3.000 OO | #+TBLFM: $3=$1+$2;%.3f FOO I argue the first form should result in an error. The second can either result in an error or in everything following the % sign to be used as a format string, although I am not sure there is a clear use case for this. Thank you. Cheers, Dan