From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Colin Baxter <m43cap@yandex.com>
Cc: emacs-orgmode@gnu.org, Kaushal Modi <kaushal.modi@gmail.com>
Subject: Re: [RFC] Shrink columns dynamically
Date: Wed, 12 Jul 2017 12:17:26 +0200 [thread overview]
Message-ID: <87vamy0xjd.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87iniyrug0.fsf@yandex.com> (Colin Baxter's message of "Wed, 12 Jul 2017 08:22:07 +0100")
Hello,
Colin Baxter <m43cap@yandex.com> 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
next prev parent reply other threads:[~2017-07-12 10:17 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 12:12 [RFC] Shrink columns dynamically Nicolas Goaziou
2017-07-10 14:36 ` Uwe Brauer
2017-07-10 14:43 ` Nicolas Goaziou
2017-07-10 19:47 ` Uwe Brauer
2017-07-10 20:14 ` Nick Dokos
2017-07-10 20:59 ` Nicolas Goaziou
2017-07-11 6:27 ` Uwe Brauer
2017-07-11 7:54 ` Nicolas Goaziou
2017-07-11 8:35 ` Uwe Brauer
2017-07-11 11:41 ` Nicolas Goaziou
2017-07-11 12:03 ` Uwe Brauer
2017-07-11 12:24 ` Nicolas Goaziou
2017-07-11 17:56 ` Kaushal Modi
2017-07-11 19:09 ` Nicolas Goaziou
2017-07-11 19:23 ` Kaushal Modi
2017-07-12 7:22 ` Colin Baxter
2017-07-12 10:17 ` Nicolas Goaziou [this message]
2017-07-12 16:06 ` Colin Baxter
2017-07-12 19:14 ` Rick Frankel
2017-07-27 11:47 ` Nicolas Goaziou
[not found] ` <158a779e34564ef98104c442384dadd3@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2017-07-12 16:10 ` Eric S Fraga
2017-07-16 10:54 ` B.V. Raghav
2017-07-27 10:14 ` Nicolas Goaziou
2017-07-27 10:11 ` Nicolas Goaziou
2017-07-31 22:29 ` Adam Porter
2017-08-05 22:56 ` Nicolas Goaziou
[not found] ` <e59b6e794bff46c29380611204d00402@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2017-07-27 10:49 ` Eric S Fraga
2017-08-05 22:54 ` Nicolas Goaziou
2017-08-19 16:54 ` Nicolas Goaziou
2017-09-06 13:29 ` Nicolas Goaziou
2017-07-11 20:21 ` Uwe Brauer
2017-07-11 9:32 ` Uwe Brauer
2017-07-10 22:11 ` Kaushal Modi
2017-07-11 6:16 ` Michael Brand
2017-07-11 11:18 ` Deleting org table columns during export (Was: [RFC] Shrink columns dynamically) Kaushal Modi
2017-07-11 16:43 ` Michael Brand
2017-07-11 11:47 ` [RFC] Shrink columns dynamically Nicolas Goaziou
2017-07-11 16:40 ` Michael Brand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vamy0xjd.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=kaushal.modi@gmail.com \
--cc=m43cap@yandex.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).