emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Eric S Fraga <e.fraga@ucl.ac.uk>
Cc: emacs-orgmode@gnu.org
Subject: Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
Date: Sat, 20 Mar 2021 08:33:04 +1100	[thread overview]
Message-ID: <8735wqn55u.fsf@gmail.com> (raw)
In-Reply-To: <87im5n9sjw.fsf@ucl.ac.uk>

Eric S Fraga <e.fraga@ucl.ac.uk> 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

> 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

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

  reply	other threads:[~2021-03-19 22:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 20:29 Syntax Proposal: Multi-line Table Cells/Text Wrapping Atlas Cove
2021-03-17 21:02 ` Daniele Nicolodi
2021-03-17 22:07 ` Juan Manuel Macías
2021-03-18 13:38   ` Atlas Cove
2021-03-18 14:04     ` Daniele Nicolodi
2021-03-18 15:15     ` Juan Manuel Macías
2021-03-18 14:19 ` Maxim Nikulin
2021-03-18 14:26 ` Timothy
2021-03-18 14:31   ` Atlas Cove
2021-03-18 21:58     ` Tim Cross
2021-03-18 22:41       ` Juan Manuel Macías
2021-03-19  8:08         ` tomas
2021-03-19  8:44           ` Juan Manuel Macías
2021-03-19  8:53             ` tomas
2021-03-19  9:22               ` Juan Manuel Macías
2021-03-19 10:14                 ` tomas
2021-03-19 10:53                   ` Juan Manuel Macías
2021-03-19 11:08                     ` Juan Manuel Macías
2021-03-19 13:43                     ` tomas
2021-03-19 15:07                       ` Juan Manuel Macías
2021-03-20 22:49         ` Samuel Wales
2021-03-21  8:43           ` Juan Manuel Macías
2021-03-19  2:27       ` Timothy
2021-03-19  3:50         ` Tim Cross
2021-03-19  4:02           ` Timothy
2021-03-19 13:33       ` Eric S Fraga
2021-03-19 21:33         ` Tim Cross [this message]
2021-03-20  9:19           ` Eric S Fraga
2021-03-20 10:40           ` Juan Manuel Macías
2021-03-20 13:41         ` Andreas Eder
2021-03-20 22:06           ` Tim Cross
2021-03-22 10:54             ` Eric S Fraga
2021-04-01  6:15       ` Tom Gillespie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735wqn55u.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).