Ihor Radchenko <yanta...@gmail.com> writes:
> George Michaelson <g...@pobox.com> writes: > >> Thank you for the continuing support for Org mode. I really appreciate >> the work done. >> >> I would love to understand why there is no built-in 'fill/wrap' >> function for text in a cell, inside an org mode table. >> >> Given how this is a layout mechanism, and heads to M-x ox-<exportform> >> outcomes, it would be useful to recognize the output is often table >> edit states which do respect fill/wrap/center > > AFAIK, mostly technical difficulty. Emacs does not natively distinguish > individual table cells, so we would need to emulate cell editing if it > spans over multiple lines. > > Patches are welcome! > I agree. This is actually a much harder problem to solve than it may appear on the surface. There have been a number of proposals regarding how to do this over the years, but unfortunately, they have all had significant drawbacks or limitations. One of which is that formatting tables with multiple lines in LaTeX is actually a bit tricky (probably the only exporter where it is relatively straight-forward is HTML). This means you actually have two broad problems - handling cell wrapping in the org buffers and handling it cleanly in the different exporters. In addition to the problem of defining some mechanism to treat each table cell as if it was it's own 'minibuffer' (in TeX, you sometimes see the 'minipage' environment used in this context), you also have to define some mechanism to describe the relationship between the cells in order to handle things like centring and justification. screen/page width etc. To further complicate matters, you also have to consider what this would mean for org's spreadsheet like capabilities when applied to tables with cells wrapped over multiple lines. If you have lots of cells needing wrapping, the table is perhaps not the right layout mechanism to use. While it may seem like a convenient way to present content, often it isn't a great way to consume it. Donald Knuth wrote a bit about why tables with multiple cell lines were a poor choice. After years of dealing with project managers who too often use Excel to record, present and share data, I tend to agree with his views. I'm also old enough to remember when the table was the 'goto' solution for managing layout in HTML files and what a mess that became. While tables are great when you want to show 2-dimensional relationships, for other situations, alternatives like definition lists, nested lists and breaking the content up into subsections are often a good alternative. It could be argued that not supporting table wrapping is a positive aspect as it makes the author consider alternative layout approaches which may actually improve readability of the content. Finally, there is also an accessibility issue with multiple line tables. For users who rely on assistive technology to consume content, presenting information in a meaningful manner which is easy to navigate and can represent larger 'chunks' of information with appropriate indicators for the relationships between the cells is challenging. As an aside, I sometimes find it useful when thinking about how to layout information, how a typical user will consume it. We tend prefer layouts with infinite length (pages), but with set width. Scrolling up/down is convenient. Scrolling left/right is not. While larger screens means we have more width to work with when reading on the screen, this does not map well to printed pages as that 'width' has not changed - best we can do is switch to 'landscape' rather than portrait mode. The other problem with width is in variability - many people have wide screens on desktops, but narrow screens on mobile devices. We can see how quickly this becomes complex when we consider all the challenges we have had with respect to being able to render web content on different devices with varying screen sizes. Much of the complexity of CSS is related to column layout and screen sizes.
