Re: Unnecessary comma escapes in HTML export of #+INCLUDE files

[Hsiu-Khuern Tang <hsiu-khuern.tang@hp.com>]

* On Tue 10:47PM +0000, 01 Sep 2009, Dokos, Nicholas (nicholas.dokos@hp.com) wrote:
> Hsiu-Khuern Tang <hsiu-khuern.tang@hp.com> 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.