Re: org table proposal: merge and split cells in org-tables

Re: org table proposal: merge and split cells in org-tables

[Mati]

I don't know is this helpful, but on reddit some people mentioned that 
cell-mode is very promising for tables. Maybe it can ease table 
development. I'm not into programming at all so I can't evaluate.

Re: org table proposal: merge and split cells in org-tables

[Ihor Radchenko]

Mati <mati@electrum-bikes.pl> writes:

> I don't know is this helpful, but on reddit some people mentioned that 
> cell-mode is very promising for tables. Maybe it can ease table 
> development. I'm not into programming at all so I can't evaluate.

While cell-mode (https://gitlab.com/dto/cell-mode) is a nice idea, but
it is not plain text. I doubt that we can get much inspiration from
there.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org table proposal: merge and split cells in org-tables

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

Hi Ihor,

> While cell-mode (<https://gitlab.com/dto/cell-mode>) is a nice idea, but
> it is not plain text. I doubt that we can get much inspiration from
> there.

This reminds me that ages ago I made a proposal about multi-row/column cells, it
might be worth reviving that at some point?

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.

Re: org table proposal: merge and split cells in org-tables

[Ihor Radchenko]

Timothy <orgmode@tec.tecosaur.net> writes:

> This reminds me that ages ago I made a proposal about multi-row/column cells, it
> might be worth reviving that at some point?

https://orgmode.org/list/878rkyarvm.fsf@localhost, which is the
exact discussion herein.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org table proposal: merge and split cells in org-tables

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

Hi Ihor,

> Timothy <orgmode@tec.tecosaur.net> writes:
>
>> This reminds me that ages ago I made a proposal about multi-row/column cells, it
>> might be worth reviving that at some point?
>
> <https://orgmode.org/list/878rkyarvm.fsf@localhost>, which is the
> exact discussion herein.

Ah, I’ll move there. I suppose this is a downside to taking a LIFO approach to
my inbox 😅.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.

org table proposal: merge and split cells in org-tables

[Uwe Brauer]

Hi

This subject is brought up regularly. 

In a conversation with Ihor Radchenko it was considered as being helpful
to provide a table in which cells are merged and split.

Here is one

+--------+-------------------------------------------------+
| Region |                      Sales                      |
|        +-------------+-----------+-----------+-----------+
|        |      Q1     |    Q2     |    Q3     |    Q4     |
|        +-------+-----+-----+-----+-----+-----+-----+-----+
|        | foo   | bar | foo | bar | foo | bar | foo | bar |
+--------+-------+-----+-----+-----+-----+-----+-----+-----+
| North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
+--------+-------+-----+-----+-----+-----+-----+-----+-----+
| South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
+--------+-------+-----+-----+-----+-----+-----+-----+-----+

Or better




------------------------------------------------------------
| Region |                      Sales                      |
|        ---------------------------------------------------
|        |      Q1     |    Q2     |    Q3     |    Q4     |
|        ---------------------------------------------------
|        | foo   | bar | foo | bar | foo | bar | foo | bar |
------------------------------------------------------------
| North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
------------------------------------------------------------
| South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
------------------------------------------------------------





-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: org table proposal: merge and split cells in org-tables

[Ihor Radchenko]

Uwe Brauer <oub@mat.ucm.es> writes:

> In a conversation with Ihor Radchenko it was considered as being helpful
> to provide a table in which cells are merged and split.

We should consider this idea seriously as this and related features are
being requested frequently in the community. I recall the following
contexts:

- Support merging cells when exporting to LaTeX tables
- Text filling inside tables

> Here is one
>
> +--------+-------------------------------------------------+
> | Region |                      Sales                      |
> |        +-------------+-----------+-----------+-----------+
> |        |      Q1     |    Q2     |    Q3     |    Q4     |
> |        +-------+-----+-----+-----+-----+-----+-----+-----+
> |        | foo   | bar | foo | bar | foo | bar | foo | bar |
> +--------+-------+-----+-----+-----+-----+-----+-----+-----+
> | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
> +--------+-------+-----+-----+-----+-----+-----+-----+-----+
> | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
> +--------+-------+-----+-----+-----+-----+-----+-----+-----+

This essentially suggests supporting table.el syntax natively. Or maybe
extending it by mixing with native Org tables.

In terms of syntax, adding cell boundary support might be simply a
question of allowing +----+ in Org tables. It will not break anything as
we already parse +-----+ as table.el tables.

At lower level of org-element representation, we do not need to change
much either. table-row elements are already not tied to a fixed number
of cells in every row. And we may extend table-row 'rule type to define
the "+----+   +   +---+--+" cell boundaries.

However, in order to support merging cells, one needs to rework Org in a
number of places. At least:

1. org-element parser and interpreter
2. org-table.el in its totality
3. export backends
4. table formulas; in particular, cell references
5. update syntax document

> Or better

> ------------------------------------------------------------
> | Region |                      Sales                      |
> |        ---------------------------------------------------
> |        |      Q1     |    Q2     |    Q3     |    Q4     |
> |        ---------------------------------------------------
> |        | foo   | bar | foo | bar | foo | bar | foo | bar |
> ------------------------------------------------------------
> | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
> ------------------------------------------------------------
> | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
> ------------------------------------------------------------

This will clash with horizontal-rule syntax. Not acceptable. Also,
parsing this kind of table will be significantly harder programatically.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org table proposal: merge and split cells in org-tables

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 3741 bytes --]

>>> "IR" == Ihor Radchenko <yantar92@posteo.net> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>> In a conversation with Ihor Radchenko it was considered as being helpful
>> to provide a table in which cells are merged and split.

> We should consider this idea seriously as this and related features are
> being requested frequently in the community. I recall the following
> contexts:

> - Support merging cells when exporting to LaTeX tables
> - Text filling inside tables

I would suggest that filling, might be the point to start, since this
the lack of this feature is one of the inconvenience of org-tables.

I am sometimes running org-table-wrap 
found in 
https://github.com/analyticd/org-table-wrap-functions.git 

It is nice but takes a long long time to finish.


>> Here is one
>> 
>> +--------+-------------------------------------------------+
>> | Region |                      Sales                      |
>> |        +-------------+-----------+-----------+-----------+
>> |        |      Q1     |    Q2     |    Q3     |    Q4     |
>> |        +-------+-----+-----+-----+-----+-----+-----+-----+
>> |        | foo   | bar | foo | bar | foo | bar | foo | bar |
>> +--------+-------+-----+-----+-----+-----+-----+-----+-----+
>> | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
>> +--------+-------+-----+-----+-----+-----+-----+-----+-----+
>> | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
>> +--------+-------+-----+-----+-----+-----+-----+-----+-----+

> This essentially suggests supporting table.el syntax natively. Or maybe
> extending it by mixing with native Org tables.

> In terms of syntax, adding cell boundary support might be simply a
> question of allowing +----+ in Org tables. It will not break anything as
> we already parse +-----+ as table.el tables.

> At lower level of org-element representation, we do not need to change
> much either. table-row elements are already not tied to a fixed number
> of cells in every row. And we may extend table-row 'rule type to define
> the "+----+   +   +---+--+" cell boundaries.

> However, in order to support merging cells, one needs to rework Org in a
> number of places. At least:

> 1. org-element parser and interpreter
> 2. org-table.el in its totality
> 3. export backends
> 4. table formulas; in particular, cell references
> 5. update syntax document

Or would leave 4 and 5 out for the moment, since it sounds like a headache
>> Or better

>> ------------------------------------------------------------
>> | Region |                      Sales                      |
>> |        ---------------------------------------------------
>> |        |      Q1     |    Q2     |    Q3     |    Q4     |
>> |        ---------------------------------------------------
>> |        | foo   | bar | foo | bar | foo | bar | foo | bar |
>> ------------------------------------------------------------
>> | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
>> ------------------------------------------------------------
>> | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
>> ------------------------------------------------------------

> This will clash with horizontal-rule syntax. Not acceptable. Also,
> parsing this kind of table will be significantly harder programatically.


Ok.


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: org table proposal: merge and split cells in org-tables

[Jean Louis]

To solve that problem personally, I use Asciidoctor, see how it is
done there:

Example 76. Table with formatted, aligned and merged cells:
https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/#ex-cell-format

Org has Babel, for purposes of HTML output, Org file could use Bable
to get HTML return from Babel containing Asciidoc and embed it in Org
HTML.

That solution is definitely not general solution, it may be personal one.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: org table proposal: merge and split cells in org-tables

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> To solve that problem personally, I use Asciidoctor, see how it is
> done there:
>
> Example 76. Table with formatted, aligned and merged cells:
> https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/#ex-cell-format

I am sorry, but this looks unreadable. I would avoid re-using such
syntax ideas.

> Org has Babel, for purposes of HTML output, Org file could use Bable
> to get HTML return from Babel containing Asciidoc and embed it in Org
> HTML.

Sure. And we do use pretty much the same approach to export table.el
tables, which are supported by Org natively (up to a limit). But this
proposal is about bringing cell merging into native Org tables.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org table proposal: merge and split cells in org-tables

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2022-10-30 12:27]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > To solve that problem personally, I use Asciidoctor, see how it is
> > done there:
> >
> > Example 76. Table with formatted, aligned and merged cells:
> > https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/#ex-cell-format
> 
> I am sorry, but this looks unreadable. I would avoid re-using such
> syntax ideas.

