From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)] Date: Wed, 24 Aug 2011 10:26:35 +0200 Message-ID: <87ty97f7ai.fsf@altern.org> References: <87pqjwfb0b.fsf@gmail.com> <87bovgf7tc.fsf@gmail.com> <87sjosxft3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:34371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwAQA-00039P-HB for emacs-orgmode@gnu.org; Wed, 24 Aug 2011 06:10:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QwAQ8-00063O-Vq for emacs-orgmode@gnu.org; Wed, 24 Aug 2011 06:10:54 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:37883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwAQ8-00062a-JS for emacs-orgmode@gnu.org; Wed, 24 Aug 2011 06:10:52 -0400 Received: by mail-fx0-f41.google.com with SMTP id 9so1029756fxg.0 for ; Wed, 24 Aug 2011 03:10:52 -0700 (PDT) In-Reply-To: (=?iso-8859-1?Q?=22?= =?iso-8859-1?Q?Andr=E1s?= Major"'s message of "Wed, 24 Aug 2011 06:35:10 +0000 (UTC)") 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: =?iso-8859-1?Q?Andr=E1s?= Major Cc: emacs-orgmode@gnu.org Hi András, András Major writes: > I fully agree with you, but it looks like I didn't express my point > clearly enough. Thanks for taking the time to make this clear. > if the tag :noexport: is only supposed > to work in headlines, then I consider it a bug if it works elsewhere, > so the developers must actually make sure that this never happens. Fully agreed. The right thing to do is to fix it. > By saying that a "feature" must work if and only if it is so > documented I refer to individual features (such as keywords, tags, > keystrokes, etc.), not use cases. Yes, let's try to be consistent about this. Now, taking practically, this is something we can do on a use-case basis: in the issue your raised, we fix the problem then fix the doc if necessary. And we can deal with future similar issues like this. Thanks again, -- Bastien