Timothy <tecos...@gmail.com> writes:
> 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. We can debate how easy or hard this is to implement indefinitely. What is needed is for someone to implement a working version which is consistent, reliable and provides expected results across all export environments. The devil is in the details and I suspect that once you start trying to implement the feature is when many of those challenges become clear. My view is 'go for it'. Just create a new feature branch and implment the functionality in that branch. We can then try using it and see where it works and where it doesn't. Once this is done, a call can be made as to whether it should be implemented in the main code base -- Tim Cross