You have got an extreme reference on what can be done. Other people
and other projects have faced same issues as you are facing in Org
mode, and have resolved it. To understand anything one cannot just
read simple reference, but better understand the surrounding meanings,
the context.

Org tables are nothing harder or simpler than tables in other
lightweight markup languages.

What appears "unreadable" to you is readable to other
person. In fact, there is no single char in the extreme example of
Asciidoc table below that you can't read. The meaning of
"unreadable" is most probably "not understandable". That is why I
said, one has to inspect the context and look for definitions.

[cols="e,m,^,>s",width="25%"]
|===
|1 >s|2 |3 |4
^|5 2.2+^.^|6 .3+<.>m|7
^|8
|9 2+>|10nnp
|===

In fact, looking into functionality of other lightweigh markup
languages may only be helpful for Org development.

For [cols="e,m,^p,>s",width="25%"] look here:
https://docs.asciidoctor.org/asciidoc/latest/tables/format-column-content/

Thus `e' before first comma, means emphasized (I guess) and in fact on
the original demonstration one can see that first column is
emphasized. 

The fact that one may "describe" column's font style in Asciidoc(tor)  could
be adopted as well in Org mode.

`m' after first comma says that text of that column shall be in
monospaced font, which I find very useful for table columns.

`^' signifies centered column in `[cols="e,m,^,>s",width="25%"]'

