From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hsiu-Khuern Tang Subject: Re: Unnecessary comma escapes in HTML export of #+INCLUDE files Date: Tue, 1 Sep 2009 17:09:13 -0700 Message-ID: <20090902000913.GS4172@hplhtang.hpl.hp.com> References: <20090722011304.GY16388@hplhtang> <87tz15jgv3.fsf@bzg.ath.cx> <20090722173504.GZ16388@hplhtang> <87vdlizxha.fsf@bzg.ath.cx> <20090724054520.GB2207@hplhtang> <20090901220312.GP4172@hplhtang.hpl.hp.com> <9119.1251845271@alphaville.usa.hp.com> Reply-To: Hsiu-Khuern Tang Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MidQi-0005vL-Rg for emacs-orgmode@gnu.org; Tue, 01 Sep 2009 20:10:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MidQe-0005uo-9J for emacs-orgmode@gnu.org; Tue, 01 Sep 2009 20:10:28 -0400 Received: from [199.232.76.173] (port=53763 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MidQe-0005ul-72 for emacs-orgmode@gnu.org; Tue, 01 Sep 2009 20:10:24 -0400 Received: from madara.hpl.hp.com ([192.6.19.124]:64239) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MidQd-00015z-92 for emacs-orgmode@gnu.org; Tue, 01 Sep 2009 20:10:24 -0400 Received: from mailhub-pa1.hpl.hp.com (mailhub-pa1.hpl.hp.com [15.25.115.25]) by madara.hpl.hp.com (8.14.3/8.14.1/HPL-PA Relay) with ESMTP id n820ABpm022675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 Sep 2009 17:10:11 -0700 (PDT) Received: from hplhtang.hpl.hp.com (hplhtang.hpl.hp.com [15.4.92.39]) by mailhub-pa1.hpl.hp.com (8.14.3/8.14.3/HPL-PA Hub) with ESMTP id n820ABC4007602 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 1 Sep 2009 17:10:11 -0700 Received: from htang by hplhtang.hpl.hp.com with local (Exim 4.69) (envelope-from ) id 1MidPa-0003Vc-SZ for emacs-orgmode@gnu.org; Tue, 01 Sep 2009 17:09:18 -0700 Content-Disposition: inline In-Reply-To: <9119.1251845271@alphaville.usa.hp.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org * On Tue 10:47PM +0000, 01 Sep 2009, Dokos, Nicholas (nicholas.dokos@hp.com) wrote: > Hsiu-Khuern Tang wrote: > > It looks Org has reverted to the old behavior: inserting a comma at a beginning > > of every line in the #INCLUDE'd file that starts with whitespace followed by #. > > > > For example, if you export this as ascii (see > > http://article.gmane.org/gmane.emacs.orgmode/15718): > > > > File 1: a.org > > ================================================== > > * test > > > > #+INCLUDE: "a.sh" src sh > > ================================================== > > > > File 2: a.sh > > ================================================== > > #!/bin/sh > > > > ## shell comment > > echo "This is a test" > > ================================================== > > > > the output contains the line ", ## shell comment". > > > > Related question: what git commands does one use to obtain all the commits that > > changed a particular range of lines in a file? I'm quite lost with git. > > > > There was some churn for this particular functionality, but since I > don't really understand what is *supposed* to happen, I'll just refer > you (and Carsten and Bastien, both of whom made -possibly conflicting- > changes to this functionality) to the following exchange in the archive, > hoping it will shed some light and lead to a satisfactory resolution for > all involved: > > http://thread.gmane.org/gmane.emacs.orgmode/16244/focus=16259 > > > The relevant commits are > > 68b65e8f480c17cfe1024001c236eb4065893f4d > > and > > dfd3749a273cc9f9a1d954363ea6de87049d17a7 > > Thanks, > Nick Thanks for pointing me to the relevant commits, both of which changed the org-get-file-contents function. I'm not sure what the correct behavior for that function is, since it may ultimately be used for different purposes, e.g., to generate an agenda and for exporting. For exporting to various formats, is there any reason to escape Org-like lines -- headers and comments -- of an #INCLUDE'd file, since the file contents are indented in the output anyway and so there can be no confusion? I'm not sure that the indentation occurs for all export formats, but it seems to be the case for ASCII and HTML export. At any rate, the docstring of org-get-file-contents is inconsistent with the behavior: "If MARKUP, don't protect org-like lines, the exporter will take care of the block they are in." It is actually protecting org-like lines when the markup is "src" or "example". -- Best, Hsiu-Khuern.