From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id eJqDD79Q5V50PwAA0tVLHw (envelope-from ) for ; Sat, 13 Jun 2020 22:18:39 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id MKsyC79Q5V4MDgAAbx9fmQ (envelope-from ) for ; Sat, 13 Jun 2020 22:18:39 +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 A07009401CB for ; Sat, 13 Jun 2020 22:18:38 +0000 (UTC) Received: from localhost ([::1]:34944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jkEU1-0002s6-55 for larch@yhetil.org; Sat, 13 Jun 2020 18:18:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkETd-0002ry-T8 for emacs-orgmode@gnu.org; Sat, 13 Jun 2020 18:18:13 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:43293) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkETb-00008j-JW for emacs-orgmode@gnu.org; Sat, 13 Jun 2020 18:18:13 -0400 X-Originating-IP: 185.131.40.67 Received: from localhost (40-67.ipv4.commingeshautdebit.fr [185.131.40.67]) (Authenticated sender: admin@nicolasgoaziou.fr) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 986C8C0006; Sat, 13 Jun 2020 22:18:06 +0000 (UTC) From: Nicolas Goaziou To: Mario Frasca Subject: Re: [PATCH] allow for multiline headers References: <87wo4bhpkx.fsf@nicolasgoaziou.fr> Mail-Followup-To: Mario Frasca , emacs-orgmode@gnu.org Date: Sun, 14 Jun 2020 00:18:05 +0200 In-Reply-To: (Mario Frasca's message of "Sat, 13 Jun 2020 15:20:01 -0500") Message-ID: <87tuzeehk2.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=217.70.183.198; envelope-from=mail@nicolasgoaziou.fr; helo=relay6-d.mail.gandi.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/13 18:18:07 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN 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: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; 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: -1.01 X-TUID: 2LzBvmBCN5ps Hello, Mario Frasca writes: > is there an agreement on cl-lib usage within the project? Using cl-lib is OK, even though I wish we could use "seq.el" instead. > I was hinted at cl-loop in this mailing list, and I liked it, in > particular the `collect' clause, the destructuring feature, and less > parentheses. That's exactly my point. It does way too much, and it is very far from Lisp. Since it does so much stuff, it is tempting to use it all over the place, for every single iteration. And then, your code doesn't look like Lisp anymore. See how they defaced that poor "org-contacts.el" =3D/ > I can leave existing loops in peace, or edit them keeping them > cl-loop-free.=C2=A0 as for myself, I find it practical and readable. Then you'll enjoy reading, e.g., `org-contacts-try-completion-prefix'. FWIW, I don't. > this is not a correct description of the current status, at least not > within org-plot. > > (let ((table (org-table-to-lisp)) =E2=80=A6 > > in org-plot we expect either the first or the second element of > `table' to be a list; > > any leading `hline' is removed; I don't know Org Plot enough, but these expectations should be located in "org-plot.el". I expect `org-table-to-lisp' to be as faithful as possible. In particular, this function is used in `org-table-align'; as such, it should not do anything fancy. > a table looking like hline-header-hline-data is treated as having > a header, while your description says it's all data, no header, > because of the leading hline. The manual states: Rows before the first horizontal rule are header lines. But you are right, this is ambiguous.=20 Moreover, I mis-remembered how I defined header lines in the export framework. Per "ox.el", the header is the first row group. A row group is a group of one or more data rows located between row separators or table boundaries. This is more accurate than the above. > but in my opinion if there's any problem or misunderstanding here, > it's because there's no unit tests that describe the correct > behaviour.=C2=A0 can we work at that? Unit tests are not worth a formal definition. However, "test-ox.el" contains unit tests. > anyhow, what do you think of the multiple-lines-header option? Multiple lines header are already a thing, at least in the export framework. Try to export, e.g., | a | | b | |---| | c | in HTML. They are also assumed to be valid in the manual, per above. So, if your question is: "should Org support multiple lines headers?", I'd say that it already does, but it should definitely be made more consistent across the various libraries (e.g., Org Plot). Regards, --=20 Nicolas Goaziou