Hello, Julius Dittmar <julius.ditt...@gmx.de> writes:
> What I think this was about: Assume, the following table is set up for > right-aligned output (that's one of the things I don't know how to do, > but that's fine with me): > > | a very long entry which enforces a long table cell | > | a moderately long entry | > | a short entry | > > Assume further that this table is to be displayed showing only 19 > characters. As I understand the original post, the outcome at the moment > would be something like : > > > | a very long entr... | > | ... | > | ... | For the record, it is more like | a very long entr…| | …| | …| > What I would prefer is: > > | a very long entr... | > | a moderately lon... | > | a short entry | So the narrowing is done field wise and not column wise. If you are in the last cell, you cannot possibly tell the column is narrowed unless you check other levels. > This does not really mean cutting on both ends, at least not more than > org already does. Org already does add or subtract leading or trailing > whitespace as needed. There is a misunderstanding here. One of the motivation of the current implementation of columns narrowing is to _not change the buffer_. It hides characters, but never removes them. So, if you want to remove characters on the right, you need to hide them somehow. So, I still think you would need to narrow on both sides. I have the gut feeling this is not very practical. I agree right-aligned -- and center-aligned -- fields are not perfect, but I cannot think of a good design for these at the moment. Regards, -- Nicolas Goaziou
