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 |
|---+----+---|
| hi || a |
| two x || . |
| three || b |
| c | - | . |
#+TBLCELLMERGE: @2$1..@4$2
This is /currently/ a valid Org table, which /currently/
autoformats to:
| a | b | c |
|-------+---+---|
| hi | | a |
| two x | | . |
| three | | b |
| c | - | . |
So with an autoformatting change + an overlay, perhaps we can do
this
nicely without any syntax changes 😃.
Thoughts?
Christian Moe <m...@christianmoe.com> writes:
+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 <tecos...@gmail.com> 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.