From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qMg/BH59ol8UUAAA0tVLHw (envelope-from ) for ; Wed, 04 Nov 2020 10:07:58 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id QCoTAH59ol8uegAAB5/wlQ (envelope-from ) for ; Wed, 04 Nov 2020 10:07:58 +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 85EA29404D3 for ; Wed, 4 Nov 2020 10:07:57 +0000 (UTC) Received: from localhost ([::1]:35760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kaFhs-0004sf-Fj for larch@yhetil.org; Wed, 04 Nov 2020 05:07:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kaFhD-0004r3-IS for emacs-orgmode@gnu.org; Wed, 04 Nov 2020 05:07:15 -0500 Received: from mail-pf1-x42d.google.com ([2607:f8b0:4864:20::42d]:39594) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kaFhB-0000Pv-MG for emacs-orgmode@gnu.org; Wed, 04 Nov 2020 05:07:15 -0500 Received: by mail-pf1-x42d.google.com with SMTP id z3so10511847pfz.6 for ; Wed, 04 Nov 2020 02:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=w0ouDiVRRkOZTrtn/QjFZnoTWFaW54vTpd8n1FzBebk=; b=cZXy/x5Yk1xATpCohoqAjZoRAqahyLl461+Enlj02k72wPJ7PiQ0ihk0bZTAIflz7B 6+ZeNK3ZS2HDguY8oieCVW2xadH/XfupYN8xWYx/i1c4CPCCUutHxoA1LqgaNpYwBmaK 8q0SlNtpYCvB2vmecYCiBpGtw8PKnGVIphOzOFv6Jr9CKkvglBfsEF58D2JyUbe5FAOk bXbydqNdQHSmE09tGY69Ltc1vkdbgVZKLXPgUq7267s1FeQfXQQ8H6IymOMn405Ksw1e zARI18uRJyC8QWLzgkCW4BVaE5DNEN2Zf/IQOZVVn6SUrzTpO7eE6C6kbMQ5z1FRme3Z Abjg== 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:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=w0ouDiVRRkOZTrtn/QjFZnoTWFaW54vTpd8n1FzBebk=; b=qkuOO14a83J9ed9GVvN4bmWI32Rt3KTGkfYVkMwFk4txXIvKiHm8vhvl/N72H3XyDH Nl5ObWCt44grqOCj7jf1gwjhFeYUEZ+Hy25v6nmtikC/75qZ8ItOqM4+Jc/Ns3QxZBBC G9vc71Ph8CbWOZDaw+liKhU0rLonwlD41NnMcD036Is3o5bp39pSEG25PTBoA/HTMYTF WtvKZZSIGWETV3RbwkTxHFGJ6zPftCN1pFpG+hqfCdP807KZGGPGNAB1hbXQnjRri+EX Uom3ZZ2wuOWe0/qFqhadGnD9/PYzyNHXNlSTtg4sMDmb8noLFRjqvCv9XEVBicDZWCt/ C+Dw== X-Gm-Message-State: AOAM533vdWiZunzG7IgtacdLkY5ucTD9JDTk+r/ecNPp8kLG1E0pIc3D mK2Knvz5IrbIGp/V80mWphzoK2AXW0I= X-Google-Smtp-Source: ABdhPJxpaCB9QVs9pMchydASAxqd16LzIjrULp4FIsMoLwXE44gDLMRJDsGNLc3kWVDHDvTS0YdNFw== X-Received: by 2002:aa7:96d7:0:b029:18a:b62f:3527 with SMTP id h23-20020aa796d70000b029018ab62f3527mr18616267pfq.53.1604484431769; Wed, 04 Nov 2020 02:07:11 -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 ca5sm1776112pjb.27.2020.11.04.02.07.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Nov 2020 02:07:11 -0800 (PST) References: <87k0v361x9.fsf@gmail.com> <877dr1scex.fsf@christianmoe.com> User-agent: mu4e 1.4.13; emacs 27.1 From: TEC To: org-mode-email Subject: Re: Tables: missing multi-col/row syntax Date: Wed, 04 Nov 2020 17:28:58 +0800 In-reply-to: <877dr1scex.fsf@christianmoe.com> Message-ID: <874km5saes.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::42d; envelope-from=tecosaur@gmail.com; helo=mail-pf1-x42d.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: , 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=cZXy/x5Y; 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: -0.21 X-TUID: 0GUUKvUS29gS I think we may be able get something promising by merging your (Christian + Tom) ideas and David's. What if we have have a #+TBLCELLMERGE key which acts as you describe, and /just using the current table syntax/ have something like this (using the example=20 from my first email) | a | b | c | |---+----+---| | hi || a | | two x || . | | three || b | | c | - | . | #+TBLCELLMERGE: @2$1..@4$2 This is /currently/ a valid Org table, which /currently/=20 autoformats to: | a | b | c | |-------+---+---| | hi | | a | | two x | | . | | three | | b | | c | - | . | So with an autoformatting change + an overlay, perhaps we can do=20 this nicely without any syntax changes =F0=9F=98=83. Thoughts? Christian Moe writes: > +1 for enabling table-cell merges in export. I imagine this=20 > would be a > tricky job for developers, but it would relieve me as a user of=20 > much > repeated fiddling with exported drafts. > > +1 for doing it without adding clutter to the table syntax, but > specifying merges on a separate line like formulas, like Tom's > > #+TBLCELLMERGE: @2..3$1 > > (amended here to use the established '..' rather than hyphen for=20 > range) > > Though if we do add such a line, we might also think of a more=20 > general > solution that could over time be extended with additional=20 > formatting > options, e.g. something like > > #+TBLSTYLE: @2..3$1=3D'(:merge t)::@4$1=3D'(:bgcolor yellow :color=20 > red) > > But obviously that could open a can of worms, aka potentially=20 > endless > feature requests requiring different implementations for each=20 > backend. > > Yours, > Christian > > > > Tom Gillespie writes: > >> Any support for something like this would need to retain=20 >> backward >> compatibility as well to avoid older versions reformatting the=20 >> tables >> due to e.g. the presence of a double pipe. I also think that=20 >> extending >> the table syntax in ways that makes it more complex than it=20 >> already >> is, will be a non-starter. Thus, an alternate but more likely=20 >> approach >> would be to allow specification of what cells to merge outside=20 >> the >> table as is done for formulas. It is not elegant, but it would=20 >> be a >> layer on top of existing syntax, and it would allow the=20 >> fundamental >> structure of the table to remain the same -- rows of cells. For >> example #+TBLCELLMERGE: @2-3$1 or something like that.=20 >> Thoughts? >> Tom >> >> 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=20 >>> 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=20 >>> (in >>> my >>> case, usually TeX + HTML). This is clumsy, difficult to work=20 >>> with, >>> and >>> could be avoided should org gain support for multi-col/row=20 >>> syntax. >>> >>> I appreciate that this would constitute a major change both=20 >>> the >>> Org's >>> syntax and the codebase, but I believe such a change is=20 >>> warranted >>> by the >>> advantages it would provide. >>> >>> Both how this can be implemented while minimising/eliminating=20 >>> the >>> chance >>> of breaking well-formed current table elements, and what=20 >>> 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=20 >>> "-". >>> 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=20 >>> hopefully >>> the >>> general form of this idea seems viable. >>> >>> All the best, >>> >>> Timothy. >>>