From mboxrd@z Thu Jan 1 00:00:00 1970 From: Uwe Brauer Subject: Re: [RFC] Shrink columns dynamically Date: Tue, 11 Jul 2017 08:35:55 +0000 Message-ID: <87o9srxtec.fsf@mat.ucm.es> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUqeS-0007qK-5C for emacs-orgmode@gnu.org; Tue, 11 Jul 2017 04:36:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dUqeN-0008I4-R2 for emacs-orgmode@gnu.org; Tue, 11 Jul 2017 04:36:12 -0400 Received: from [195.159.176.226] (port=45467 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dUqeN-0008Gq-K7 for emacs-orgmode@gnu.org; Tue, 11 Jul 2017 04:36:07 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dUqeE-0000H3-W5 for emacs-orgmode@gnu.org; Tue, 11 Jul 2017 10:35:58 +0200 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 >>> "Nicolas" == Nicolas Goaziou writes: > Hello, > Uwe Brauer writes: >> If you want to implement the second feature differently, because of >> maintain reasons that sound reasonable, but please don't simple remove >> the second feature. > Then I'll just drop this branch. I'm against having the same (sub-set of > a) feature implemented in two different ways. That is a real pity! So in master we have the feature of narrowing one column to a width we want. That is useful in scenario 1. Now in the branch there is another *very nice* feature, which allows you to hide many columns on the fly. That is useful in scenario 2. So you are saying we cannot have both. I still have your patch and use it often, I really don't want to miss it, since it enhance the features of the table very much. It is a pity that you won't conserve that. I hope that patch can survive in the future. > I still think width cookies in their current state are wrong since > they really do two different things. But couldn't the feature of shrink one particular wide column to a certain width be implemented using your new implementation? Thank you very much for you work and I still hope this can somehow be saved and merged into master. Regards Uwe