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 SO7ECZBnoF+uGwAA0tVLHw (envelope-from ) for ; Mon, 02 Nov 2020 20:09:52 +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 cAXfBZBnoF+rfAAA1q6Kng (envelope-from ) for ; Mon, 02 Nov 2020 20:09:52 +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 ACA159401CD for ; Mon, 2 Nov 2020 20:09:51 +0000 (UTC) Received: from localhost ([::1]:51594 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZg9G-0007nc-Gf for larch@yhetil.org; Mon, 02 Nov 2020 15:09:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZg8D-0007lb-Gi for emacs-orgmode@gnu.org; Mon, 02 Nov 2020 15:08:45 -0500 Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]:34132) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZg8B-0003ct-LX for emacs-orgmode@gnu.org; Mon, 02 Nov 2020 15:08:45 -0500 Received: by mail-pl1-x629.google.com with SMTP id p4so59378plr.1 for ; Mon, 02 Nov 2020 12:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=uM17ZX4VJHD/HosLo4clxNhy1uzIt4gkJz2ZsDCLl6g=; b=UZTNvbx5nQYXtfPilpQ/dWncCk+D18bgcJBIGWQxvyyLgrmAqXiLB8Zp/0yfEhNWXv aFuvzTVlH4zmQEil8ivL2ntlPNDbk4bz2ymXvUmyHFMwUkXkzzoI4/onvZHn/Tpvh3Ai j7oXidIjRxM7MoBoS5EGE9MsNGscCebv52UANM5EAn2eethcSEGdiylcizlfOpmB8fS9 TloaHsjlhf0Is2X/pzCKpllKPK8sx5sCUA7sdeNi/BHmJAx0jnCzKUhplSDroBx6yCtT x/73nA/DPIAcsh9xONz9u0g8K3C2ybX+qWOwy8Ji2VGuW/7pDA+UX8rvp2qiTXWNKDOV 29Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=uM17ZX4VJHD/HosLo4clxNhy1uzIt4gkJz2ZsDCLl6g=; b=qZoIIAIKQoBZkWk3ObZLJevqBC4fjeU5vuMg8ilLexXTR2ZZ7N7t96O/9MwCDyQLDi tC5WNUHSR9GawhCwTfwWZYzspQ8ydCkF2rGg+ZVEBHWU4sLhln7Kk+DmYwUP8UNeqw11 rASWNvuXLHpdLeT2r68SDhOhR9GZuGhnyf4DQWGa1ww+cDTDzsCG2oTO7u/fblPUZfXp c/mWEdat7xcnJnXsi0uZDQZ/e0CJw5LNlxMlKOJ8LucBIOBEzQdztu81Xm9fkOl3rgM5 b8pnEzD/ts87TbRciZa4jiU+E9L1SRjo08Nikl8gFqqAtd+XEdzkKE/AJVgmlVZnnyBz BOSQ== X-Gm-Message-State: AOAM531i3H4G2z6qlfRkeHhthfrdIN6KsugofbhuIKzfD91vbVaZVkYa FqHpiON9PFQt2E42UYzefVI= X-Google-Smtp-Source: ABdhPJxfAwl/HkHH7HS5nJf40bAMwBPnRYIbQ/HZWqyCyXjVn8YBVtRhOWpYssKOyNzz1gqhbLYFvQ== X-Received: by 2002:a17:902:fe0f:b029:d6:cf9d:3260 with SMTP id g15-20020a170902fe0fb02900d6cf9d3260mr5424846plj.3.1604347722103; Mon, 02 Nov 2020 12:08:42 -0800 (PST) Received: from localhost (180-150-91-8.b4965b.per.nbn.aussiebb.net. [180.150.91.8]) by smtp.gmail.com with ESMTPSA id w4sm314582pjh.14.2020.11.02.12.08.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Nov 2020 12:08:41 -0800 (PST) References: <87k0v361x9.fsf@gmail.com> User-agent: mu4e 1.4.13; emacs 27.1 From: TEC To: Tom Gillespie Subject: Re: Tables: missing multi-col/row syntax Date: Tue, 03 Nov 2020 03:46:54 +0800 In-reply-to: Message-ID: <87iman5xoa.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Received-SPF: pass client-ip=2607:f8b0:4864:20::629; envelope-from=tecosaur@gmail.com; helo=mail-pl1-x629.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: org-mode-email Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=UZTNvbx5; dmarc=pass (policy=none) header.from=gmail.com; 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.71 X-TUID: BncX+eZg4cDJ Tom Gillespie writes: > Any support for something like this would need to retain > backward > compatibility as well to avoid older versions reformatting the > tables > due to e.g. the presence of a double pipe. I also think that > extending > the table syntax in ways that makes it more complex than it > already > is, will be a non-starter. I am also concerned with avoiding disrupting previous table. I think that non-space double+ pipes should be alright (hence their part in my suggestion) as it still maintains that the number of columns is equal to the number of pipes. E.g. currently || a | b | = 3 columns, and is reformatted to | | a | b | proposal || a | b | = 2 cells, 2+1=3 columns (same) > Thus, an alternate but more likely approach > would be to allow specification of what cells to merge outside > the > table as is done for formulas. It is not elegant, but it would > be a > layer on top of existing syntax, and it would allow the > fundamental > structure of the table to remain the same -- rows of cells. For > example #+TBLCELLMERGE: @2-3$1 or something like that. Thoughts? > Tom I like how this seems to address the issue while keeping backwards compatibility, but I have two big concerns: 1. I think this could make it hard to see which cells are 'masked' by a merge at a glance, and would make associated errors easy 2. I think that for say a table with 2-3 large sub-sections this could lead to problematic formating. Regarding 2, E.g. (content and form made up on the spot) | Powerpoint | Voltage ripple while drawing 2A continuous load over Xs | | | | | Current ripple while drawing 24V continuous load over Xs | | | | | | | | 1s | 5s | 10s | 20s | 30s | 1s | 2s | 5s | 10s | 20 | 30s | |------------+---------------------------------------------------------+----+-----+-----+-----+----------------------------------------------------------+----+----+-----+----+-----| | Kitchen | 3% | 2% | 3% | 1% | 2% | 1% | 4% | 3% | 5% | 3% | 2% | | Bedroom | 1% | 2% | 1% | 2% | 1% | 2% | 1% | 1% | 1% | 2% | 1% | #+TBLCELLMERGE: @2-6$1,@7-11$1 vs. | Powerpoint ||||| Voltage ripple while drawing 2A continuous load over Xs |||||| Current ripple while drawing 24V continuous load over Xs | | | 1s | 5s | 10s | 20s | 30s | 1s | 2s | 5s | 10s | 20 | 30s | |------------+----+----+-----+-----+---------------------------------------+----+----+----+-----+----+-------------------------------------| | Kitchen | 3% | 2% | 3% | 1% | 2% | 1% | 4% | 3% | 5% | 3% | 2% | | Bedroom | 1% | 2% | 1% | 2% | 1% | 2% | 1% | 1% | 1% | 2% | 1% | (NB: clearer without line wrapping, more concise examples definitely available if I thought about it a tad more) > On Mon, Nov 2, 2020 at 1:37 PM TEC wrote: >> >> Hi all, >> >> This is a pretty major 'feature request', but I think also an >> important >> one. >> >> When developing large tables, it can often be /necessary/ to >> start >> using >> multi-column/row cells for clarity, and sensible exporting >> results. >> >> As far as I am aware, in Org does not currently have any >> multi-col/row >> syntax. The only viable method seems to be re-implementing the >> table >> using export blocks in every backend you may want to export to >> (in >> my >> case, usually TeX + HTML). This is clumsy, difficult to work >> with, >> and >> could be avoided should org gain support for multi-col/row >> syntax. >> >> I appreciate that this would constitute a major change both the >> Org's >> syntax and the codebase, but I believe such a change is >> warranted >> by the >> advantages it would provide. >> >> Both how this can be implemented while minimising/eliminating >> the >> chance >> of breaking well-formed current table elements, and what syntax >> may be >> both acceptable and seem sensible to use. >> >> I would anticipate such a feature working by designating two >> characters >> to indicate "add row" and "add column". For example "|" and >> "-". >> These >> characters would take affect when /immediately following/ (no >> space) a >> cell separator ("|"), and designate the dimensions of the top >> right cell. >> >> Example: >> | a | b | c | >> |---+---+---| >> | a | - | | | >> | - | b | . | >> | . | | | c | >> >> Would be interpreted just as any current table is. >> >> However, >> >> | hello | there | you | >> |-------+-------+------| >> || two column | cell | >> >> Contains a 2x1 cell. >> >> | a little | test | >> |----------+------| >> |- hello | hi | >> | two row | you | >> >> Contains a 1x2 cell. In a more complex example: >> >> | a | b | c | >> |---+---+---| >> ||-- hi | a | >> | two x | . | >> | three | b | >> | c | - | . | >> >> Contains a 2x3 cell. >> >> This is just the first syntax that comes to mind, but hopefully >> the >> general form of this idea seems viable. >> >> All the best, >> >> Timothy. >>