From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Feature request: shrink according to alignment (was Re: Org table columns without width cookies get shrunk on TAB) Date: Wed, 21 Feb 2018 12:45:15 +0100 Message-ID: <87fu5uk1mc.fsf@nicolasgoaziou.fr> References: <87po5638ea.fsf@gmail.com> <87o9kqicys.fsf@nicolasgoaziou.fr> <8a0b873e-e9ea-2070-d276-702939e99511@gmx.de> <87bmgll2rh.fsf@nicolasgoaziou.fr> <97d48f48-a6b4-eaf6-5f31-8e38525b25a6@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eoSps-0004wB-Pq for emacs-orgmode@gnu.org; Wed, 21 Feb 2018 06:45:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eoSpr-0008HE-Aa for emacs-orgmode@gnu.org; Wed, 21 Feb 2018 06:45:20 -0500 Received: from relay2-d.mail.gandi.net ([2001:4b98:c:538::194]:43957) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eoSpq-0008Ea-Ip for emacs-orgmode@gnu.org; Wed, 21 Feb 2018 06:45:18 -0500 In-Reply-To: <97d48f48-a6b4-eaf6-5f31-8e38525b25a6@gmx.de> (Julius Dittmar's message of "Mon, 19 Feb 2018 12:29:30 +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: Julius Dittmar Cc: emacs-orgmode@gnu.org Hello, Julius Dittmar writes: > What I think this was about: Assume, the following table is set up for > right-aligned output (that's one of the things I don't know how to do, > but that's fine with me): > > | a very long entry which enforces a long table cell | > | a moderately long entry | > | a short entry | > > Assume further that this table is to be displayed showing only 19 > characters. As I understand the original post, the outcome at the moment > would be something like : > > > | a very long entr... | > | ... | > | ... | For the record, it is more like | a very long entr=E2=80=A6| | =E2=80=A6| | =E2=80=A6| > What I would prefer is: > > | a very long entr... | > | a moderately lon... | > | a short entry | So the narrowing is done field wise and not column wise. If you are in the last cell, you cannot possibly tell the column is narrowed unless you check other levels. > This does not really mean cutting on both ends, at least not more than > org already does. Org already does add or subtract leading or trailing > whitespace as needed. There is a misunderstanding here. One of the motivation of the current implementation of columns narrowing is to _not change the buffer_. It hides characters, but never removes them. So, if you want to remove characters on the right, you need to hide them somehow. So, I still think you would need to narrow on both sides. I have the gut feeling this is not very practical. I agree right-aligned -- and center-aligned -- fields are not perfect, but I cannot think of a good design for these at the moment. Regards, --=20 Nicolas Goaziou