From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kaushal Modi Subject: Re: Unable to retrieve :parameters for src-block [org-element] Date: Tue, 17 Oct 2017 17:22:43 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11488d16a34c1f055bc15f30" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e4VZy-0007LK-Q3 for emacs-orgmode@gnu.org; Tue, 17 Oct 2017 13:22:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e4VZx-0008JU-Mn for emacs-orgmode@gnu.org; Tue, 17 Oct 2017 13:22:58 -0400 Received: from mail-qt0-x22a.google.com ([2607:f8b0:400d:c0d::22a]:48887) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e4VZx-0008IF-I0 for emacs-orgmode@gnu.org; Tue, 17 Oct 2017 13:22:57 -0400 Received: by mail-qt0-x22a.google.com with SMTP id f8so5169985qta.5 for ; Tue, 17 Oct 2017 10:22:55 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: "Berry, Charles" Cc: emacs-org list --001a11488d16a34c1f055bc15f30 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 17, 2017 at 12:31 PM Berry, Charles wrote: > The copy buffer that org-export-as sets up will contain this src block > *after* the babel process runs. > > As you can see the headers are stripped off of it. > Oh! That explains! > So you need to do something tricky to hold onto those headers. I do not > know of a seamless way to do this. FWIW, this is handled in ox-ravel by > hacking babel so it produces #+ATTR_ lines just before the src block result > in the copy buffer. Those lines hold the header info which the ravel > exporter trancoders can consult. > I like that approach. I found your ox-ravel project on GitHub and have tangled it to ox-ravel.el. It would be great if you an paste the revelant snippets of code here as that library is ~800 lines. I still hope there is some way to prevent doing this hack, or if a non-intrusive change in Org code can still have the :parameters available during export. Would it be possible to remove *only* babel-recognized parameters and leave the unidentified parameters (which could be specific to an exporter) intact? -- Kaushal Modi --001a11488d16a34c1f055bc15f30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 17= , 2017 at 12:31 PM Berry, Charles <c= cberry@ucsd.edu> wrote:
The = copy buffer that org-export-as sets up will contain this src block *after* = the babel process runs.

As you can see the headers are stripped off of it.
Oh! That explains!
=C2=A0
So you need to do something tricky to hold onto those headers= .=C2=A0 I do not know of a seamless way to do this.=C2=A0 FWIW, this is han= dled in ox-ravel by hacking babel so it produces #+ATTR_ lines just before = the src block result in the copy buffer. Those lines hold the header info w= hich the ravel exporter trancoders can consult.

I like that approach. I found your ox-ravel project on GitHub and = have tangled it to ox-ravel.el.

It would be great = if you an paste the revelant snippets of code here as that library is ~800 = lines.

I still hope there is some way to prevent d= oing this hack, or if a non-intrusive change in Org code can still have the= :parameters available during export. Would it be possible to remove *only*= babel-recognized parameters and leave the unidentified parameters (which c= ould be specific to an exporter) intact?
= --

Kaushal Modi

--001a11488d16a34c1f055bc15f30--