From: Jason Ross <jasonross1024@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Best way to include METAPOST in ConTeXt exporter
Date: Tue, 5 Oct 2021 07:40:12 -0700 [thread overview]
Message-ID: <CABcgBKJmR4yCTFW996efrmBE1D2pb6=2D68yKXByCS6bnqGG4A@mail.gmail.com> (raw)
In-Reply-To: <87o884buwf.fsf@localhost>
(Apologies to Ihor who I already replied to without cc'ing the list)
=======================================================
> If you are in control of the export backend, you can directly process
> the metapost source blocks during export and ignore/filter their output
> as needed.
This is definitely possible, but I don't want to commit to bypassing the
entire Org Babel system right now. I will explore this a bit.
> Or you can use "raw" results by default and format everything as you
> wish in your Org Babel module programatically.
I'm not sure I understand this yet. Would this emit METAPOST code to the
Org buffer? Ideally, I'd like to emit METAPOST code if the backend is
`context`, otherwise, emit a file.
> If above is not sufficient, you can install global export filters that
> can transform the metapost blocks/source blocks/their results as you
> need in other export backends.
This sounds like it might be a good solution. Is it possible to have an
export filter that changes the header arguments of a source block before
Org Babel sees them? If so, ox-context could change all METAPOST source
block header arguments to give raw results wrapped in appropriate tags.
Also, I'm still curious if there's a better way to add #+CAPTION and
#+NAME tags to images generated by source blocks (in any context). It
would be extremely handy to reference figures generated with
matplotlib throughout the document, not just METAPOST drawings.
Thanks,
Jason
On Mon, Oct 4, 2021 at 9:44 AM Ihor Radchenko <yantar92@gmail.com> wrote:
>
> Jason Ross <jasonross1024@gmail.com> writes:
>
> > I had considered using special blocks; they match my mental model the best.
> > However, they don't provide any support for syntax highlighting or opening
> > the block in a new major mode buffer. I'm not sure if it's worth giving up
> > language features in order to use the block that's most intuitive to users.
> >
> > I'm also considering writing an Org Babel module for METAPOST. This could
> > allow METAPOST figures to be included with any export backend. However,
> > if I go this route, there are still some challenges:
>
> If you are in control of the export backend, you can directly process
> the metapost source blocks during export and ignore/filter their output
> as needed.
>
> > #+MACRO: conditional-header (eval (when (not (eq
> > org-export-current-backend 'context)) (concat "#+HEADER: :results
> > file :file " $1)))
>
> > #+BEGIN_SRC metapost :results drawer :post
> > wrap_metapost(name="my-name", caption="my-caption", data=*this*)
>
> Or you can use "raw" results by default and format everything as you
> wish in your Org Babel module programatically.
>
> If above is not sufficient, you can install global export filters that
> can transform the metapost blocks/source blocks/their results as you
> need in other export backends.
>
> Best,
> Ihor
next prev parent reply other threads:[~2021-10-05 15:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-03 17:53 Best way to include METAPOST in ConTeXt exporter Jason Ross
2021-10-04 8:41 ` Ihor Radchenko
2021-10-04 15:41 ` Jason Ross
2021-10-04 16:46 ` Ihor Radchenko
2021-10-05 14:40 ` Jason Ross [this message]
2021-10-05 19:50 ` Jason Ross
2021-10-13 6:51 ` Ihor Radchenko
2021-10-13 6:54 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABcgBKJmR4yCTFW996efrmBE1D2pb6=2D68yKXByCS6bnqGG4A@mail.gmail.com' \
--to=jasonross1024@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).