+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. >>