* #+INCLUDE: myfile.html html does not include /literally/; Org processes
@ 2014-06-01 4:06 Omid
2014-06-01 4:42 ` Nick Dokos
2014-06-01 7:53 ` Achim Gratz
0 siblings, 2 replies; 24+ messages in thread
From: Omid @ 2014-06-01 4:06 UTC (permalink / raw)
To: emacs-orgmode
Hello,
I am trying to include an HTML file (say myfile.html, which has only
the <body>) in an Org file so that upon export the contents of
myfile.html are /literally/ inserted in the appropriate section of the
exported HTML file. Following
http://orgmode.org/manual/Include-files.html, I used
#+INCLUDE: "myfile.html" html
But checking the exported HTML document, I see that the included HTML
file myfile.html has been "processed" by Org. Other options (such as
src or example) work as expected. How can I get the literal include
behaviour with #+INCLUDE, as if the contents of myfile.html were wrapped
in
#+BEGIN_HTML
#+END_HTML
delimiters?
I don't want to use
#+BEGIN_SRC sh :results html exports results
cat myfile.html
#+END_SRC
for these reasons:
1. myfile.html could be rather large and dumping its contents in the
Org file clutters things up.
2. Changing myfile.html would change the Org file, and makes a mess
since my Org file is under git version control.
Thanks,
--
Omid
Sent from my Emacs
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 4:06 #+INCLUDE: myfile.html html does not include /literally/; Org processes Omid
@ 2014-06-01 4:42 ` Nick Dokos
2014-06-01 4:51 ` Omid
2014-06-01 5:05 ` Omid
2014-06-01 7:53 ` Achim Gratz
1 sibling, 2 replies; 24+ messages in thread
From: Nick Dokos @ 2014-06-01 4:42 UTC (permalink / raw)
To: emacs-orgmode
Omid <omidlink@gmail.com> writes:
> Hello,
>
> I am trying to include an HTML file (say myfile.html, which has only
> the <body>) in an Org file so that upon export the contents of
> myfile.html are /literally/ inserted in the appropriate section of the
> exported HTML file. Following
> http://orgmode.org/manual/Include-files.html, I used
>
> #+INCLUDE: "myfile.html" html
>
Untested, but the doc seems to say that
--8<---------------cut here---------------start------------->8---
#+INCLUDE: "myfile.html" src html
--8<---------------cut here---------------end--------------->8---
should work.
--
Nick
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 4:42 ` Nick Dokos
@ 2014-06-01 4:51 ` Omid
2014-06-01 6:18 ` Nick Dokos
2014-06-01 5:05 ` Omid
1 sibling, 1 reply; 24+ messages in thread
From: Omid @ 2014-06-01 4:51 UTC (permalink / raw)
To: emacs-orgmode
Hello Nick,
Thanks for your reply. But no, src html results in the included HTML
being processed by Org and wrapped in <pre class="src src-html">, just
like if the contents of myfile.html were put in
#+BEGIN_SRC html
#+END_SRC
Omid
Sent from my Emacs
On 06/01/2014 12:42 AM, Nick Dokos wrote:
> Omid <omidlink@gmail.com> writes:
>
>> Hello,
>>
>> I am trying to include an HTML file (say myfile.html, which has only
>> the <body>) in an Org file so that upon export the contents of
>> myfile.html are /literally/ inserted in the appropriate section of the
>> exported HTML file. Following
>> http://orgmode.org/manual/Include-files.html, I used
>>
>> #+INCLUDE: "myfile.html" html
>>
>
> Untested, but the doc seems to say that
>
> --8<---------------cut here---------------start------------->8---
> #+INCLUDE: "myfile.html" src html
> --8<---------------cut here---------------end--------------->8---
>
> should work.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 4:42 ` Nick Dokos
2014-06-01 4:51 ` Omid
@ 2014-06-01 5:05 ` Omid
1 sibling, 0 replies; 24+ messages in thread
From: Omid @ 2014-06-01 5:05 UTC (permalink / raw)
To: emacs-orgmode
Here is a minimal example, in case someone wants to try
myfile.html:
<p>
<b>Hello, World!</b>
</p>
orgincludehtml.org:
* Test
#+INCLUDE: "./myfile.html" html
I am using Org-mode version 8.2.6 (from ELPA) and GNU Emacs 24.3.1.
Omid
Sent from my Emacs
On 06/01/2014 12:42 AM, Nick Dokos wrote:
> Omid <omidlink@gmail.com> writes:
>
>> Hello,
>>
>> I am trying to include an HTML file (say myfile.html, which has only
>> the <body>) in an Org file so that upon export the contents of
>> myfile.html are /literally/ inserted in the appropriate section of the
>> exported HTML file. Following
>> http://orgmode.org/manual/Include-files.html, I used
>>
>> #+INCLUDE: "myfile.html" html
>>
>
> Untested, but the doc seems to say that
>
> --8<---------------cut here---------------start------------->8---
> #+INCLUDE: "myfile.html" src html
> --8<---------------cut here---------------end--------------->8---
>
> should work.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 4:51 ` Omid
@ 2014-06-01 6:18 ` Nick Dokos
0 siblings, 0 replies; 24+ messages in thread
From: Nick Dokos @ 2014-06-01 6:18 UTC (permalink / raw)
To: emacs-orgmode
Omid <omidlink@gmail.com> writes:
> Hello Nick,
>
> Thanks for your reply. But no, src html results in the included HTML
> being processed by Org and wrapped in <pre class="src src-html">, just
> like if the contents of myfile.html were put in
> #+BEGIN_SRC html
>
> #+END_SRC
>
Yes, I misunderstood the doc.
--
Nick
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 4:06 #+INCLUDE: myfile.html html does not include /literally/; Org processes Omid
2014-06-01 4:42 ` Nick Dokos
@ 2014-06-01 7:53 ` Achim Gratz
2014-06-01 8:31 ` Nicolas Goaziou
1 sibling, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2014-06-01 7:53 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]
Omid writes:
> I am trying to include an HTML file (say myfile.html, which has only
> the <body>) in an Org file so that upon export the contents of
> myfile.html are /literally/ inserted in the appropriate section of the
> exported HTML file.
That's not yet possible. The following patch would implement it, but I
guess there are a few things that need to be discussed before this gets
official, if at all. I haven't given it much testing either.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-implement-wrap-for-INCLUDE.patch --]
[-- Type: text/x-patch, Size: 2355 bytes --]
From 425b53146b99b1dd9b9b5d9b96e950dfea81835c Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Sun, 1 Jun 2014 09:49:48 +0200
Subject: [PATCH] ox: implement "wrap" for #+INCLUDE
* lisp/ox.el (org-export-expand-include-keyword): Implement additional
"wrap" parameter for including files literally, wrapped in an
appropriate block (usually an export block). The contents of the
file gets included literally.
This is experimental, the documentation and testing for this feature
is missing!
---
lisp/ox.el | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index be843e6..26d2a9e 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -3305,9 +3305,10 @@ (defun org-export-expand-include-keyword (&optional included dir)
value)
(prog1 (match-string 1 value)
(setq value (replace-match "" nil nil value)))))
- (env (cond ((string-match "\\<example\\>" value) 'example)
- ((string-match "\\<src\\(?: +\\(.*\\)\\)?" value)
- (match-string 1 value))))
+ (env (cond ((string-match "\\(\\<example\\)\\>" value) 'example)
+ ((string-match "\\<wrap\\(?: +\\(.*\\)\\)?" value) 'wrap)
+ ((string-match "\\<src\\(?: +\\(.*\\)\\)?" value) 'src)))
+ (lang (when env (match-string 1 value)))
;; Minimal level of included file defaults to the child
;; level of the current headline, if any, or one. It
;; only applies is the file is meant to be included as
@@ -3340,14 +3341,21 @@ (defun org-export-expand-include-keyword (&optional included dir)
(org-export--prepare-file-contents file lines))))
(format "%s#+BEGIN_EXAMPLE\n%s%s#+END_EXAMPLE\n"
ind-str contents ind-str))))
- ((stringp env)
+ ((eq env 'src)
(insert
(let ((ind-str (make-string ind ? ))
(contents
(org-escape-code-in-string
(org-export--prepare-file-contents file lines))))
(format "%s#+BEGIN_SRC %s\n%s%s#+END_SRC\n"
- ind-str env contents ind-str))))
+ ind-str lang contents ind-str))))
+ ((eq env 'wrap)
+ (insert
+ (let ((ind-str (make-string ind ? ))
+ (contents
+ (org-export--prepare-file-contents file lines)))
+ (format "%s#+BEGIN_%s\n%s%s#+END_%s\n"
+ ind-str lang contents ind-str lang))))
(t
(insert
(with-temp-buffer
--
1.9.3
[-- Attachment #3: Type: text/plain, Size: 199 bytes --]
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 7:53 ` Achim Gratz
@ 2014-06-01 8:31 ` Nicolas Goaziou
2014-06-01 9:26 ` Achim Gratz
0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Goaziou @ 2014-06-01 8:31 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Hello,
Achim Gratz <Stromeko@nexgo.de> writes:
> That's not yet possible. The following patch would implement it, but I
> guess there are a few things that need to be discussed before this gets
> official, if at all. I haven't given it much testing either.
>
> From 425b53146b99b1dd9b9b5d9b96e950dfea81835c Mon Sep 17 00:00:00 2001
> From: Achim Gratz <Stromeko@Stromeko.DE>
> Date: Sun, 1 Jun 2014 09:49:48 +0200
> Subject: [PATCH] ox: implement "wrap" for #+INCLUDE
>
> * lisp/ox.el (org-export-expand-include-keyword): Implement additional
> "wrap" parameter for including files literally, wrapped in an
> appropriate block (usually an export block). The contents of the
> file gets included literally.
Thanks for the patch. However, I'd rather not allow arbitrary blocks
around included files, as it can be the source of some headache (e.g.,
a quote block around an Org file containing a headline). Also we don't
really need it since most use-cases are already supported.
Actually, I think there are two possible ways to handle this:
1. Add a new "export" (or something else) parameter which will wrap
file contents within an export block relative to the current
back-end. Unfortunately, this will not work for exotic back-ends
that do not provide such a block (:export-block property in its
definition). We can always fallback to an example block in this
case, though.
2. Extend "src" syntax to allow Babel parameters after the language.
E.g.,
#+INCLUDE: "file.html" src html :results html
WDYT?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 8:31 ` Nicolas Goaziou
@ 2014-06-01 9:26 ` Achim Gratz
2014-06-01 10:01 ` Nicolas Goaziou
2014-06-01 10:01 ` Omid
0 siblings, 2 replies; 24+ messages in thread
From: Achim Gratz @ 2014-06-01 9:26 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou writes:
> Thanks for the patch. However, I'd rather not allow arbitrary blocks
> around included files, as it can be the source of some headache (e.g.,
> a quote block around an Org file containing a headline). Also we don't
> really need it since most use-cases are already supported.
Fair enough. FWIW, I'm pretty sure the problem of the OP can also be
solved with Babel, perhaps even with an inline function, but I haven't
yet tried and it's likely to be quite a bit less intuitive than using
INCLUDE.
> Actually, I think there are two possible ways to handle this:
>
> 1. Add a new "export" (or something else) parameter which will wrap
> file contents within an export block relative to the current
> back-end. Unfortunately, this will not work for exotic back-ends
> that do not provide such a block (:export-block property in its
> definition). We can always fallback to an example block in this
> case, though.
Please not.
> 2. Extend "src" syntax to allow Babel parameters after the language.
> E.g.,
>
> #+INCLUDE: "file.html" src html :results html
That looks better, but still isn't quite self-explanatory. What
happens if I write
#+INCLUDE: "file.html" src html :results elisp
for instance? That would still wrap the include file with an almost
arbitrary block, no? I don't think you can check that the file to be
included fulfills all the requirements of being included at that point
anyway. Here are two more options with different degrees of iffyness:
#+INCLUDE_HTML: "file.html"
#+BEGIN_HTML
<<"file.html">>
#+END_HTML
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 9:26 ` Achim Gratz
@ 2014-06-01 10:01 ` Nicolas Goaziou
2014-06-01 10:23 ` Achim Gratz
2014-06-01 10:01 ` Omid
1 sibling, 1 reply; 24+ messages in thread
From: Nicolas Goaziou @ 2014-06-01 10:01 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> Nicolas Goaziou writes:
>> Actually, I think there are two possible ways to handle this:
>>
>> 1. Add a new "export" (or something else) parameter which will wrap
>> file contents within an export block relative to the current
>> back-end. Unfortunately, this will not work for exotic back-ends
>> that do not provide such a block (:export-block property in its
>> definition). We can always fallback to an example block in this
>> case, though.
>
> Please not.
Why?
>> 2. Extend "src" syntax to allow Babel parameters after the language.
>> E.g.,
>>
>> #+INCLUDE: "file.html" src html :results html
>
> That looks better, but still isn't quite self-explanatory. What
> happens if I write
>
> #+INCLUDE: "file.html" src html :results elisp
>
> for instance?
The same as if you write
#+INCLUDE: "file.html" src html
but with an additional :results elisp Babel parameter, whatever it may
mean.
> That would still wrap the include file with an almost arbitrary block,
> no?
> I don't think you can check that the file to be included fulfills
> all the requirements of being included at that point anyway.
We don't need to.
I didn't like the "wrap" parameter because it mixes parsed blocks (e.g.,
wrap quote) and raw blocks (e.g., wrap html). It is important to know if
the parser should parse the contents of the file or not. Therefore, the
new syntax, if any, should make it clear. In the current problem, we
mustn't parse the contents of the file.
> Here are two more options with different degrees of iffyness:
>
> #+INCLUDE_HTML: "file.html"
This would extend Org syntax, by a large part. This is not necessary for
the problem at hand.
> #+BEGIN_HTML
> <<"file.html">>
> #+END_HTML
Again, I don't want to extend Org syntax, or only by a tiny part, hence
the two proposals above.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 9:26 ` Achim Gratz
2014-06-01 10:01 ` Nicolas Goaziou
@ 2014-06-01 10:01 ` Omid
2014-06-01 11:24 ` Nicolas Goaziou
1 sibling, 1 reply; 24+ messages in thread
From: Omid @ 2014-06-01 10:01 UTC (permalink / raw)
To: emacs-orgmode
Thank you for the patch, Achim.
On 06/01/2014 05:26 AM, Achim Gratz wrote:
> Nicolas Goaziou writes:
>> Thanks for the patch. However, I'd rather not allow arbitrary blocks
>> around included files, as it can be the source of some headache (e.g.,
>> a quote block around an Org file containing a headline). Also we don't
>> really need it since most use-cases are already supported.
>
> Fair enough. FWIW, I'm pretty sure the problem of the OP can also be
> solved with Babel, perhaps even with an inline function, but I haven't
> yet tried and it's likely to be quite a bit less intuitive than using
> INCLUDE.
>
>> Actually, I think there are two possible ways to handle this:
>>
>> 1. Add a new "export" (or something else) parameter which will wrap
>> file contents within an export block relative to the current
>> back-end. Unfortunately, this will not work for exotic back-ends
>> that do not provide such a block (:export-block property in its
>> definition). We can always fallback to an example block in this
>> case, though.
>
> Please not.
>
>> 2. Extend "src" syntax to allow Babel parameters after the language.
>> E.g.,
>>
>> #+INCLUDE: "file.html" src html :results html
>
> That looks better, but still isn't quite self-explanatory. What
> happens if I write
>
> #+INCLUDE: "file.html" src html :results elisp
>
> for instance? That would still wrap the include file with an almost
> arbitrary block, no? I don't think you can check that the file to be
> included fulfills all the requirements of being included at that point
> anyway. Here are two more options with different degrees of iffyness:
>
> #+INCLUDE_HTML: "file.html"
>
> #+BEGIN_HTML
> <<"file.html">>
> #+END_HTML
>
I think #+INCLUDE: should be just that: Include whatever the user is
asking to. No header arguments dumps the file in Org (as it does now),
subject to the usual processing, and a header argument like html wraps
it in the appropriate delimiter, subject to processing according to
that delimiter. I is up to the user to make sure the included content
doesn't break things or lead to unexpected behavior. This
functionality will be an extension of C's #include (the extension
being the addition of delimiters around the included content if the
user asks that) and in that sense I think it would be most
appropriate.
>
> Regards,
> Achim.
>
Regards,
Omid
Sent from my Emacs
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 10:01 ` Nicolas Goaziou
@ 2014-06-01 10:23 ` Achim Gratz
2014-06-01 11:30 ` Nicolas Goaziou
0 siblings, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2014-06-01 10:23 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou writes:
> I didn't like the "wrap" parameter because it mixes parsed blocks (e.g.,
> wrap quote) and raw blocks (e.g., wrap html). It is important to know if
> the parser should parse the contents of the file or not. Therefore, the
> new syntax, if any, should make it clear. In the current problem, we
> mustn't parse the contents of the file.
That's the only problem? Aside from "quote" not being an export
backend, I'm afraid I don't really see the difference between
#+INCLUDE: "file.ext" src <lang> results: <lang>
and
#+INCLUDE: "file.ext" wrap <lang>
in this case. We can always check if <lang> maps to a valid export
block and drop back to quoting the whole thing like we do with "src" if
not.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 10:01 ` Omid
@ 2014-06-01 11:24 ` Nicolas Goaziou
0 siblings, 0 replies; 24+ messages in thread
From: Nicolas Goaziou @ 2014-06-01 11:24 UTC (permalink / raw)
To: Omid; +Cc: emacs-orgmode
Hello,
Omid <omidlink@gmail.com> writes:
> I think #+INCLUDE: should be just that: Include whatever the user is
> asking to. No header arguments dumps the file in Org (as it does now),
> subject to the usual processing, and a header argument like html wraps
> it in the appropriate delimiter, subject to processing according to
> that delimiter.
We don't need support for arbitrary blocks in keywords INCLUDE. Using
actual blocks will work just fine:
#+BEGIN_QUOTE
#+INCLUDE: "file.org"
#+END_QUOTE
This is very regular: no need for redundancy in these cases.
Though, it cannot work for verbatim blocks[1] for obvious reasons.
That's why INCLUDE syntax provides parameters for both "example" and
"src" blocks. At the moment, there's no support for export blocks. We
just need to add that.
Regards,
[1] And verse blocks, but I'd rather put it aside for now.
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 10:23 ` Achim Gratz
@ 2014-06-01 11:30 ` Nicolas Goaziou
2014-06-01 13:02 ` Achim Gratz
0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Goaziou @ 2014-06-01 11:30 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> Nicolas Goaziou writes:
>> I didn't like the "wrap" parameter because it mixes parsed blocks (e.g.,
>> wrap quote) and raw blocks (e.g., wrap html). It is important to know if
>> the parser should parse the contents of the file or not. Therefore, the
>> new syntax, if any, should make it clear. In the current problem, we
>> mustn't parse the contents of the file.
>
> That's the only problem? Aside from "quote" not being an export
> backend, I'm afraid I don't really see the difference between
>
> #+INCLUDE: "file.ext" src <lang> results: <lang>
>
> and
>
> #+INCLUDE: "file.ext" wrap <lang>
As explained in this thread, it is not necessary to support:
#+INCLUDE: "file.ext" wrap center
> in this case. We can always check if <lang> maps to a valid export
> block and drop back to quoting the whole thing like we do with "src" if
> not.
The "check" part is useless if we assume that any "wrap", "export",
"raw" or whatever parameter implies that the contents of the file are
specific to an export back-end.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 11:30 ` Nicolas Goaziou
@ 2014-06-01 13:02 ` Achim Gratz
2014-06-01 14:00 ` Nicolas Goaziou
0 siblings, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2014-06-01 13:02 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou writes:
> As explained in this thread, it is not necessary to support:
>
> #+INCLUDE: "file.ext" wrap center
I'm still not getting your argument or I misunderstand what you're
trying to say. Using "wrap" should produce an export block and nothing
else. So as long as there can be no export block named "center", the
INCLUDE above would simply raise a user-error (yes, that check isn't in
the quick&dirty patch I posted). And since I think the list of NAMES
that fit this description and is known in advance (by org syntax) and
short, that check is cheap.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 13:02 ` Achim Gratz
@ 2014-06-01 14:00 ` Nicolas Goaziou
2014-06-01 14:27 ` Achim Gratz
0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Goaziou @ 2014-06-01 14:00 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> I'm still not getting your argument or I misunderstand what you're
> trying to say. Using "wrap" should produce an export block and nothing
> else. So as long as there can be no export block named "center", the
> INCLUDE above would simply raise a user-error (yes, that check isn't in
> the quick&dirty patch I posted).
I thought you wanted to be able to wrap the contents within any block.
If you limit it to export blocks, then we're suggesting the same idea.
However, note that "wrap" is confusing because it sounds like Babel's
keyword and yet does something different.
> And since I think the list of NAMES that fit this description and is
> known in advance (by org syntax) ...
Unfortunately, that assumption is slightly wrong. Export blocks are
defined by export back-ends. If the export back-end is not loaded, the
block is a special block. This is not great, but in practice, it doesn't
matter much as we can safely assume all used back-ends are required
already at the time of export. The only export block we know for sure is
the one defined in the current back-end, hence my initial proposal.
Of course, it is still possible to raise a user-error (e.g., "unknown
export block") in front of anything unknown at the time of export.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 14:00 ` Nicolas Goaziou
@ 2014-06-01 14:27 ` Achim Gratz
2014-06-03 20:37 ` Nicolas Goaziou
0 siblings, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2014-06-01 14:27 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou writes:
> However, note that "wrap" is confusing because it sounds like Babel's
> keyword and yet does something different.
I'm not wedded to the name, maybe "export" has a nicer ring to it (but
that#s also been used differently in Babel, just like almost anything
else you#d be able to come up with).
>> And since I think the list of NAMES that fit this description and is
>> known in advance (by org syntax) ...
>
> Unfortunately, that assumption is slightly wrong. Export blocks are
> defined by export back-ends. If the export back-end is not loaded, the
> block is a special block.
What I'm talking about is the list of blocks that never can be export
blocks (CENTER, QUOTE, SRC, COMMENT, EXAMPLE, VERSE). These can be
flagged as errors, anything else is the responsibility of the user.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-01 14:27 ` Achim Gratz
@ 2014-06-03 20:37 ` Nicolas Goaziou
2014-06-04 21:50 ` Achim Gratz
2014-06-07 10:11 ` Achim Gratz
0 siblings, 2 replies; 24+ messages in thread
From: Nicolas Goaziou @ 2014-06-03 20:37 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Hello,
Achim Gratz <Stromeko@nexgo.de> writes:
> I'm not wedded to the name, maybe "export" has a nicer ring to it (but
> that#s also been used differently in Babel, just like almost anything
> else you#d be able to come up with).
True.
> What I'm talking about is the list of blocks that never can be export
> blocks (CENTER, QUOTE, SRC, COMMENT, EXAMPLE, VERSE). These can be
> flagged as errors, anything else is the responsibility of the user.
On second thought, we shouldn't bother too much about it, let the user
provide any keyword, and turn it into a block of the same name.
So, for example, both
#+include: "file.html" html
and
#+include: "file.html" center
are valid, even though the second one makes little sense.
It is close to your initial approach, minus the "wrap" keyword, which
seems unnecessary. If you agree with this suggestion, do you volunteer
to finalize it, along with the required documentation?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-03 20:37 ` Nicolas Goaziou
@ 2014-06-04 21:50 ` Achim Gratz
2014-06-05 9:28 ` Nicolas Goaziou
2014-06-07 10:11 ` Achim Gratz
1 sibling, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2014-06-04 21:50 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou writes:
> On second thought, we shouldn't bother too much about it, let the user
> provide any keyword, and turn it into a block of the same name.
>
> So, for example, both
>
> #+include: "file.html" html
>
> and
>
> #+include: "file.html" center
>
> are valid, even though the second one makes little sense.
>
> It is close to your initial approach, minus the "wrap" keyword, which
> seems unnecessary. If you agree with this suggestion, do you volunteer
> to finalize it, along with the required documentation?
I'll have a look at that later this week.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-04 21:50 ` Achim Gratz
@ 2014-06-05 9:28 ` Nicolas Goaziou
0 siblings, 0 replies; 24+ messages in thread
From: Nicolas Goaziou @ 2014-06-05 9:28 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> Nicolas Goaziou writes:
>> It is close to your initial approach, minus the "wrap" keyword, which
>> seems unnecessary. If you agree with this suggestion, do you volunteer
>> to finalize it, along with the required documentation?
>
> I'll have a look at that later this week.
Thank you.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-03 20:37 ` Nicolas Goaziou
2014-06-04 21:50 ` Achim Gratz
@ 2014-06-07 10:11 ` Achim Gratz
2014-06-07 13:53 ` Nicolas Goaziou
1 sibling, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2014-06-07 10:11 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 562 bytes --]
Nicolas Goaziou writes:
> On second thought, we shouldn't bother too much about it, let the user
> provide any keyword, and turn it into a block of the same name.
>
> So, for example, both
>
> #+include: "file.html" html
>
> and
>
> #+include: "file.html" center
>
> are valid, even though the second one makes little sense.
>
> It is close to your initial approach, minus the "wrap" keyword, which
> seems unnecessary. If you agree with this suggestion, do you volunteer
> to finalize it, along with the required documentation?
Here's the patch for this:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-implement-additional-INCLUDE-markup.patch --]
[-- Type: text/x-patch, Size: 6852 bytes --]
From 3fe089c11b1ca149bbd0f80ee9389a1d7c14e5ed Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Sat, 7 Jun 2014 11:54:02 +0200
Subject: [PATCH] ox: implement additional #+INCLUDE markup
* lisp/ox.el (org-export-expand-include-keyword): Change parsing so
that arbitrary blocks around the included content can be used.
Content is not code-escaped unless it is a literal block, this
applies to "src" and "example".
* doc/org.texi (Include files): Document the additional markup.
* testing/lisp/test-ox.el (test-org-export/expand-include): Add test
for an #+INCLUDE with "html" and "center" markup.
* testing/examples/include.html: New file, used for testing
"#+INCLUDE html".
---
doc/org.texi | 25 +++++++++++++++----------
lisp/ox.el | 29 ++++++++++++++++++-----------
testing/examples/include.html | 1 +
testing/lisp/test-ox.el | 16 ++++++++++++++++
4 files changed, 50 insertions(+), 21 deletions(-)
create mode 100644 testing/examples/include.html
diff --git a/doc/org.texi b/doc/org.texi
index 4548eda..0484ef1 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -9963,13 +9963,18 @@ @section Include files
@end example
@noindent
-The optional second and third parameter are the markup (i.e., @samp{example}
-or @samp{src}), and, if the markup is @samp{src}, the language for formatting
-the contents.
-
-If no markup is given, the text will be assumed to be in Org mode format and
-will be processed normally. However, footnote labels (@pxref{Footnotes}) in
-the file will be made local to that file.
+The first parameter names the the file to include. The optional second and
+third parameter specify the markup (i.e., @samp{example} or @samp{src}), and,
+if the markup is @samp{src}, the language for formatting the contents.
+
+If markup is requested, the included content will be placed within an
+appropriate block@footnote{While you can request paragraphs (@samp{verse},
+@samp{quote}, @samp{center}), there are no checks ensure the result is valid
+Org syntax.}. For markup @samp{example} and @samp{src}, which is requesting
+a literal example, the content will be code-escaped before inclusion. In all
+other cases, the text will be assumed to be in Org mode format and will be
+processed normally. However, footnote labels (@pxref{Footnotes}) in the file
+will be made local to that file.
Contents of the included file will belong to the same structure (headline,
item) containing the @code{INCLUDE} keyword. In particular, headlines within
@@ -9984,9 +9989,9 @@ @section Include files
@end example
You can also include a portion of a file by specifying a lines range using
-the @code{:lines} parameter. The line at the upper end of the range will not
-be included. The start and/or the end of the range may be omitted to use the
-obvious defaults.
+the @code{:lines} keyword parameter. The line at the upper end of the range
+will not be included. The start and/or the end of the range may be omitted
+to use the obvious defaults.
@example
#+INCLUDE: "~/.emacs" :lines "5-10" @r{Include lines 5 to 10, 10 excluded}
diff --git a/lisp/ox.el b/lisp/ox.el
index 584037b..fab4960 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -3313,9 +3313,10 @@ (defun org-export-expand-include-keyword (&optional included dir)
value)
(prog1 (match-string 1 value)
(setq value (replace-match "" nil nil value)))))
- (env (cond ((string-match "\\<example\\>" value) 'example)
+ (env (cond ((string-match "\\<example\\>" value)
+ 'literal)
((string-match "\\<src\\(?: +\\(.*\\)\\)?" value)
- (match-string 1 value))))
+ 'literal)))
;; Minimal level of included file defaults to the child
;; level of the current headline, if any, or one. It
;; only applies is the file is meant to be included as
@@ -3326,7 +3327,11 @@ (defun org-export-expand-include-keyword (&optional included dir)
(prog1 (string-to-number (match-string 1 value))
(setq value (replace-match "" nil nil value)))
(let ((cur (org-current-level)))
- (if cur (1+ (org-reduced-level cur)) 1))))))
+ (if cur (1+ (org-reduced-level cur)) 1)))))
+ (src-args (when (eq env 'literal)
+ (match-string 1 value)))
+ (block (when (string-match "\\<\\([a-zA-Z]+\\)\\>" value)
+ (upcase (match-string 1 value)))))
;; Remove keyword.
(delete-region (point) (progn (forward-line) (point)))
(cond
@@ -3340,22 +3345,24 @@ (defun org-export-expand-include-keyword (&optional included dir)
(error "Recursive file inclusion: %s" file))
(t
(cond
- ((eq env 'example)
+ ((eq env 'literal)
(insert
(let ((ind-str (make-string ind ? ))
+ (arg-str (if (stringp src-args)
+ (format " %s" src-args)
+ ""))
(contents
(org-escape-code-in-string
(org-export--prepare-file-contents file lines))))
- (format "%s#+BEGIN_EXAMPLE\n%s%s#+END_EXAMPLE\n"
- ind-str contents ind-str))))
- ((stringp env)
+ (format "%s#+BEGIN_%s%s\n%s%s#+END_%s\n"
+ ind-str block arg-str contents ind-str block))))
+ ((stringp block)
(insert
(let ((ind-str (make-string ind ? ))
(contents
- (org-escape-code-in-string
- (org-export--prepare-file-contents file lines))))
- (format "%s#+BEGIN_SRC %s\n%s%s#+END_SRC\n"
- ind-str env contents ind-str))))
+ (org-export--prepare-file-contents file lines)))
+ (format "%s#+BEGIN_%s\n%s%s#+END_%s\n"
+ ind-str block contents ind-str block))))
(t
(insert
(with-temp-buffer
diff --git a/testing/examples/include.html b/testing/examples/include.html
new file mode 100644
index 0000000..c9986d3
--- /dev/null
+++ b/testing/examples/include.html
@@ -0,0 +1 @@
+<p>HTML!</p>
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 858d38c..e2af5a3 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -851,6 +851,22 @@ (defmacro org-test-with-parsed-data (data &rest body)
(org-export-expand-include-keyword)
(should (equal (buffer-string)
"#+BEGIN_SRC emacs-lisp\n(+ 2 1)\n#+END_SRC\n")))
+ ;; Inclusion within an html export-block.
+ (org-test-with-temp-text
+ (format
+ "#+INCLUDE: \"%s/examples/include.html\" html"
+ org-test-dir)
+ (org-export-expand-include-keyword)
+ (should (equal (buffer-string)
+ "#+BEGIN_HTML\n<p>HTML!</p>\n#+END_HTML\n")))
+ ;; Inclusion within an center paragraph
+ (org-test-with-temp-text
+ (format
+ "#+INCLUDE: \"%s/examples/include2.org\" center"
+ org-test-dir)
+ (org-export-expand-include-keyword)
+ (should (equal (buffer-string)
+ "#+BEGIN_CENTER\nSuccess!\n#+END_CENTER\n")))
;; Footnotes labels are local to each included file.
(should
(= 6
--
1.9.3
[-- Attachment #3: Type: text/plain, Size: 208 bytes --]
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-06-07 10:11 ` Achim Gratz
@ 2014-06-07 13:53 ` Nicolas Goaziou
0 siblings, 0 replies; 24+ messages in thread
From: Nicolas Goaziou @ 2014-06-07 13:53 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Hello,
Achim Gratz <Stromeko@nexgo.de> writes:
> Here's the patch for this:
Thank you. Some comments follow.
> +If markup is requested, the included content will be placed within an
> +appropriate block@footnote{While you can request paragraphs (@samp{verse},
> +@samp{quote}, @samp{center}), there are no checks ensure the result is valid
> +Org syntax.}. For markup @samp{example} and @samp{src}, which is requesting
> +a literal example, the content will be code-escaped before inclusion. In all
> +other cases, the text will be assumed to be in Org mode format and will be
> +processed normally. However, footnote labels (@pxref{Footnotes}) in the file
> +will be made local to that file.
I do not fully agree with the penultimate sentence. Indeed, text will be
assumed to be in Org mode /only/ if no markup is provided . In all other
cases, contents will be included as-is in the buffer, without assuming
anything. In particular, no footnote transformation will happen. I think
documentation should make it clear.
> + (src-args (when (eq env 'literal)
> + (match-string 1 value)))
Nitpicking: I suggest
(and (eq env 'literal) (match-string 1 value))
> + (block (when (string-match "\\<\\([a-zA-Z]+\\)\\>" value)
> + (upcase (match-string 1 value)))))
Special blocks are not limited to alphabetic range. According to
`org-element-special-block-parser' any non-blank character ("\\S-+") is
valid (e.g., "#+begin_equation*"). Also, there's no need for upcasing.
(and (string-match "\\S-+" value) (match-string 1 value))
> + ;; Inclusion within an html export-block.
> + (org-test-with-temp-text
> + (format
> + "#+INCLUDE: \"%s/examples/include.html\" html"
> + org-test-dir)
> + (org-export-expand-include-keyword)
> + (should (equal (buffer-string)
> + "#+BEGIN_HTML\n<p>HTML!</p>\n#+END_HTML\n")))
> + ;; Inclusion within an center paragraph
> + (org-test-with-temp-text
> + (format
> + "#+INCLUDE: \"%s/examples/include2.org\" center"
> + org-test-dir)
> + (org-export-expand-include-keyword)
> + (should (equal (buffer-string)
> + "#+BEGIN_CENTER\nSuccess!\n#+END_CENTER\n")))
I suggest to move the `should' outside the test to make it a tad bit
easier to debug.
(should
(equal "#+BEGIN_CENTER\nSuccess!\n#+END_CENTER\n"
(org-test-with-temp-text ...)))
Otherwise, it looks good. AFAIC, you can apply it whenever you want.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
@ 2014-09-25 22:36 Omid
2014-09-26 9:07 ` Nicolas Goaziou
2014-09-26 18:53 ` Achim Gratz
0 siblings, 2 replies; 24+ messages in thread
From: Omid @ 2014-09-25 22:36 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Stromeko
Hello,
Apologies for waking up this old thread. But is this feature, for
which Achim proposed a patch early on, going to be included in the Org
mode? As of Org-mode version 8.2.7c (8.2.7c-71-g60418c-elpa)
#+INCLUDE: "myfile.html" html
still does not do a literal include.
The last discussion I saw of it was
https://lists.gnu.org/archive/html/emacs-orgmode/2014-06/msg00028.html
In any case, could you (Achim Gratz) please share with us the final
patch that you and Nicolas Goaziou agreed upon?
Thanks,
--
Omid
GPG: 0x371DC12B (see https://u.fsf.org/yw)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-09-25 22:36 Omid
@ 2014-09-26 9:07 ` Nicolas Goaziou
2014-09-26 18:53 ` Achim Gratz
1 sibling, 0 replies; 24+ messages in thread
From: Nicolas Goaziou @ 2014-09-26 9:07 UTC (permalink / raw)
To: Omid; +Cc: Stromeko, emacs-orgmode
Hello,
Omid <omidlink@gmail.com> writes:
> Apologies for waking up this old thread. But is this feature, for
> which Achim proposed a patch early on, going to be included in the Org
> mode? As of Org-mode version 8.2.7c (8.2.7c-71-g60418c-elpa)
>
> #+INCLUDE: "myfile.html" html
>
> still does not do a literal include.
IIRC, this feature is applied on master (i.e., future Org 8.3) not in
maint, which you are currenty using.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes
2014-09-25 22:36 Omid
2014-09-26 9:07 ` Nicolas Goaziou
@ 2014-09-26 18:53 ` Achim Gratz
1 sibling, 0 replies; 24+ messages in thread
From: Achim Gratz @ 2014-09-26 18:53 UTC (permalink / raw)
To: emacs-orgmode
Omid writes:
> In any case, could you (Achim Gratz) please share with us the final
> patch that you and Nicolas Goaziou agreed upon?
That is commit 4ed554196b on master.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-09-26 18:54 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-01 4:06 #+INCLUDE: myfile.html html does not include /literally/; Org processes Omid
2014-06-01 4:42 ` Nick Dokos
2014-06-01 4:51 ` Omid
2014-06-01 6:18 ` Nick Dokos
2014-06-01 5:05 ` Omid
2014-06-01 7:53 ` Achim Gratz
2014-06-01 8:31 ` Nicolas Goaziou
2014-06-01 9:26 ` Achim Gratz
2014-06-01 10:01 ` Nicolas Goaziou
2014-06-01 10:23 ` Achim Gratz
2014-06-01 11:30 ` Nicolas Goaziou
2014-06-01 13:02 ` Achim Gratz
2014-06-01 14:00 ` Nicolas Goaziou
2014-06-01 14:27 ` Achim Gratz
2014-06-03 20:37 ` Nicolas Goaziou
2014-06-04 21:50 ` Achim Gratz
2014-06-05 9:28 ` Nicolas Goaziou
2014-06-07 10:11 ` Achim Gratz
2014-06-07 13:53 ` Nicolas Goaziou
2014-06-01 10:01 ` Omid
2014-06-01 11:24 ` Nicolas Goaziou
-- strict thread matches above, loose matches on Subject: below --
2014-09-25 22:36 Omid
2014-09-26 9:07 ` Nicolas Goaziou
2014-09-26 18:53 ` Achim Gratz
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).