Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Hello, Omid omidl...@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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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)
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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: From 3fe089c11b1ca149bbd0f80ee9389a1d7c14e5ed Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@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 @@
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Hello, Achim Gratz strom...@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\npHTML!/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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Hello, Achim Gratz strom...@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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Omid omidl...@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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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. From 425b53146b99b1dd9b9b5d9b96e950dfea81835c Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@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 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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Hello, Achim Gratz strom...@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 strom...@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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Achim Gratz strom...@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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Hello, Omid omidl...@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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Achim Gratz strom...@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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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 quickdirty 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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Achim Gratz strom...@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 quickdirty 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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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
[O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Omid omidl...@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
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
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 omidl...@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.
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Here is a minimal example, in case someone wants to try myfile.html: p bHello, 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 omidl...@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.