From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)] Date: Sat, 07 Dec 2019 19:16:10 +0100 Message-ID: <87d0d0uhlh.fsf@nicolasgoaziou.fr> References: <0100016ed1d37aac-88e8671f-bb77-434f-a756-35131ada48db-000000@email.amazonses.com> <87lfrsc8zj.fsf@ucl.ac.uk> <0100016ed4392587-b1efb2eb-f2d2-49d2-b77c-572deb0fff17-000000@email.amazonses.com> <87eexjgx30.fsf@kyleam.com> <87k179w5n3.fsf@nicolasgoaziou.fr> <86o8wkgk6k.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39207) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idect-00009t-Sr for emacs-orgmode@gnu.org; Sat, 07 Dec 2019 13:16:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1idecs-0001lp-Gz for emacs-orgmode@gnu.org; Sat, 07 Dec 2019 13:16:19 -0500 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:34475) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1idecs-0001l4-BK for emacs-orgmode@gnu.org; Sat, 07 Dec 2019 13:16:18 -0500 In-Reply-To: <86o8wkgk6k.fsf@gmail.com> (Andy Moreton's message of "Sat, 07 Dec 2019 16:44:03 +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: Andy Moreton Cc: emacs-orgmode@gnu.org Hello, Andy Moreton writes: > That still does not match the old behaviour though, as the table still > shows the `org-table-shrunk-column-indicator' overlay which is > undesireable. Why is it undesirable? > Dynamic shrink/expand is a fine feature to add, but why was it done in a > way that broke the documented existing behaviour ? I think the current state is better. However, I initially explained the motivation behind this change (see links in this thread). Feel free to suggest, and possibly implement, if users agree, a better way. Or, please point where the documented behaviour does not match the current state. Regards, -- Nicolas Goaziou