From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [rows?] Date: Sat, 01 Jul 2017 11:57:51 +0200 Message-ID: <87efu04gyo.fsf@nicolasgoaziou.fr> References: <87o9thk827.fsf@mat.ucm.es> <87mv8z7v80.fsf@nicolasgoaziou.fr> <87podvowxl.fsf@mat.ucm.es> <87r2y94vq0.fsf@nicolasgoaziou.fr> <87fuephz8y.fsf@mat.ucm.es> <87efu93rua.fsf@nicolasgoaziou.fr> <87lgogdm9q.fsf@mat.ucm.es> <874lv1hzok.fsf@nicolasgoaziou.fr> <87mv8r1awh.fsf_-_@mat.ucm.es> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRFA7-0006Gb-1F for emacs-orgmode@gnu.org; Sat, 01 Jul 2017 05:57:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dRFA6-0005eA-63 for emacs-orgmode@gnu.org; Sat, 01 Jul 2017 05:57:59 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:46635) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dRFA5-0005b6-Vs for emacs-orgmode@gnu.org; Sat, 01 Jul 2017 05:57:58 -0400 Received: from saiph.selenimh (000043010000000000000469.ipv6.commingeshautdebit.fr [IPv6:2a03:a0a0:0:4301::469]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 3AB151720B2 for ; Sat, 1 Jul 2017 11:57:55 +0200 (CEST) Received: from ngz by saiph.selenimh with local (Exim 4.89) (envelope-from ) id 1dRF9z-000236-RZ for emacs-orgmode@gnu.org; Sat, 01 Jul 2017 11:57:51 +0200 In-Reply-To: <87mv8r1awh.fsf_-_@mat.ucm.es> (Uwe Brauer's message of "Thu, 29 Jun 2017 08:00:14 +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 Hello, Uwe Brauer writes: > I tested it quite a bit yesterday. There was only one problem concerning > pabbrev mode which scans the buffer periodically and this scanning did > widen the columns at some point. One can try this out by running > (pabbrev-scavenge-buffer) in an org buffer with columns being narrowed: > the columns will widen. But I am not sure whether this is a bug of your > implementation. I am happy with turning pabbrev mode off in org buffers > with large table where I need to narrow. I could not reproduce it. Columns are automatically expanded whenever contents change in a field (and change is not wrapped within `org-table-with-shrunk-columns'). AFAICT, `pabbrev-scavenge-buffer' uses `with-silent-modifications' so that shouldn't happen. > BTW what's about hiding rows? For very long tables (~100 and more rows) > hiding can be convenient. I do that by running hide-region (a third > package found in elpa). But maybe that feature could be included in org > mode as well? Hiding rows is a different beast. For example, it doesn't make sense to have a feature to hide current row since Org rows are already 1 character high. So, we would only want to hide contiguous rows. But then, the problem is that hlines may disappear and the formulas could be more difficult to write (without using `org-table-toggle-coordinate-overlays'). Perhaps we could only allow to hide columns between 2 hlines. Do you have any idea about the interface of such functionality? Regards, -- Nicolas Goaziou