Uwe Brauer <o...@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>
