Hi, Changes are one sentence in the documentations, casing, and I changed the regexp so that :only-contents is valid (it's nil). Nicolas Goaziou writes: > Rasmus writes: > >> It's two extra words and maybe it's helpful to make the concept clear >> to people unfamilar with org-element. The statement "contents of the >> requested element", while technically clear, is only barely >> comprehensible for the uninvited. >> >> However, it's only tweo extra words, so I'm happy to remove them if >> you have strong feeling about this. > > I have no strong feeling. Though, I admit the "etc" these two words > imply annoys me. Anyway, you will be the final judge. Is it better now? >> I don't know what you mean with regular. Anyway, my reasoning is that >> this INCLUDE-command >> >> #+INCLUDE: "/tmp/test0.org" :my-random-prop "foo" >> >> Will give me something like: >> >> \#+\textsc{begin}\(_{\text{my}}\)-random-prop >> \section{test0} >> \label{sec-2} >> 1 >> \#+\textsc{end}\(_{\text{my}}\)-random-prop >> >> In casual testing similar stuff happened when I did not remove the >> match. It could have been it was a bit too casual and that I >> misspelling the property. I will test this properly later. > > OK. I wait for your report. Block sucks up whatever remains, so the match must be removed: (block (and (string-match "\\<\\(\\S-+\\)\\>" value) (match-string 1 value))) I want to discuss one more important potential issue before having the patch applied. Currently, location is ignored if the included part is not an env (line 3381) and not a block (3392). I'm not sure this is right. I could do one of the following: 1. Nothing (current state) 2. Throw an error if location and env or block are combined. 3. Try to use location even if block is set. Recall, though, that location is resolved using org-mode. 4. Let location be a general regexp if env or block is non-nil. But then we are breaking with the org file-link idea. 5. Make location work for org files when env or block, otherwise throw an error. WDYT? Less important. Should the