* #+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: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: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: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 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: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-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 ` 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-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).