Tim Cross <theophil...@gmail.com> writes:
> In principal, it wold be great to be able to support multi-row columns. > However, I'm not sure how easily this can actually be implemented in a > consistent and maintainable manner. Mmmm, this of feels like something where you'll quickly learn how hard it is/isn't when you try to implement it. > From watching these discussions in the past, I think the big stumbling > block is how easily multi-row columns can be added and maintained in the > various export formats. Some are easy, like HTML, but others are less > so. In particular, I know from my many years working with Latex, > multi-row columns are not straight-forward. There are lots of edge cases > to deal with and it is hard to get a consistent result programatically. > > Proposals like this one can seem simple and straight-forward on the > surface. However, implementation is another matter. All of the exporters > will need to be updated to handle this new syntax and it will probably > take a fair bit of work to handle it correctly in just plain org files > (formatting, highlighting etc). Currently if you were to try this content with the proposed syntax, content is just put in the top left cell of the group. This seems like a reasonable fallback to me. Then for HTML we have colspan/rowspan, and for LaTeX there's \multicolumn and with the multirow package \multirow. FWIW just formatting would need to be updated for Org files. Highlighting is fine as is. > If this was something people were prepared to put the time into > implementing, I think it must be done in a completely separate feature > branch and would need to be fully tested (including all back end > exporters) before it can be merged into the mainline branch. It would > also be important to profile and ensure it does not have significant > impact on performance. > > I am a little concerned about the expansion and addition of features in > org mode when there seems to already be a challenge with respect to > maintenance and bug fixing. Personally, I would prefer an org mode which > is consistent and reliable over one with large numbers of features that > is less stable and slower. I appreciate this concern, but I do think that the ability to have multi-col/row cells is invaluable in many large tables, and so would be a very good addition to Org. -- Timothy