and `>s' means right centered, bold column;

`width=25%' tells about table width.

I would like it if Org mode could provide such functionality for
tables, to specify various attributes for columns. It does provide,
though I am not sure if it can provide so many.

And in that extreme example then we have following lines:

|===
for begin of the table

|1 >s|2 |3 |4
the second `|' has attribute `>s' or complete `>s|' which specifically
formats number "2" to be bold and right centered. 

^|5 2.2+^.^|6 .3+<.>m|7

It is good to read about span factor:
https://docs.asciidoctor.org/asciidoc/latest/tables/span-cells/

2.2+^.^|6 -- talks about spanning 2 columns, two rows and its alignment.

while .3+<.>m|7 talks about spanning 3 rows, that is where number 7 comes.

|===
for end of the table

It is surely good to try to make visual tables with merged cells as
general Org functionality. 

It is also very useful to look how other people implement various
functionalities and try to see if such could be useful in Org as well.

But when you don't have the functionality yet, due to the Babel and
inclusion of other files, one may achieve the final result by
including HTML directly, or by using external tools.

Org is integrator of almost anything. Babel and integration of, to the
Org external tools, allows user to include almost any value or results
from outside the file.

I do agree that it is "hard" to understand at once what it is, but it
is a solution for reason that Org allows external tools' values to be
included in the Org file. In this case it is the HTML output from
Asciidoctor. 

This elaboration is for opening the mind of Org user, it is to
understand that extensibility, due to Babel and inclusion of any
external tools has no limits at any point of time.

One need not wait for that feature X to be implemented in Org, while
there is plenty of available options to reach the purpose of feature
X.

