emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [RFC] Shrink columns dynamically


From: Nicolas Goaziou
Subject: Re: [O] [RFC] Shrink columns dynamically
Date: Wed, 12 Jul 2017 12:17:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Hello,

Colin Baxter <address@hidden> writes:

> Column cookies work - and they work well for me - so why on earth remove
> something that is actually *useful*?

Really, I explained already the motivation, right from my initial post.
Anyway, let me re-iterate and expound it a bit.

The first thing to know is I'm *no longer* wanting to remove the
feature, as I initially suggested. As explained before, I understood
narrowing was an important feature, so I'm offering to rewrite it. Why?
Because I'm trying to introduce a new feature which is close to this
one, and I would like both features to converge under the same
implementation.

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

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

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

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

The conclusion is that columns narrowing should be independent from
width cookies. More specifically, there is nothing wrong in narrowing
obeying to a width cookie, but it should also be able to ignore it. So
here is why "on earth" I'm suggesting to think about it and, maybe,
implement something more general, possibly more useful, too.

However, rewriting it implies some changes in the current behaviour.
This is why I'm trying to discuss with actual users of width cookies
and, with their help, find a solution that would satisfy everyone. 

I may be trying to square the circle. I don't know yet. Note that
however, so far, most answers are somewhat like "width cookies are
exactly what we want, don't remove them", which is missing the point.
Also, please don't focus on how tables should look like upon opening an
Org document. This is really putting us off-track. It can be postponed.

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

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

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

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

Food for thought.

Regards,

-- 
Nicolas Goaziou



reply via email to

[Prev in Thread] Current Thread [Next in Thread]