From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id yKBqDpv4ZWNwSwEAbAwnHQ (envelope-from ) for ; Sat, 05 Nov 2022 06:46:03 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id aGh8DZv4ZWMIFAAAG6o9tA (envelope-from ) for ; Sat, 05 Nov 2022 06:46:03 +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 CC8D1FB3D for ; Sat, 5 Nov 2022 06:46:02 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orBz7-0007jE-9b; Sat, 05 Nov 2022 01:44:49 -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 1orByy-0007ip-6o for emacs-orgmode@gnu.org; Sat, 05 Nov 2022 01:44:45 -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 1orByk-0005VQ-2e for emacs-orgmode@gnu.org; Sat, 05 Nov 2022 01:44:39 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id C6731240026 for ; Sat, 5 Nov 2022 06:44:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667627061; bh=dv66ClS7JFoClvTYpaN+vzVDKnlJ/xhJYbkIm2Wt6OQ=; h=From:To:Cc:Subject:Date:From; b=XGxWpHjmKj8pTPxpZ4StRPUGZIPuzPJmsGgqF5FQLfZ2Ty1G6SDai7cP3Nb3kH2gY G56rS1DSqkRBUAeQzGexChnnyaFxH1TPHwChJwmq37V4TTYJluMgqvm8/FJxcA6Wac LsLrA14iuegtLKSvIfh/VcS8EqFT8X1V8PjcCczC+Kgb661NVTNCBF1a5x8Ri4KM0d oKQBwxPvSj4cYezEbqFsP7PFPv6BNVPxPkdcG37nfDwSNf9w2oMGj/qStSJpDuYnOJ 0xVooGMDHQiD+Wuvr34oEyxqzvPKlpCCwhztmUWeAlHHtYK60YxHcJSxevWPR6rXuA PqGiGxO1ektcg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N45z80ZN8z9rxH; Sat, 5 Nov 2022 06:44:19 +0100 (CET) From: Ihor Radchenko To: Max Nikulin 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> Date: Sat, 05 Nov 2022 05:44:59 +0000 Message-ID: <87fseykl9g.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: -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, 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=1667627163; 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=1k2e9Dht63Dm/1T1VTCZAc/U4ja+Wbhl9LIFbKfWmlA=; b=g8aKCoEJN8lKWzeIwCgyKcU8E7HtfW1JsZOm+Apr5CQX5Jdznomt5bY8Pn/SBfvWGvP73o FfljIEHHu9r9m8Grc7A/Ply8Stsfk8nAz5R56vcSs/g6yhXUl9HFWQdc/uiVKIk5hf+Lm1 I6x5+Qxk6tsw1udVmFQROIivcjcvSYTXHRdq5HqjgtbhAd0cu9UAmhBE94LiK6X9Kj+sp7 DC4b9c5PhEMmczQVCjv3czMmFBn47vYYOmbgSe7kW6t10+wt7Gyc7yDY066izxxTOA7nDJ LT30hX/xcjo+iuvi8J2UmGl5ocRsn3QirSU9jkMAVk0VOEMmDYZcKpajukA9fw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1667627163; a=rsa-sha256; cv=none; b=qhbFJWjXw+D5Ahsg3gY9tTMNoY+8N5gMzs8Vym8I+vEeMP4Oy9QzG6AfG5sd9DQ4WS5TKH 3kccrlFLCqGggUu3x+xaVFJtUqH7KS4pbiUKmgh+EvKMHY2fPo6qPbhNHRMcZIJ4DcT4EW IxcOiiWSZBFYeX9Qrr9eF7DvUk/7HyJ96hXna/pku/MhlWNG94JOYyRsA0FbAwBOtujbeQ AIPLW8pFf/85bdAt+5nSlc8a7GS6KSpIQtdQA0nKKyz9MQ/M2i3PN+jNzQprrhJ7WmnVzl wTdqxbIt5i9WvnA4lcPgKt+FWc1z0eC/j0F1FXQy8kQ2JNPNcLKPl9Fwm6sxEA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=XGxWpHjm; 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: -7.10 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=XGxWpHjm; 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: CC8D1FB3D X-Spam-Score: -7.10 X-Migadu-Scanner: scn0.migadu.com X-TUID: 5Jbv/TSNO7FN Max Nikulin writes: > I believe that tables in Org are already too complicated due to the > spreadsheet feature. They are, but merging cells is widely demanded. If we can come up with some reasonable extension of Org syntax, it will be a benefit for the whole Org community. > However those who are brave enough to add cells > spanning columns and rows may take some inspiration from > reStructuredText, in particular horizontal lines marked by "+===+===+" These are the table.el Emacs tables we already support (partially). Uwe's proposal is supporting table.el more fully, but it will be incompatible (if taken as is) with the current Org table syntax. We can learn from the design, but cannot just blindly re-use it. > Besides "grid" tables there are "simple" tables without vertical lines. That's similar to the ASCIIDoctor tables as I read it in the link. I do not think that it is a good option to move away from the visual table style employed in Org. > Perhaps it better to implement new table features as src blocks for some > new language and a dedicated Emacs mode. In the case of success such > proof of concept may be merged into Org core. That's what our table.el integration does. But it is not enough. Some features are only present in native Org tables and some features are only present in table.el tables. We will end up needing to extend either of the table syntaxes to obtain full Org table functionality. Then, it is better to extend native Org tables rather than replacing the existing table syntax with third party. > My impression is that Org tables quickly become hardly maintainable when > their complexity is above some quite low threshold. E.g. automatic > recalculation works only for first #+tblfm: line. It requires some > efforts to figure out association of particular formula with cell spans. I'd say that the problem is mostly with org-table.el which heavily relies on direct regexp matching. If we generalize things using parser, it should become easier to maintain even with merge cells. > Merge cells add more complexity to formula ranges. Some protocol should > be defined to allow source blocks to generate extended cells. Agree. And such protocol will improve maintainability even if implemented without extended cells. Either way, it is a good idea to refactor org-table.el -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at