#+BEGIN_SRC shell :results raw
echo "
[cols=\"e,m,^,>s\",width=\"25%\"]
|===
|1 >s|2 |3 |4
^|5 2.2+^.^|6 .3+<.>m|7
^|8
|9 2+>|10nnp
|===
" | asciidoctor -e -o - -

#+END_SRC

#+RESULTS:
<table class="tableblock frame-all grid-all" style="width: 25%;">
<colgroup>
<col style="width: 25%;">
<col style="width: 25%;">
<col style="width: 25%;">
<col style="width: 25%;">
</colgroup>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><em>1</em></p></td>
<td class="tableblock halign-right valign-top"><p class="tableblock"><strong>2</strong></p></td>
<td class="tableblock halign-center valign-top"><p class="tableblock">3</p></td>
<td class="tableblock halign-right valign-top"><p class="tableblock"><strong>4</strong></p></td>
</tr>
<tr>
<td class="tableblock halign-center valign-top"><p class="tableblock"><em>5</em></p></td>
<td class="tableblock halign-center valign-middle" colspan="2" rowspan="2"><p class="tableblock"><code>6</code></p></td>
<td class="tableblock halign-left valign-bottom" rowspan="3"><p class="tableblock"><code>7</code></p></td>
</tr>
<tr>
<td class="tableblock halign-center valign-top"><p class="tableblock"><em>8</em></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><em>9</em></p></td>
<td class="tableblock halign-right valign-top" colspan="2"><p class="tableblock"><code>10nnp</code></p></td>
</tr>
</tbody>
</table>

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: org table proposal: merge and split cells in org-tables

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

>> I am sorry, but this looks unreadable. I would avoid re-using such
>> syntax ideas.
>
> You have got an extreme reference on what can be done. Other people
> and other projects have faced same issues as you are facing in Org
> mode, and have resolved it. To understand anything one cannot just
> read simple reference, but better understand the surrounding meanings,
> the context.

Indeed. I was expecting a link describing the concepts. What your
provided was not very helpful.

> Org tables are nothing harder or simpler than tables in other
> lightweight markup languages.

Somewhat harder. Somewhat simpler. We do not support some features
ASCIIDOC supports. ASCIIDOC does not support spreadsheet features of Org
tables. That's why we need context. We cannot blindly copy from
ASCIIDOC.

> What appears "unreadable" to you is readable to other
> person. In fact, there is no single char in the extreme example of
> Asciidoc table below that you can't read. The meaning of
> "unreadable" is most probably "not understandable".

Sure. But we have different proposals in the previous emails. Compared
to the existing proposals, this looks unreadable. (which does not mean
that it is worse - maybe ASCIIDOC has more flexibility; but less
readable compared to other proposals for sure).

> In fact, looking into functionality of other lightweigh markup
> languages may only be helpful for Org development.
>
> For [cols="e,m,^p,>s",width="25%"] look here:
> https://docs.asciidoctor.org/asciidoc/latest/tables/format-column-content/

> Thus `e' before first comma, means emphasized (I guess) and in fact on
> the original demonstration one can see that first column is
> emphasized. 
>
> The fact that one may "describe" column's font style in Asciidoc(tor)  could
> be adopted as well in Org mode.

Thanks for the link! This specific link is out of scope of this
discussion (I do not think that we need to specify formatting for the
whole column), but another link nearby looks more useful:
https://docs.asciidoctor.org/asciidoc/latest/tables/span-cells/

> I would like it if Org mode could provide such functionality for
> tables, to specify various attributes for columns. It does provide,
> though I am not sure if it can provide so many.

Please open a discussion about other attributes in a separate thread.
Let's stay on the topic of merging cells and columns in this thread.
It is already difficult enough.

> It is good to read about span factor:
> https://docs.asciidoctor.org/asciidoc/latest/tables/span-cells/

I think a slightly more clear example is (from the link; they also
provide how html export of the below table looks like)

|===
|Column 1, header row |Column 2, header row |Column 3, header row |Column 4, header row

|Cell in column 1, row 2
2.3+|This cell spans columns 2 and 3 and rows 2, 3, and 4 because its specifier contains a span of `2.3+`
|Cell in column 4, row 2

|Cell in column 1, row 3
|Cell in column 4, row 3

|Cell in column 1, row 4
|Cell in column 4, row 4
|===

I can see the idea here. For columns, it is similar to Timothy's ||||,
but uses a number. For rows, I'm afraid that we cannot use the same
approach because of conceptually different table structure.

Takeaway:
TEC's:
|----    ||||||||               Sales                      |
can become
|----    2+|                    Sales                      |

> One need not wait for that feature X to be implemented in Org, while
> there is plenty of available options to reach the purpose of feature
> X.
>
> #+BEGIN_SRC shell :results raw
> echo "
> [cols=\"e,m,^,>s\",width=\"25%\"]
> ...
> |===
> " | asciidoctor -e -o - -
>
> #+END_SRC

Indeed. But it is not what we are discussing here.
We are discussing concrete ideas to implement feature X. X being merged
table cells. Let's not sidestep into other topics.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org table proposal: merge and split cells in org-tables

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

Hi Uwe and Ihor,

> This subject is brought up regularly.
>
> In a conversation with Ihor Radchenko it was considered as being helpful
> to provide a table in which cells are merged and split.

This reminds me of a proposal I made in 2020 on this very matter:
<https://list.orgmode.org/87k0v361x9.fsf@gmail.com>.

I won’t re-hash it here, but if I am to apply that proposed syntax to the
example table it would look like this:

┌────
│ |----    ||||||||               Sales                      |
│ | Region |-------------+-----------+-----------+-----------|
│ |        ||     Q1     ||   Q2     ||   Q3     ||   Q4     |
│ |        | foo   | bar | foo | bar | foo | bar | foo | bar |
│ |--------+-------+-----+-----+-----+-----+-----+-----+-----|
│ | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
│ | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
└────

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.

Re: org table proposal: merge and split cells in org-tables

[Max Nikulin]

I believe that tables in Org are already too complicated due to the 
spreadsheet feature. However those who are brave enough to add cells 
spanning columns and rows may take some inspiration from 
reStructuredText, in particular horizontal lines marked by "+===+===+"

https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#tables
> Grid tables are described with a visual grid made up of the characters "-", "=", "|", and "+". The hyphen ("-") is used for horizontal lines (row separators). The equals sign ("=") may be used to separate optional header rows from the table body (not supported by the Emacs table mode). The vertical bar ("|") is used for vertical lines (column separators). The plus sign ("+") is used for intersections of horizontal and vertical lines. Example:
> 
> +------------------------+------------+----------+----------+
> | Header row, column 1   | Header 2   | Header 3 | Header 4 |
> | (header rows optional) |            |          |          |
> +========================+============+==========+==========+
> | body row 1, column 1   | column 2   | column 3 | column 4 |
> +------------------------+------------+----------+----------+
> | body row 2             | Cells may span columns.          |
> +------------------------+------------+---------------------+
> | body row 3             | Cells may  | - Table cells       |
> +------------------------+ span rows. | - contain           |
> | body row 4             |            | - body elements.    |
> +------------------------+------------+---------------------+

RST tables have a feature making hard to implement autoalignment. If 
come cell have "|" with offset in respect to lines above and below then
it is a regular character.

Besides "grid" tables there are "simple" tables without vertical lines.

Perhaps it better to implement new table features as src blocks for some 
new language and a dedicated Emacs mode. In the case of success such 
proof of concept may be merged into Org core.

My impression is that Org tables quickly become hardly maintainable when 
their complexity is above some quite low threshold. E.g. automatic 
recalculation works only for first #+tblfm: line. It requires some 
efforts to figure out association of particular formula with cell spans.

Merge cells add more complexity to formula ranges. Some protocol should 
be defined to allow source blocks to generate extended cells.

Re: org table proposal: merge and split cells in org-tables

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> I believe that tables in Org are already too complicated due to the 
> spreadsheet feature.

They are, but merging cells is widely demanded. If we can come up with
some reasonable extension of Org syntax, it will be a benefit for the
whole Org community.

> However those who are brave enough to add cells 
> spanning columns and rows may take some inspiration from 
> reStructuredText, in particular horizontal lines marked by "+===+===+"

These are the table.el Emacs tables we already support (partially).
Uwe's proposal is supporting table.el more fully, but it will be
incompatible (if taken as is) with the current Org table syntax.

We can learn from the design, but cannot just blindly re-use it.

> Besides "grid" tables there are "simple" tables without vertical lines.

That's similar to the ASCIIDoctor tables as I read it in the link.
I do not think that it is a good option to move away from the visual
table style employed in Org.

> Perhaps it better to implement new table features as src blocks for some 
> new language and a dedicated Emacs mode. In the case of success such 
> proof of concept may be merged into Org core.

That's what our table.el integration does. But it is not enough.

Some features are only present in native Org tables and some features
are only present in table.el tables. We will end up needing to extend
either of the table syntaxes to obtain full Org table functionality.

Then, it is better to extend native Org tables rather than replacing the
existing table syntax with third party.

> My impression is that Org tables quickly become hardly maintainable when 
> their complexity is above some quite low threshold. E.g. automatic 
> recalculation works only for first #+tblfm: line. It requires some 
> efforts to figure out association of particular formula with cell spans.

I'd say that the problem is mostly with org-table.el which heavily
relies on direct regexp matching. If we generalize things using parser,
it should become easier to maintain even with merge cells.

> Merge cells add more complexity to formula ranges. Some protocol should 
> be defined to allow source blocks to generate extended cells.

Agree. And such protocol will improve maintainability even if
implemented without extended cells. Either way, it is a good idea to
refactor org-table.el

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>