File-local export filters

File-local export filters

[Carsten Dominik]

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

Hi everyone

I guess this is mostly a request for Nicolas, but maybe others would
like to chime in.

Quite often I am in a situation where I want to use filters
to customize the export for a specific file.  I was wondering
if it would be useful to support a special source code block
that can contain code that should be executed before export in
a way that a temporary list of export filters is installed
for this specific backend and then removed again.

For example, I would like to have special formatting of
time stamps in a specific file - I could then use this
to install a filter in org-export-filter-timestamp-functions
that would do this special formatting, without influencing
what happens to other exports.

Have I overlooked an easy way to do this, or would this be
something others would like to use as well.

- Carsten

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: File-local export filters

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> I guess this is mostly a request for Nicolas, but maybe others would
> like to chime in.
>
> Quite often I am in a situation where I want to use filters
> to customize the export for a specific file.  I was wondering
> if it would be useful to support a special source code block
> that can contain code that should be executed before export in
> a way that a temporary list of export filters is installed
> for this specific backend and then removed again.
>
> For example, I would like to have special formatting of
> time stamps in a specific file - I could then use this
> to install a filter in org-export-filter-timestamp-functions
> that would do this special formatting, without influencing
> what happens to other exports.
>
> Have I overlooked an easy way to do this, or would this be
> something others would like to use as well.

I didn't check, but I think it is possible to set filter through #+BIND
keyword? Otherwise, you can try file local variables.


Regards,

-- 
Nicolas Goaziou

Re: File-local export filters

[Carsten Dominik]

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


On 21.9.2013, at 13:45, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> I guess this is mostly a request for Nicolas, but maybe others would
>> like to chime in.
>> 
>> Quite often I am in a situation where I want to use filters
>> to customize the export for a specific file.  I was wondering
>> if it would be useful to support a special source code block
>> that can contain code that should be executed before export in
>> a way that a temporary list of export filters is installed
>> for this specific backend and then removed again.
>> 
>> For example, I would like to have special formatting of
>> time stamps in a specific file - I could then use this
>> to install a filter in org-export-filter-timestamp-functions
>> that would do this special formatting, without influencing
>> what happens to other exports.
>> 
>> Have I overlooked an easy way to do this, or would this be
>> something others would like to use as well.
> 
> I didn't check, but I think it is possible to set filter through #+BIND
> keyword? Otherwise, you can try file local variables.

OK, I'll try this.  However, if the code is a bit more extensive, an SRC block would make it more comfortable to maintain this code inside a file.  If I want to write a somewhat complex filter function, it is not convenient to do so in #+BIND line.

- Carsten

> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: File-local export filters

[Nicolas Goaziou]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> OK, I'll try this. However, if the code is a bit more extensive, an
> SRC block would make it more comfortable to maintain this code inside
> a file. If I want to write a somewhat complex filter function, it is
> not convenient to do so in #+BIND line.

I can't see why it would be inconvenient, since you needn't define the
filter within the BIND keyword.

Anyway, you can write a source block that sets locally the filters. That
should work too.


Regards,

-- 
Nicolas Goaziou

Re: File-local export filters

[Carsten Dominik]

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


On 21.9.2013, at 14:44, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> OK, I'll try this. However, if the code is a bit more extensive, an
>> SRC block would make it more comfortable to maintain this code inside
>> a file. If I want to write a somewhat complex filter function, it is
>> not convenient to do so in #+BIND line.
> 
> I can't see why it would be inconvenient, since you needn't define the
> filter within the BIND keyword.
> 
> Anyway, you can write a source block that sets locally the filters. That
> should work too.

OK, I'll give that a try.

Thanks

- Carsten

> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Summary: File-local export filters

[Carsten Dominik]

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


On 21.9.2013, at 14:44, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> OK, I'll try this. However, if the code is a bit more extensive, an
>> SRC block would make it more comfortable to maintain this code inside
>> a file. If I want to write a somewhat complex filter function, it is
>> not convenient to do so in #+BIND line.
> 
> I can't see why it would be inconvenient, since you needn't define the
> filter within the BIND keyword.
> 
> Anyway, you can write a source block that sets locally the filters. That
> should work too.

Indeed, this can be done.  Here is an example (thanks also to Eric for
quick help with the export arguments):

* Special export setup						   :noexport:

#+begin_src emacs-lisp :exports results :results none
  (defun my-org-export-filter-timestamp-function (timestamp backend info)
    "removes relevant brackets from a timestamp"
    (when (org-export-derived-backend-p backend 'html)
      (replace-regexp-in-string "&[gl]t;\\|[][]" "" timestamp)))
  (make-local-variable 'org-export-filter-timestamp-functions)
  (add-to-list 'org-export-filter-timestamp-functions
               'my-org-export-filter-timestamp-function)
#+end_src

- Carsten

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: File-local export filters

[Rasmus]

Hi Carsten,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Have I overlooked an easy way to do this, or would this be
> something others would like to use as well.

Can't you identify it by the folder name?  Or with a
special #+DESCRIPTION or #+KEYWORDS?

Like this: 

#+TITLE: MySpecialFile.org

#+begin_src emacs-lisp
    (defun rasmus/match-buffer (text backend info)
      "Match only some buffers identified by "
      (if (and
           (string-match "MySpecialFile" (plist-get info :input-file))
           (org-export-derived-backend-p backend 'latex))
          "Match!" text)) 
    
    (add-to-list 'org-export-filter-final-output-functions
                 'rasmus/match-buffer) 
#+end_src

Otherwise I'd also bind the value locally and maintain the code in a
SETUPFILE or in a * lisp :noexport: heading.

–Rasmus


-- 
I almost cut my hair, it happened just the other day