Re: [O] [patch, ox] #+INCLUDE resolves links

[Rasmus]

Hi,

Okay, I hope I got a better patch here.  I do — for sure — present
another dreadfully long email!  Let's start.

Nicolas Goaziou <address@hidden> 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 <address@hidden> writes:

> Rasmus <address@hidden> 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!!!

0001-ox-Allow-file-links-with-INCLUDE-keyword.patch
Description: Text Data