From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [RFC] Shrink columns dynamically Date: Wed, 12 Jul 2017 12:17:26 +0200 Message-ID: <87vamy0xjd.fsf@nicolasgoaziou.fr> References: <87bmoswkvs.fsf@nicolasgoaziou.fr> <87d198uznu.fsf@mat.ucm.es> <87o9ss4aj4.fsf@nicolasgoaziou.fr> <87inj0m5v5.fsf@mat.ucm.es> <878tjwuhxe.fsf@nicolasgoaziou.fr> <87o9sr5vzl.fsf@mat.ucm.es> <874lujv26h.fsf@nicolasgoaziou.fr> <87o9srxtec.fsf@mat.ucm.es> <87r2xntd3k.fsf@nicolasgoaziou.fr> <87fue3xjsl.fsf@mat.ucm.es> <877ezftb39.fsf@nicolasgoaziou.fr> <87fue23i4l.fsf@nicolasgoaziou.fr> <87iniyrug0.fsf@yandex.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVEi7-00054n-5Z for emacs-orgmode@gnu.org; Wed, 12 Jul 2017 06:17:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVEi3-0001F4-Lh for emacs-orgmode@gnu.org; Wed, 12 Jul 2017 06:17:35 -0400 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:41785) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dVEi3-0001Eh-EE for emacs-orgmode@gnu.org; Wed, 12 Jul 2017 06:17:31 -0400 In-Reply-To: <87iniyrug0.fsf@yandex.com> (Colin Baxter's message of "Wed, 12 Jul 2017 08:22:07 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Colin Baxter Cc: emacs-orgmode@gnu.org, Kaushal Modi Hello, Colin Baxter 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