>>> "IR" == Ihor Radchenko writes: > Uwe Brauer 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/