Hi, Okay, I hope I got a better patch here. I do — for sure — present another dreadfully long email! Let's start. Nicolas Goaziou writes: >>> #+INCLUDE: file.org::#custom_id :noheadline :lines "3-" > > Is it `:only-contents' or `:no-headline'? Also ":kwd1 :kbd2 value" is > usually a shortcut for ":kwd1 nil :kbd2 value" (at least in export > attributes). Your example is thus confusing, you should include the > expected value. > > #+INCLUDE: "file.org::#custom_id" :only-contents t :lines "3-" Well it's only-contents now. Why? It's more precise in terms of the org-element terminology and it makes more sense when you include, say, a table. >> +elements.}. If the keyword @code{:only-contents} is used, only the >> contents >> +of the element in included. For headlines, drawers and properties > ^^ > >> +assumed to be in Org mode format and will be processed normally. >> File-links >> +will be interpret as well: > ^^^^^^^^^ Sorry about that. Fixed. >> ;;; ox.el --- Generic Export Engine for Org Mode >> - >> ;; Copyright (C) 2012-2014 Free Software Foundation, Inc. > > You can remove this chunk. As above. [I should somehow disable whitespace cleanup when in source repos]. >> + (only-contents >> + (and (string-match >> + ":\\(only-?contents?[[:space:]]*\\(?:'t\\|true\\|yes\\)?\\)" >> value) > > This should be ":only-contents t" or ":only-contents nil". > ":only-contents" alone can be tolerated as a shortcut for > ":only-contents nil", but that's all. Okay, I hope I got it now. It's a rather forgiving regexp in terms of mistakes. Is that OK? >> + (prog1 t >> + (setq value (replace-match "" nil nil value))))) > > Since `replace-match' cannot return nil here, you can remove I did it in another way in the new patch now since to allow for nil values. > (prog1 t ...) > > wrapper. If you insist on ONLY-CONTENTS being t, then No, it's changed. >> + (org-export--prepare-file-contents file location only-contents >> lines)))) > > Couldn't location, only-contents and lines be merged into a single > argument? At the moment, you are either short-circuiting or breaking > guard against circular inclusions (which relies on a combination of > file-name and lines). I try to do that now. So the arguments of `org-export--prepare-file-contents' are now unchanged compared to master. Note that lonely property drawers are now unconditionally discard if they are in the beginning of the buffer — including just after an initial drawer. > IOW, each include keyword could be defined as a triplet of file name, > beginning and ending global positions. You could implement a helper > function to translate FILE LOCATION and ONLY-CONTENTS into this > triplet, > which would then be passed to `org-export--prepare-file-contents'. I just pass a string of line numbers like before. >> -(defun org-export--prepare-file-contents (file &optional lines ind minlevel id) >> +(defun org-export--prepare-file-contents (file &optional location only-contents lines ind minlevel id) >> "Prepare the contents of FILE for inclusion and return them as a string. >> >> +When optional argument LOCATION is a string the matching element >> +identified using `org-link-search' is returned. Note that >> +`org-link-search-must-match-exact-headline' is locally set to >> +non-nil. When ONLY-CONTENTS is non-nil only the contents of the >> +matched element in included. If LOCATION is a headline and >> +ONLY-CONTENTS is non-nil, drawers and property-drawers >> +immediately following the first headline are also removed. >> + >> When optional argument LINES is a string specifying a range of >> lines, include only those lines. >> >> @@ -3420,6 +3437,26 @@ This is useful to avoid conflicts when more than one Org file >> with footnotes is included in a document." >> (with-temp-buffer >> (insert-file-contents file) >> + (org-mode) > > You cannot enforce `org-mode' as the current major mode since you can > include other file types. > >> + (when location >> + (condition-case err >> + ;; enforce consistency in search. >> + (let ((org-link-search-must-match-exact-headline t)) >> + (org-link-search location)) >> + ;; helpful error messages >> + (error (error (format "%s for %s::%s" >> + (error-message-string err) file location)))) >> + (narrow-to-region >> + (org-element-property >> + (if only-contents :contents-begin :begin) (org-element-at-point)) >> + (org-element-property (if only-contents :contents-end :end) >> (org-element-at-point))) >> + ;; get rid of drawers and properties >> + (when only-contents >> + (let ((element (org-element-at-point))) >> + (while (member (org-element-type element) '(drawer >> property-drawer)) >> + (delete-region (org-element-property :begin element) >> + (org-element-property :end element)) >> + (setq element (org-element-at-point)))))) > > This could be handled when building the triplet. However, please do > not > skip drawers (property drawers are fine), as you cannot tell what the > contents are. OK. >> (when lines >> (let* ((lines (split-string lines "-")) >> (lbeg (string-to-number (car lines))) >> @@ -3495,7 +3532,7 @@ with footnotes is included in a document." >> (org-element-normalize-string (buffer-string)))) >> >> (defun org-export-execute-babel-code () >> - "Execute every Babel code in the visible part of current buffer." >> + "ExecUte every Babel code in the visible part of current buffer." > > You can remove this chunk too. Sorry. Nicolas Goaziou writes: > Rasmus writes: > >>> You cannot enforce `org-mode' as the current major mode since you can >>> include other file types. >> >> But then I can't use org-element-at-point: >> >> (with-temp-buffer >> (text-mode) (insert "* test\nmy txt") (goto-char (point-min)) (org-element-at-point)) >> >> (with-temp-buffer >> (org-mode) (insert "* test\nmy txt") (goto-char (point-min)) (org-element-at-point)) > > `org-export--prepare-file-contents' is not called with the same number > of arguments when it is an Org file. You can activate `org-mode' if you > are in this situation (look for (when ind ...) and (when minlevel ...) > in the function). I hope it's OK now. In the new `org-export--inclusion-absolute-lines' I trigger org-mode when a location is given (e.g. file::#h3). This should be OK as only org files should be specified with this sort of link (I believe) and further it's currently only called in the end of `org-export-expand-include-keyword' when we know it's an org file. It doesn't make sense to apply this to source files, right? I will document the functions better before a final patch. Thanks, Rasmus -- Don't panic!!!