From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [export] org-export-with-* bugs Date: Wed, 18 Dec 2013 14:31:46 +0100 Message-ID: <87k3f28ev1.fsf@gmail.com> References: <87d2kxfou8.fsf@gmail.com> <87wqj38jy3.fsf@gmail.com> <87mwjyenoh.fsf@gmail.com> 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]:36067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtHDt-0007fQ-4L for emacs-orgmode@gnu.org; Wed, 18 Dec 2013 08:31:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtHDk-0003rC-6A for emacs-orgmode@gnu.org; Wed, 18 Dec 2013 08:31:37 -0500 Received: from mail-we0-x22e.google.com ([2a00:1450:400c:c03::22e]:36696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtHDj-0003qy-W4 for emacs-orgmode@gnu.org; Wed, 18 Dec 2013 08:31:28 -0500 Received: by mail-we0-f174.google.com with SMTP id q58so7569557wes.33 for ; Wed, 18 Dec 2013 05:31:26 -0800 (PST) Received: from selenimh ([91.224.148.150]) by mx.google.com with ESMTPSA id fj8sm4102509wib.1.2013.12.18.05.31.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Dec 2013 05:31:25 -0800 (PST) In-Reply-To: <87mwjyenoh.fsf@gmail.com> (Aaron Ecay's message of "Wed, 18 Dec 2013 00:24:46 -0500") 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hello, Aaron Ecay writes: > 2013ko abenudak 17an, Nicolas Goaziou-ek idatzi zuen: >> The more I look at it, the more I'm inclined to think that it's totally >> useless. I don't think anyone wants tables removed from Org syntax. >>=20 >> Though, occasionally some line starting with "|" can be interpreted as >> a table. In this case, it's possible to use "\vert" entity anyway. >>=20 >> I'm not sure it is worth fixing. I think we really should remove it, or >> change its meaning, like "|:nil means that all tables are ignored in >> export process" (which is probably almost as useless). The same goes for >> "::nil". > > I think either suggestion (total removal or changing semantics) is a > reasonable option. I'll ask the question in a separate thread. > (fixed-width is one of the branches in the =E2=80=98case=E2=80=99 form in= the new > code...?) Indeed. I attached the draft, not the real patch. I committed the latter. > I can confirm the fix. It looks like the new mechanism is equivalent to > a parse tree filter. It is exactly a parse tree filter. > Should org-export--remove-uninterpreted be added to the default value > of org-export-filter-parse-tree-functions, rather than hard-coding it > into org-export-as? No, it shouldn't. `org-export-filter-parse-tree-functions' is meant for user's consumption. For example, export back-end have their own way to add such a filter without clobbering the variable. In this case, the implemented behaviour is clearly not optional, so it is logically hard-coded. Thank you for reporting the problem. Regards, --=20 Nicolas Goaziou