From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: syntax for blocks that the exporter should not render? Date: Thu, 5 Sep 2013 13:57:19 +0200 Message-ID: <3C681BE5-05DA-41A9-8277-7180063D2642@gmail.com> References: <87eh93r35b.fsf@gmail.com> <0B394303-79FD-4990-B731-1F3F36FE02E0@gmail.com> <20130905114303.GB2392@kuru.dyndns-at-home.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHYBj-0003NF-QS for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 07:57:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHYBd-00078a-Vi for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 07:57:27 -0400 Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]:59154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHYBd-00078T-OD for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 07:57:21 -0400 Received: by mail-ea0-f174.google.com with SMTP id z15so837636ead.19 for ; Thu, 05 Sep 2013 04:57:20 -0700 (PDT) In-Reply-To: <20130905114303.GB2392@kuru.dyndns-at-home.com> 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: Suvayu Ali Cc: emacs-orgmode@gnu.org On Sep 5, 2013, at 1:43 PM, Suvayu Ali = wrote: > Hi Carsten, >=20 > On Thu, Sep 05, 2013 at 01:27:57PM +0200, Carsten Dominik wrote: >>=20 >> On Sep 5, 2013, at 12:09 PM, Nicolas Goaziou = wrote: >>=20 >>>>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg >>>>> = http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.j= pg >>>>=20 >>>> I don't think this is the right behavior, such lines should not be = rendered. >>>> Suvayu is right, with a space after the # they are treated as = commendt, but I think >>>> they should also be ignored with the plus. >>>>=20 >>>> Nicolas, what is the reasoning behind rendering them? >>>=20 >>> Because this isn't valid Org syntax, so it is treated as regular = text >>> (i.e. a paragraph). Something similar happens for unbalanced blocks: >>=20 >> So in a way this is a "syntax error" message. :) >>=20 >> OK, I get that point. Is that behaviour documented? >=20 > I think it is more of a "I don't recognise this as special syntax; it > must be text". In that case, I'm not sure what can be documented, one > can have infinitely many text blurbs which look very similar to valid > Org syntax but isn't. >=20 > I have noticed quite a few posts on the list with this kind of > misunderstanding. I think the confusion arises from thinking of = special > keywords like "#+options:", "#+attr_latex:", etc as comments. AFAIU, > they are not. Lines starting with "#+" are possible keywords, whereas > lines starting with "# " are comments. Yes, and I just checked what we have in the manual: Lines starting with zero or more whitespace characters followed by one @samp{#} and a whitespace are treated as comments and will never be = exported. So indeed, the white space after the # is in the manual. I had = forgotten about this. >=20 > I can see how that can be confusing, but can't think of a way to = resolve > this. I have two possibilities in mind: > 1. change "# " to something more distict like: "//", or "##", > 2. use different faces for the two. Another way to do this would be that every line starting with "#" (no = space) is a comment line, except when it is starting with "#+". This = was how I used to think about lines starting with "#". BUt it is not = bad the way it is now - we just need to be aware and tell people - we = just did. Thanks - Carsten >=20 > (1) is probably too big a change, whereas (2) might be feasible. >=20 > Nicolas will probably have a better feeling about what is more > appropriate here. >=20 > Cheers, >=20 > --=20 > Suvayu >=20 > Open source is the future. It sets us free. >=20