Fwd: including external file in src block execution; ATTR_HTML on src blocks

[Matt Price <moptop99@gmail.com>]

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

(sent to Charles direcly by mistake. Charles, this resend gave me the
chance to modify my response)
On Mon, Dec 12, 2016 at 10:52 PM, Charles C. Berry <ccberry@ucsd.edu> wrote:

> On Mon, 12 Dec 2016, Matt Price wrote:
>
> On Mon, Dec 12, 2016 at 12:16 PM, Charles C. Berry <ccberry@ucsd.edu>
>> wrote:
>>
>> On Mon, 12 Dec 2016, Matt Price wrote:
>>>
>>>
>>> [snip]
>>>
>>>
>>> My questions are:
>>>> 1. can I pass this html attribute to the <pre><code> block somehow?
>>>>
>>>>
>>> Yes.
>>>
>>> ATTR_HTML doesn't seem to work.  Is this a bug? If so, should I try to
>>> fix
>>>
>>>> it?
>>>>
>>>>
>>> No and no.
>>>
>>> Did you try
>>>
>>> : (plist-get (cadr src-block) :attr_html)
>>>
>>> in `org-html-src-block' ?
>>>
>>>
>>> ah, ok.  Now I will reveal some of the depths of my ignorance.  Looks
>> like
>> :attr_html is a plist (right?).
>>
>
> No, it is a property name. (cadr src-block) is the plist.
>

:-)  I think what I meant was, looks like (org-export-read-attribute
:attr_html src-block) RETURNS a plist.  But that doesn't seem to be quite
true, if I'm understanding properly what a plist is.

Instead it returns a list of this form:
(:code_attribs data-external-libs="https://cdnjs.cloudflare.com/ajax/
libs/jquery/3.1.1/jquery.js" data-other="other" :class some class list)

 Access to the :properties only seems reliable through
(org-export-read-attribute :attr_html src_plock :propname), which returns
what should be an odd list of symbols (?) as a string. Again, it seems
somewhat mysterious to me.

UPDATE: despite the tentative solution seen below, I guess maybe the
#+ATTR_XXX attributes are not intended for iteration as I describe, but
instead each such attribute should have a well-specified function that the
exporter knows about.  If I'm adding attributes -- and it turns out that
ox-reveal can interpret a :code_attribs attribute that I hadn't known about
-- then I feel like I should structure them in an expected way.  I haven't
found documentation about the best practice here and would definitely
appreciate further pointers.


> See (info "(elisp) Property Lists")
>
>
> (a) what is the appropriate way to identify an attribute here.  should I
>> write, e.g.:
>>
>> #+ATTR_HTML: :data-external-libs "http://underscorejs.org/under
>> score-min.js"
>> :class "list of classes"
>>
>
> Any could be made to work, but I'd use (a). Then
>
> : (org-babel-parse-header-arguments
> :  (car (plist-get (cadr src-block) :attr_html)))
>
> will give you
>
> : ((:data-external-libs . "http://underscorejs.org/underscore-min.js") :
>  (:class . "list of classes"))
>

ah, ok, thank you.   Someday I hope I really understand list objects and
how to transform them.  I think part of the problem is that, unlike in some
other languages, programming effectively requires a proper understanding of
*what the objects are that you're manipulating*, and I'm just a bit too
stupid to learn this effectively on my own.

And then, if I want to transform this into:
>


>
>> data-external-libs="http://underscorejs.org/underscore-min.js"
>> class="list
>> of classes"
>>
>> can I just do something like:
>> (let ((attributes (org-export-get-attribute :attr_html src-block))
>>  (cl-loop for (key value) in attributes
>>    (collect (concat key "=" "\"" value "\" " ))))
>>
>> or do I need to transform the key into a string first?
>>
>
> Well, I'd just try it and see.
>
:-) Seems like I should be able to manage this now!


> I'm sorry to be writing such basic lisp questions; obviously I need to read
>> a really good lisp introduction, but I haven't found one yet.
>>
>>
> This is what I use:
>
> * Elisp: (elisp).               The Emacs Lisp Reference Manual.
> * Emacs Lisp Intro: (eintr).    A simple introduction to Emacs Lisp
> programming.
>
> and ample Googling, usually leading to StackOverflow, to get hints on
> stuff I am fuzzy on. And I read docstrings over and over and ...
>

This is the method i'm using, but for me it's veeeeerrrrry slow.



>
> Best,
>
> Chuck
>

Thank you Chuck!

[-- Attachment #2: Type: text/html, Size: 7505 bytes --]