From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [RFC] Shrink columns dynamically Date: Tue, 11 Jul 2017 13:41:35 +0200 Message-ID: <87r2xntd3k.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUtXw-0002hX-OP for emacs-orgmode@gnu.org; Tue, 11 Jul 2017 07:41:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dUtXt-0001Kx-M8 for emacs-orgmode@gnu.org; Tue, 11 Jul 2017 07:41:40 -0400 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:47006) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dUtXt-0001Ke-Fx for emacs-orgmode@gnu.org; Tue, 11 Jul 2017 07:41:37 -0400 Received: from saiph.selenimh (000043010000000000000469.ipv6.commingeshautdebit.fr [IPv6:2a03:a0a0:0:4301::469]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id E9B29C5A51 for ; Tue, 11 Jul 2017 13:41:35 +0200 (CEST) Received: from ngz by saiph.selenimh with local (Exim 4.89) (envelope-from ) id 1dUtXr-0007Jt-5D for emacs-orgmode@gnu.org; Tue, 11 Jul 2017 13:41:35 +0200 In-Reply-To: <87o9srxtec.fsf@mat.ucm.es> (Uwe Brauer's message of "Tue, 11 Jul 2017 08:35:55 +0000") 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: emacs-orgmode@gnu.org Uwe Brauer writes: > So you are saying we cannot have both. I'm not. I'm opposed to have overlapping features with two different implementations, that's all. > But couldn't the feature of shrink one particular wide column to a > certain width be implemented using your new implementation? I already made that offer. However, the narrowing (as opposed to shrinking) feature is yet to be defined. In particular, I think width cookies should not be used, i.e., you shouldn't have to modify _data_ to alter the _view_. It is possible, however, to, e.g., reduce by half the current column, or to a pre-defined width. Regards,