Re: [O] [RFC] Shrink columns dynamically

[Colin Baxter]

Dear Nicolas,

I apologise for not understanding fully what you propose. I use org-mode
extensively, so any possibility of "change" tends to make me anxious. 

    Nicolas> Besides, columns cookies may work for you, but, as pointed
    Nicolas> out, they are limited:

    Nicolas> - Setting a width cookie also changes how the table is
    Nicolas> exported (e.g., in ASCII export). However I may want to
    Nicolas> narrow view of the table and, yet, export it to its full
    Nicolas> extent.

    Nicolas> - Setting a width cookie hard-codes how the column is
    Nicolas> displayed. I may want to completely hide the column
    Nicolas> temporarily, or expand it without affecting other narrowed
    Nicolas> columns.

    Nicolas> - Setting a width cookie segregates other columns. I can
    Nicolas> only narrow columns with a width cookie. I may want to
    Nicolas> temporarily hide another column without modifying my table.

I appreciate these points and indeed I regularly face export
problems. However, I just manually remove the cookies if they become an
issue. I accept other users may wish to work differently.

    Nicolas> The real question for now is: how can we alter columns
    Nicolas> display when at a table? E.g.,

    Nicolas> - Do we need two commands, one for narrowing (to a given
    Nicolas> number of characters) and one for shrinking (to one
    Nicolas> character only)? Or would a command toggling between the
    Nicolas> three states be sufficient?

    Nicolas> - Is there some rule of thumb to narrow a column when no
    Nicolas> width cookie is supplied or should we consider this kind of
    Nicolas> columns has only two states, shrunk and expanded?

In my own case, the values of the column widths are not static but vary 
from file-to-file. I don't have any rule of thumb, except, from my own
experience, I have never found the need to shrink any column to a single
character.

    Nicolas> - Supposing we focus on a single, cycling, command, how
    Nicolas> should it behave when called on multiple columns at a time?
    Nicolas> Since some columns may have two states and other ones
    Nicolas> three, it may end up being confusing for the user.

To me, that's the beauty of my present arrangement: it's simple,
intuitive and controllable. I am sure that my requirements are more
modest than those of other users.

    Nicolas> Food for thought.

Indeed.


Best wishes,

Colin.

-- 
--
Colin Baxter
address@hidden
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8