Using org-map-entries with org-export-before-processing-hook

Using org-map-entries with org-export-before-processing-hook

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

I've attached a minimum org file that shows what I'm trying to do:
essentially to attach a hook to the export process that ends up calling
org-map-entries to make alterations to the file just before it's
exported.

As I've got it now, the hook does change the org buffer, but those
changes are *not* reflected in the exported output. I can only guess
that somehow the export process is able to continue on before the
org-map-entries results are returned? Doesn't seem likely, but...

This is actually kind of the opposite of what I'd like: to have the
changes *only* reflected in the export, and leave the original buffer
unchanged. On the other hand, I can see what thought and care has gone
into setting up a clone buffer for export (and I do need to rely on
buffer-local variables), so maybe an (undo) is my best solution for
returning the buffer to its pre-export state.

But I would like the changes to show up in the exported file!

Thanks in advance,

Eric


[-- Attachment #2: test2.org --]
[-- Type: application/vnd.lotus-organizer, Size: 644 bytes --]

Re: Using org-map-entries with org-export-before-processing-hook

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I've attached a minimum org file that shows what I'm trying to do:
> essentially to attach a hook to the export process that ends up calling
> org-map-entries to make alterations to the file just before it's
> exported.
>
> As I've got it now, the hook does change the org buffer, but those
> changes are *not* reflected in the exported output. I can only guess
> that somehow the export process is able to continue on before the
> org-map-entries results are returned? Doesn't seem likely, but...
>
> This is actually kind of the opposite of what I'd like: to have the
> changes *only* reflected in the export, and leave the original buffer
> unchanged. On the other hand, I can see what thought and care has gone
> into setting up a clone buffer for export (and I do need to rely on
> buffer-local variables), so maybe an (undo) is my best solution for
> returning the buffer to its pre-export state.
>
> But I would like the changes to show up in the exported file!

The problem is not directly related to the export framework, but to its
relationship with `org-map-entries'.

If you use the following function:

  (defun before-export-test (backend)
    ;; (org-map-entries 'test-map "TODO=\"TODO\"" 'file)
    (while (re-search-forward "^\\*+ TODO" nil t)
      (test-map)))

it should work.

I don't know why `org-map-entries' behaves badly with export. Meanwhile,
I suggest to not use this function for export hooks.


Regards,

-- 
Nicolas Goaziou

Re: Using org-map-entries with org-export-before-processing-hook

[Eric Abrahamsen]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I've attached a minimum org file that shows what I'm trying to do:
>> essentially to attach a hook to the export process that ends up calling
>> org-map-entries to make alterations to the file just before it's
>> exported.
>>
>> As I've got it now, the hook does change the org buffer, but those
>> changes are *not* reflected in the exported output. I can only guess
>> that somehow the export process is able to continue on before the
>> org-map-entries results are returned? Doesn't seem likely, but...
>>
>> This is actually kind of the opposite of what I'd like: to have the
>> changes *only* reflected in the export, and leave the original buffer
>> unchanged. On the other hand, I can see what thought and care has gone
>> into setting up a clone buffer for export (and I do need to rely on
>> buffer-local variables), so maybe an (undo) is my best solution for
>> returning the buffer to its pre-export state.
>>
>> But I would like the changes to show up in the exported file!
>
> The problem is not directly related to the export framework, but to its
> relationship with `org-map-entries'.
>
> If you use the following function:
>
>   (defun before-export-test (backend)
>     ;; (org-map-entries 'test-map "TODO=\"TODO\"" 'file)
>     (while (re-search-forward "^\\*+ TODO" nil t)
>       (test-map)))
>
> it should work.
>
> I don't know why `org-map-entries' behaves badly with export. Meanwhile,
> I suggest to not use this function for export hooks.

That'll work! Thanks for looking at this.

E

Re: Using org-map-entries with org-export-before-processing-hook

[Nicolas Goaziou]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> The problem is not directly related to the export framework, but to its
>> relationship with `org-map-entries'.
>>
>> If you use the following function:
>>
>>   (defun before-export-test (backend)
>>     ;; (org-map-entries 'test-map "TODO=\"TODO\"" 'file)
>>     (while (re-search-forward "^\\*+ TODO" nil t)
>>       (test-map)))
>>
>> it should work.
>>
>> I don't know why `org-map-entries' behaves badly with export. Meanwhile,
>> I suggest to not use this function for export hooks.
>
> That'll work! Thanks for looking at this.

I think I fixed the problem wrt `org-map-entries' and export.

You cannot use `file' scope, since it refers to the base buffer
associated to the current buffer file name, which never is the buffer
where the export process takes place.

OTHO, a nil scope (or tree, region for that matter) should be fine with
a very recent Org.


Regards,

-- 
Nicolas Goaziou

Re: Using org-map-entries with org-export-before-processing-hook

[Eric Abrahamsen]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> The problem is not directly related to the export framework, but to its
>>> relationship with `org-map-entries'.
>>>
>>> If you use the following function:
>>>
>>>   (defun before-export-test (backend)
>>>     ;; (org-map-entries 'test-map "TODO=\"TODO\"" 'file)
>>>     (while (re-search-forward "^\\*+ TODO" nil t)
>>>       (test-map)))
>>>
>>> it should work.
>>>
>>> I don't know why `org-map-entries' behaves badly with export. Meanwhile,
>>> I suggest to not use this function for export hooks.
>>
>> That'll work! Thanks for looking at this.
>
> I think I fixed the problem wrt `org-map-entries' and export.
>
> You cannot use `file' scope, since it refers to the base buffer
> associated to the current buffer file name, which never is the buffer
> where the export process takes place.

Whoa, not only does it work, it leaves the original buffer unmodified,
as per my wishlist. Many thanks! I don't know when you find the time to
sleep.

E