From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id gJFlGlqMX2PB2gAAbAwnHQ (envelope-from ) for ; Mon, 31 Oct 2022 09:50:34 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id kI9dGVqMX2NzUgEAG6o9tA (envelope-from ) for ; Mon, 31 Oct 2022 09:50:34 +0100 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 1D6E62E80E for ; Mon, 31 Oct 2022 09:50:33 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opQUJ-0003ho-4Q; Mon, 31 Oct 2022 04:49:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opQUE-0003hL-HK for emacs-orgmode@gnu.org; Mon, 31 Oct 2022 04:49:42 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opQU7-0006Yq-Lq for emacs-orgmode@gnu.org; Mon, 31 Oct 2022 04:49:37 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4E1F8240027 for ; Mon, 31 Oct 2022 09:49:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667206165; bh=7wMuPlorqXru97b8j2n+Jd6LY9uF8QU3LOqm2XxBZpk=; h=From:To:Cc:Subject:Date:From; b=PC7+D3MLR0/o6DMlH3EcZr/baSIEV+ALvyxq0djqJeI+qBP4ksKN73u7xnYt1EHqF RneTagUpcgSH1bCj3s2hZcaPPVNstYOm/TMDJqjKXmdoIuhuWrcXFPc5t8fmJWBBYi //HoysewYSG0sLiI2tXpZOj32CPZ/9X4gj0oYLhCDwzgz+mrzoHV4zK5zpkOSWjiBb kfu1Z1/9tuF1bpDdyGIDsPzS2zBFz7f4uuu767adc2wywlXlxFLvQsQ1x1ePMsbLOR /c9VpjfY22k2+nG7oCwK0vFKTQn3kqvn8oPSmQXqG8vMZBLrkg4lf/XqYJdVkKsjjZ yiYeYTUJlePaQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N16K00Xlvz9rxD; Mon, 31 Oct 2022 09:49:23 +0100 (CET) From: Ihor Radchenko To: Jean Louis Cc: emacs-orgmode@gnu.org Subject: Re: org table proposal: merge and split cells in org-tables In-Reply-To: References: <877d0ia7vd.fsf@mat.ucm.es> <87leoxoe75.fsf@localhost> Date: Mon, 31 Oct 2022 08:50:02 +0000 Message-ID: <874jvkjs1x.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, SPF_HELO_NONE=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.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Emacs-orgmode" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1667206234; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=+1W7/JUpXMwjgUAwgXB7wlUApeoT/sndqTv7UH1xj7Y=; b=VXtJYuVaIKRTstCSBtVRsE11eNcZt1YVBzp3EuY9NK17cCY5dNrAQ6XWOqkEM7Ga4stkH4 k9id/JZbhkwJq6DoUABIby9Cfeyx9kwOfUCJZFrMhfpuaUNH6ES5yi87/xDphl0RCg3sGO PTvFeZmdmWtiDsd2hNLsjBA8WHDu9cS2Ga/6MFJhaqcM1QNM+Z5Z+LlYPxKaUcEjZZbekK sB6QxsNc1TDUg9ba6dfKyxAq/kOr6Mkc89LyypMLWC+oxRXPoWKUMLFW1yVDWgPY1LSPFN DrJuEYAsmk7dhulN+N3ntD7PY9+9r0A33IF7PnqLVxuTylRTPwl5Vko2bJQE0w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1667206234; a=rsa-sha256; cv=none; b=AkjZVY6XloYQxyEHCn6J3u4WZ6ZPasPQuP3z6wbbsjTTB4u5ZPe3Ll913pPgLpsNv+WZBM +wYT9dKaLoWddWNlAOHutKPN4i2YRCms38re5z0kDbu9TYGFvvlqbIZnEQ/ukPYO6NCSHf 8N6BrxPXWbRNIBGQlwg44KjbCYVVpxqyaz6UK/MZyTSvG8koi6lW+IOtZJ76lpeHbZwQ2W Kv+NlerZTPtBg0dQ7r3JxW3p0qENRu3+Lak5YKXsanXU5xIvX3ler/vZLf6Sp/iBR3AG0I Rp1+nHqhDgPruwhVLqN64/NKyZp1DSc0bB1AD1C54PIV1AjulL4oiEr2CST5xw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=PC7+D3ML; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.96 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=PC7+D3ML; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 1D6E62E80E X-Spam-Score: -4.96 X-Migadu-Scanner: scn0.migadu.com X-TUID: kxlZGLLbyAfu Jean Louis writes: >> I am sorry, but this looks unreadable. I would avoid re-using such >> syntax ideas. > > You have got an extreme reference on what can be done. Other people > and other projects have faced same issues as you are facing in Org > mode, and have resolved it. To understand anything one cannot just > read simple reference, but better understand the surrounding meanings, > the context. Indeed. I was expecting a link describing the concepts. What your provided was not very helpful. > Org tables are nothing harder or simpler than tables in other > lightweight markup languages. Somewhat harder. Somewhat simpler. We do not support some features ASCIIDOC supports. ASCIIDOC does not support spreadsheet features of Org tables. That's why we need context. We cannot blindly copy from ASCIIDOC. > What appears "unreadable" to you is readable to other > person. In fact, there is no single char in the extreme example of > Asciidoc table below that you can't read. The meaning of > "unreadable" is most probably "not understandable". Sure. But we have different proposals in the previous emails. Compared to the existing proposals, this looks unreadable. (which does not mean that it is worse - maybe ASCIIDOC has more flexibility; but less readable compared to other proposals for sure). > In fact, looking into functionality of other lightweigh markup > languages may only be helpful for Org development. > > For [cols="e,m,^p,>s",width="25%"] look here: > https://docs.asciidoctor.org/asciidoc/latest/tables/format-column-content/ > Thus `e' before first comma, means emphasized (I guess) and in fact on > the original demonstration one can see that first column is > emphasized. > > The fact that one may "describe" column's font style in Asciidoc(tor) could > be adopted as well in Org mode. Thanks for the link! This specific link is out of scope of this discussion (I do not think that we need to specify formatting for the whole column), but another link nearby looks more useful: https://docs.asciidoctor.org/asciidoc/latest/tables/span-cells/ > I would like it if Org mode could provide such functionality for > tables, to specify various attributes for columns. It does provide, > though I am not sure if it can provide so many. Please open a discussion about other attributes in a separate thread. Let's stay on the topic of merging cells and columns in this thread. It is already difficult enough. > It is good to read about span factor: > https://docs.asciidoctor.org/asciidoc/latest/tables/span-cells/ I think a slightly more clear example is (from the link; they also provide how html export of the below table looks like) |=== |Column 1, header row |Column 2, header row |Column 3, header row |Column 4, header row |Cell in column 1, row 2 2.3+|This cell spans columns 2 and 3 and rows 2, 3, and 4 because its specifier contains a span of `2.3+` |Cell in column 4, row 2 |Cell in column 1, row 3 |Cell in column 4, row 3 |Cell in column 1, row 4 |Cell in column 4, row 4 |=== I can see the idea here. For columns, it is similar to Timothy's ||||, but uses a number. For rows, I'm afraid that we cannot use the same approach because of conceptually different table structure. Takeaway: TEC's: |---- |||||||| Sales | can become |---- 2+| Sales | > One need not wait for that feature X to be implemented in Org, while > there is plenty of available options to reach the purpose of feature > X. > > #+BEGIN_SRC shell :results raw > echo " > [cols=\"e,m,^,>s\",width=\"25%\"] > ... > |=== > " | asciidoctor -e -o - - > > #+END_SRC Indeed. But it is not what we are discussing here. We are discussing concrete ideas to implement feature X. X being merged table cells. Let's not sidestep into other topics. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at