From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Bug: right-alignment fails in column view [9.0.7 (release_9.0.7-439-g2906e5 @ /home/tews/src/org-mode/lisp/)] Date: Mon, 22 May 2017 14:02:56 +0200 Message-ID: <87pof1f6a7.fsf@nicolasgoaziou.fr> References: <877f1e9tw5.fsf@cert.kernkonzept.com> <87inkvi8vn.fsf@nicolasgoaziou.fr> <87o9uljowp.fsf@cert.kernkonzept.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dCm3C-00049K-8y for emacs-orgmode@gnu.org; Mon, 22 May 2017 08:03:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dCm39-0002lh-7Q for emacs-orgmode@gnu.org; Mon, 22 May 2017 08:03:02 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:50201) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dCm39-0002lN-0t for emacs-orgmode@gnu.org; Mon, 22 May 2017 08:02:59 -0400 In-Reply-To: <87o9uljowp.fsf@cert.kernkonzept.com> (Hendrik Tews's message of "Mon, 22 May 2017 10:07:02 +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" To: Hendrik Tews Cc: emacs-orgmode@gnu.org Hello, Hendrik Tews writes: > I am not sure I understand the check > > (when (or (not (string-match-p "[0-9]" value)) > (and (string-match-p "[1-9]" value) > (= 0 (string-to-number value)))) > > before the error message. Wouldn't it be good enough to apply the > format on the result of string-to-number? This would permit to > have markers "TODO" or "XXX" without getting an error. The point is that format strings in summary operators are reserved for numbers. There is no point to have a "TODO" or a "XXX" value in a column that is summarized with {+;%.2f}. The intent of the check is to warn the user that a columns contains invalid values. Applying `string-to-number' unconditionally could give strange results for example, with {mean,%.2f}. > Moreover, the test is wrong for legitimate numbers such as "0e3" > while it permits non-numbers such as "1XX". I genuinely thought this would return "0". Anyway, the difficulty is to properly check we're applying the format string on numbers. It may not be possible to do so in the general case, so yes, we may fall-back to unconditional `string-to-number'. Regards, -- Nicolas Goaziou