Re: Tables: missing multi-col/row syntax

[TEC]

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 <mail@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 <tecosaur@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.