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 MAHjDsU25V7BGAAA0tVLHw (envelope-from ) for ; Sat, 13 Jun 2020 20:27:49 +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 YGKrCsU25V71NgAAbx9fmQ (envelope-from ) for ; Sat, 13 Jun 2020 20:27:49 +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 9133294042C for ; Sat, 13 Jun 2020 20:27:48 +0000 (UTC) Received: from localhost ([::1]:43956 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jkCkl-00012Z-Hc for larch@yhetil.org; Sat, 13 Jun 2020 16:27:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52204) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkCkP-00012M-PS for emacs-orgmode@gnu.org; Sat, 13 Jun 2020 16:27:25 -0400 Received: from devianza.investici.org ([198.167.222.108]:50927) by eggs.gnu.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkCkN-0006JI-6V for emacs-orgmode@gnu.org; Sat, 13 Jun 2020 16:27:25 -0400 Received: from mx2.investici.org (unknown [127.0.0.1]) by devianza.investici.org (Postfix) with ESMTP id 16F58E05CC; Sat, 13 Jun 2020 20:20:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anche.no; s=stigmate; t=1592079629; bh=MMWuYRDhJpSzLpWdT2w0G1p5/B/ruHLNLBwxa7q7Wqo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=eblb3v/pmuDbRwhYRR7OcfroyV9j3gyVoM2Tb5S0LdGAI88bgdOnwZRoh/LffP2z5 gMqlhD5RIG7hirNXznZ5fGbTBG6Acke5pM55UGH4w5F+97JtxQ2Lsc98H+Ni40A4S3 1iLsDyt+rLTTuMjRtge1Gc2+0ix1PAjdklBLFg8Q= Received: from [198.167.222.108] (mx2.investici.org [198.167.222.108]) (Authenticated sender: mariotomo@inventati.org) by localhost (Postfix) with ESMTPSA id 268DFE05C9; Sat, 13 Jun 2020 20:20:27 +0000 (UTC) Subject: Re: [PATCH] allow for multiline headers To: emacs-orgmode@gnu.org References: <87wo4bhpkx.fsf@nicolasgoaziou.fr> From: Mario Frasca Message-ID: Date: Sat, 13 Jun 2020 15:20:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <87wo4bhpkx.fsf@nicolasgoaziou.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Received-SPF: pass client-ip=198.167.222.108; envelope-from=mario@anche.no; helo=devianza.investici.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/13 16:20:29 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=anche.no header.s=stigmate header.b=eblb3v/p; 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.21 X-TUID: acu6uAZSZjWE hi Nicolas, is there an agreement on cl-lib usage within the project?  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.  I had no exposure to cl-loop before the hint received here. I can leave existing loops in peace, or edit them keeping them cl-loop-free.  as for myself, I find it practical and readable. let's say I'll try to limit usage. On 12/06/2020 17:44, Nicolas Goaziou wrote: > Also, the first hline is used to determine where to end the header. > A table starting with a hline has no header. Therefore, I suggest to > avoid removing hlines at the beginning of a table, we would lose > information. this is not a correct description of the current status, at least not within org-plot. (let ((table (org-table-to-lisp)) … in org-plot we expect either the first or the second element of `table' to be a list; any leading `hline' is removed; if the second element of `table' is a hline, the first element of `table' is considered to be the header (in this case -and only in this case- any subsequent `hline' is then removed from `table'); the presence of hline elements in `table' will crash the routine. ---------------------- 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. 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.  can we work at that? in fact, there's not even a org-table-headers function, that would return the table headers. anyhow, what do you think of the multiple-lines-header option? MF