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 0OFuNAd0ol8meAAA0tVLHw (envelope-from ) for ; Wed, 04 Nov 2020 09:27:35 +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 SPpVMAd0ol8sFQAAbx9fmQ (envelope-from ) for ; Wed, 04 Nov 2020 09:27:35 +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 8B4CB9403E7 for ; Wed, 4 Nov 2020 09:27:35 +0000 (UTC) Received: from localhost ([::1]:53014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kaF4o-00039i-Hm for larch@yhetil.org; Wed, 04 Nov 2020 04:27:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kaF4N-00036j-LK for emacs-orgmode@gnu.org; Wed, 04 Nov 2020 04:27:07 -0500 Received: from mailer-211-160.hitrost.net ([91.185.211.160]:49555) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kaF4L-0002qN-Fv for emacs-orgmode@gnu.org; Wed, 04 Nov 2020 04:27:07 -0500 Received: from [84.20.244.182] (helo=Tauriel) by b1.hitrost.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1kaF4E-007U4m-MF; Wed, 04 Nov 2020 10:26:58 +0100 References: <87k0v361x9.fsf@gmail.com> User-agent: mu4e 0.9.19; emacs 25.3.2 From: Christian Moe To: Tom Gillespie Subject: Re: Tables: missing multi-col/row syntax In-reply-to: Date: Wed, 04 Nov 2020 10:23:50 +0100 Message-ID: <877dr1scex.fsf@christianmoe.com> MIME-Version: 1.0 Content-Type: text/plain X-GeoIP: Country [IP], SI [84.20.244.182] X-Antivirus-Scanner: Clean mail though you should still use an Antivirus Received-SPF: pass client-ip=91.185.211.160; envelope-from=mail@christianmoe.com; helo=mailer-211-160.hitrost.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/04 04:26:59 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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 , TEC 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=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: 0.49 X-TUID: RK/UKRX+nMF5 +1 for enabling table-cell merges in export. I imagine this would be a tricky job for developers, but it would relieve me as a user of 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 range) Though if we do add such a line, we might also think of a more general solution that could over time be extended with additional formatting options, e.g. something like #+TBLSTYLE: @2..3$1='(:merge t)::@4$1='(:bgcolor yellow :color red) But obviously that could open a can of worms, aka potentially endless feature requests requiring different implementations for each backend. Yours, Christian 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. 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 > > 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. >>