Hello, Rick Frankel <r...@rickster.com> writes:
> Personally, my use of width cookies has been mostly for visual display of > columns are very long and will wrap in an html or latex table export, but > would force the display too wide. My ideal default would be to have a setting > which would shrink tables a reasonable (fill-column?, window-width?) visual > display, with perhaps a min-column-width option and trying to balance the > width of each column base on its un-narrowed total width, perhaps trying to > keep narrow columns as-is in the process. For me this would probably align > cognitively with how much info is needed to grok the cell contents. It would be a fun optimization problem to solve, but I doubt it would be much useful (e.g., pathological cases getting in the way...). > I like a single cycling command. [...] > Wouldn't a min-column-width setting to use when there is no cookie solve the > the bi- vs tri-state problem (every column has three states) For the sake of simplicity, I opted for two states cycling in the latest proof of concept. It means that columns with a width cookie cannot be narrowed to 1 character, but I assume it is an acceptable restriction since the width cookie is probably there for a reason. > P.S. and (somewhat) off topic: The doc string for > `org-ascii-table-use-ascii-art' is out of date. `ascii-art-to-unicode.el' is > now in elpa and the url no longer works. Fixed. Thank you. Regards, -- Nicolas Goaziou
