From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id +J30JFInVWCpaAAA0tVLHw (envelope-from ) for ; Fri, 19 Mar 2021 22:36:02 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id EC22IFInVWCMEAAAbx9fmQ (envelope-from ) for ; Fri, 19 Mar 2021 22:36:02 +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 7243C18057 for ; Fri, 19 Mar 2021 23:36:01 +0100 (CET) Received: from localhost ([::1]:42170 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNNiq-0002a8-GQ for larch@yhetil.org; Fri, 19 Mar 2021 18:36:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44002) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNNiA-0002Zc-FG for emacs-orgmode@gnu.org; Fri, 19 Mar 2021 18:35:18 -0400 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:46799) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lNNi8-0001Eg-Gw for emacs-orgmode@gnu.org; Fri, 19 Mar 2021 18:35:18 -0400 Received: by mail-pl1-x634.google.com with SMTP id t20so3600993plr.13 for ; Fri, 19 Mar 2021 15:35:15 -0700 (PDT) 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=Ba32ZbJBSZASDyVHEWwaxL9pOoTxzfW3bAAyFd/eTP0=; b=unE3IDKST85vTqdammTWAucQyyhaGmba+NxyT6zlPmnLU0pgBlm5ns49jBtS/9fkio rnr+f7d4mWR+XpJ9GSPMlyVMeJA5QpBKnd5cL2iQKMTtlQpORkxi2COg9K4fSrBJcCW4 NTluiUe0WXntVFxzCrb1QfyHpv0Lf8KISskZlznWA/Tw2w4w/27gOGXuYR+NtDTf6igK 3kBmISEM0aQElf81P0J3eFl25e0NTyP3NlJFjPr5vKkc4GuuDOQ2L4xZJj7fMEMWdtPe e5CN53PQpqmqohXr1VEwQesDya4tmSDrkLeVkwnqYaWNll/6QWY2HJwI4XS9Tj0A+zCL 1Xeg== 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=Ba32ZbJBSZASDyVHEWwaxL9pOoTxzfW3bAAyFd/eTP0=; b=e37ZtqShojN5qO9qwKynLSLigcP7oiG3pFs+nNPyW0eo1RvlsgecCECfWnQAYDqBQ1 LYTzQdiYKNvYb79n1WJTWnRiVYAUu86ITWX90KVi0b68yGoHDFq8XYLr++qUICUFn3XL 8aeGl59kNw0CbcSw10FKl0LSiCCzHE2R6uX/QhB75WRI8gXPlsQydf6bBhlFTCdZ1kV/ bEtjrikL95iOiazCB3zEprWQAtdPmnITLe91iOYy+e/u5t3gRZSLJO4PBAd+t/VJpYmw 0tb5ndXZMwA+aaLfCjli5crUXHCbsYtTMaRVw00iSzRa5YUbxa4VtpM9wsjmk4FgPrkI Lkbw== X-Gm-Message-State: AOAM533d09GgaI4NKlKlXTWS8x7u7xzlVcqeWYTMr0ZydINrR/QStuXp yolEwRgBaiRSWbyf1XN6w+VvduZVusY= X-Google-Smtp-Source: ABdhPJzzZBOW6WsQdMuhU2c3eHMQgnwn38lDu613xP5qPyvE0lgvzkJ5zGljonpNmESfAgWIZMI88Q== X-Received: by 2002:a17:90a:fb8e:: with SMTP id cp14mr735839pjb.52.1616193314243; Fri, 19 Mar 2021 15:35:14 -0700 (PDT) Received: from tim-desktop (106-69-126-4.dyn.iinet.net.au. [106.69.126.4]) by smtp.gmail.com with ESMTPSA id d10sm6367033pgl.72.2021.03.19.15.35.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Mar 2021 15:35:13 -0700 (PDT) References: <7a450ea3-b0e4-3322-04cd-fb5a5a555db8@gmx.com> <87o8fgwn9s.fsf@gmail.com> <9533dd41-ec81-43dd-8d25-a41300eb720c@gmx.com> <87czvw85ym.fsf@gmail.com> <87im5n9sjw.fsf@ucl.ac.uk> User-agent: mu4e 1.5.11; emacs 27.1.91 From: Tim Cross To: Eric S Fraga Subject: Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping Date: Sat, 20 Mar 2021 08:33:04 +1100 In-reply-to: <87im5n9sjw.fsf@ucl.ac.uk> Message-ID: <8735wqn55u.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::634; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x634.google.com 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: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1616193361; 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=Ba32ZbJBSZASDyVHEWwaxL9pOoTxzfW3bAAyFd/eTP0=; b=oVyu8HoKDyM8Aiy98Ho0aK08/w5wDyZ0OurFJ4/yy5xg3dNyt6CER5bVv9hQXX3SWeZ8Qa i5MHs0k5Z7bLVAGu6CDtjE+VFxdv3rfoEX8vxZYa1uS9LBZmrRPNcMe/nK+Cq6t5Cl0NrI g/Qdj4m14X0YImhi/iD1Mi4+RHO12dDvWm9qc3OM/KnB3nohrplCKO9S3EeNwe+M9BbyYt /QILiV3bPeogLAPJ6GNOj+5bX5k6CSrG57UCVGyMDzXTFYVkWNw2vwS/caZhOvZR6oyYes b0lSvuh5IdJkBJ8VsKXbjzf1EtJv1YYFdey97p8uBEhpyO2Kr3trRl3WYAndZA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1616193361; a=rsa-sha256; cv=none; b=bgmdsQok8wrtxAloOefbW19mPw2floYOU+bleI+489OVAR/M1XwXxrEJXIL667rAwn7U06 AKxHoG78sVwpwBEl807NqeveB9fPgRHiqjz1DJlxHJanHlm0qWPZ8x6t5cL4x5F48LYplk QBMjKT3fVRHZRPxqvOYva5UkDTwD15yJwqvzlfH+wPhg3ZOSTJgCVLsXeWgMjAT+zDflVg ALFl7+ALBWy0BFN+phf1aJfCbux2LAH1RRQaWx/IsgQShotivbDngOz32oMSfU21YDOBlZ +B+Dgl1sTQj6BYzlb/9VnyzFcRTEnwBjg2KmiC9JEWXgL30q1mBSUicG12F6TQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=unE3IDKS; 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-Migadu-Spam-Score: -3.11 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=unE3IDKS; 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-Migadu-Queue-Id: 7243C18057 X-Spam-Score: -3.11 X-Migadu-Scanner: scn0.migadu.com X-TUID: HrEHmoif21yE Eric S Fraga writes: > On Friday, 19 Mar 2021 at 08:58, Tim Cross wrote: >> I am a little concerned about the expansion and addition of features in >> org mode when there seems to already be a challenge with respect to >> maintenance and bug fixing. Personally, I would prefer an org mode which >> is consistent and reliable over one with large numbers of features that >> is less stable and slower. > > +1 on this. > > With respect to the topic at hand, I believe it's the result of the same > tendency that Excel users have of using spreadsheets (aka tables) for > everything, something I hate when I'm given some Excel sheet that I need > to modify and where entries are huge paragraphs. The UI in Excel is > horrible for these types of tables. I would hate to see org go in the > same direction. > Those excel 'workbooks' are the absolute worst. I sometimes wonder if project managers would be more popular if they hadn't decided to use that as their primary tool. The UI to navigate through those spreadsheets is horrible. The other problem is that tables with large cells of 'paragraph' like data are not terribly nice from an accessibility perspective. They can be difficult to navagate and things like screen readers can find it difficult to 'render' the content in a sensible manner i.e. where the spoken representation 'makes sense'. It has also been stated that the Latex exporter won't be a problem as tabularx (and other Latex packages) will just handle this. Sadly, I don't think it is that simple. I have used that package a lot over the years and there have been times I've had to render tables with multiple columns and rows. While the various latex table like packages do provide a much better outcome for tables with more complex cell structure, it is rare that you don't need to do a fair amount of tweaking to actually get good looking complex tables. Handling a cell with a couple of lines may be fine, but it is very easy to hit the limits of what the package can handle without some tweaking. This is where I think things begin to fall down. My suspicion is that the amount of work needed to make the Latex exporter handle the majority of common use cases for this new syntax is much larger and more complex than it seems and getting this to work reliably and consistently will be extremely difficult. We can be pretty certain that if we introduce some additional syntax to allow for multi-line cells and perhaps multi-row+multi-column cells, if the exporters do not render good looking output for every use case, bugs will be reported. I also have no idea how this will impact some of the other exporters, such as odt, texinfo etc. I do think we can probably add additional functionality to make working with more complex tables in org files somewhat easier from an editing perspective. I do have some concern over the potential performance impact, but in general, feel this is probably the easier part of the challenge. > In many cases, I believe that a simple text based database format would > be more appropriate. I wonder if the time would be better spent > providing native support for GNU recutils [1] in org instead. It could > even have a table like export... > That would be an interesting exercise. However, it does add another dependency and in some ways breaks the 'everything as text' philosophy (though I guess the last 'rendering' in the org file is still all text). To some extent, discussions like this remind me of the early days of the web where tables were used as the primary formatting 'tool'. Remember those horrible web pages which consisted of deeply nested tables? We learnt pretty quickly what a bad idea that turned out to be. I wonder if part of the issue here is with the different characteristics of displays and formatted or printed output. Displays have the property of being 'infinite' - a row can be as long as you like and a column can be as high as you like. With the growth in large screens many users now have windows far wider than the old 80 characters that were standard in old terminals. This tends to make tables a more appealing 'layout' facility as you can have a number of columns with multiple rows fitting on the screen. However, now you have a new problem - how do you map this very wide structure to a fixed width, relatively narrow, sheet of paper? The advantage of 80 characters was that generally, you could fit that on a standard sheet of paper. It is also a good width for reading, allowing you to take in multiple 'blocks' of text at a time. Really wide text can look ok, but many find such wide text more difficult to read as you have to scan long lines and cannot easily take in a 'block' at a time. I think there is probably some very good reasons multi-row cells were not supported in org mode initially. I suspect the reasons are not necessarily obvious until you try to implement such support. I could also be completely wrong and the issues I've seen in dealing with such tables in Latex are due solely to me not using the available facilities correctly. For this reason and because this question does seem to come up fairly regularly, my recommendation is to create a new feature branch and let those who are interested in supporting this proposal work on it. I would encourage them to keep good notes (and include them as a file in the feature branch) so that we have a record of the process. Once it becomes mature enough and works with all the bundled exporters, the rest of us can try it out and provide additional testing, verification of backwards compatibility and assessment of any performance implications. If it all goes well, then we could consider merging it into the main branch. If it fails to reach maturity or creates problems or for some other reason cannot be brought into the main branch, we would at least have this as a record and perhaps a starting point for the next time someone raises the question of multi-line table cells. -- Tim Cross