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
from
my first email)
| a | b | c |
+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,
TEC writes:
David Rogers writes:
IMO this can (and definitely should) be regarded as a purely
cosmetic problem,
to be resolved by purely cosmetic methods. I think the idea
that each table cell
is exactly one unit of information (and can’t be a collection
or array of units
of information)
David Rogers writes:
IMO this can (and definitely should) be regarded as a purely
cosmetic problem,
to be resolved by purely cosmetic methods. I think the idea that
each table cell
is exactly one unit of information (and can’t be a collection or
array of units
of information) is more
TEC writes:
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.
IMO this can (and definitely should) be regarded
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
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
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
