emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: [BABEL] [PROPOSAL] Seemless editing of Babel Blocks


From: Eric Schulte
Subject: [Orgmode] Re: [BABEL] [PROPOSAL] Seemless editing of Babel Blocks
Date: Sun, 05 Sep 2010 13:12:12 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Hi,

Dan Davison <address@hidden> writes:

> Jambunathan K <address@hidden> writes:
>
>>
>> jambu> How about providing user-accessible tapping points within
>> jambu> 'org-babel-map-src-blocks' (or a variation thereof) that would
>> jambu> enable me have a custom command in my .emacs.
>> jambu>
>> jambu> For the sake of record, my suggestion is very closely related to
>> jambu> what is discussed here.
>> jambu>
>> jambu> 
>> http://eschulte.github.com/babel-dev/PROPOSED-tangle-entire-org-mode-file-in-comments.html
>>
>> Eric> I've just pushed up an implementation of the functionality
>> Eric> described at the link above, see [1] for examples and details.
>> Eric>
>> Eric> Is this sufficient to satisfy the need you were addressing?  If
>> Eric> not how could it be improved?
>>
>> Eric> Footnotes: 
>> Eric> [1]  
>> http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>>
>> I am making a request for an API from BABEL core which roughly parallels
>> org's org-map-entries.
>>
>> Using this API a user should be able to 'traverse' babel and non-babel
>> blocks within a given scope (region, buffer), examine the local state
>> (say a tag or a user-defined property on a subtree), provide a verdict
>> on it's inclusion (yes I want it, no skip it) or possibly return a
>> transformed custom content (as a list).
>>
>> 'org-babel-map-src-blocks' has the skeletal structure for this API. All
>> it needs is some minimal tinkering to take on a more user-pluggable
>> form.
>
>> The proposed API would make UseCase-1 and UseCase-2 possible.
>>
>> UseCase-1: 
>> http://article.gmane.org/gmane.emacs.orgmode/28823
>>
>> Section-6 provides an illustration.
>> Section-5 helps one visualize the essentials of the propsed API.
>>
>> a) org-to-org-src-view => potential consumer of the proposed API.
>> b) beg-org, end-org, beg-babel, end-babel => strategic 'points' of
>>    user-interest.

I'll make a guess here that beg/end-org and the beginning and end of the
code block, and beg/end-babel are the beginning and end of the code
block?

This seems reasonable, and it's a minor change to let-bind all of the
relevant match-data points (like those 4 mentioned above) to temporary
variables which would then make them available to users of
ob-map-src-blocks.  I've just pushed up an enhanced ob-map-src-blocks
which implements the above.  I'll include the new docstring below [1]

>> 
>> c) body, body1 => Hooks for user
>

I don't know what you mean by hooks for the user.  When would these
hooks be run?

>
> Hi Jambunathan,
>
> I assume that beg-babel and end-babel are the start and end of the
> current code block. What exactly are beg-org and end-org here?
>
>>
>> UseCase-2: Tangling with custom pragmas.
>> http://article.gmane.org/gmane.emacs.orgmode/29805
>>
>> Additional Note: Thinking out loud here (aka contrived, over-the-top
>> requirement). 
>>
>> A user might want to override the in-buffer babel-control parameters
>> while tangling or execution.
>>
>> Think of this scenario, I would like to tangle but with comments and
>> line nos as a one-off (say for circulating to my colleagues). The
>> in-buffer 'static/default' settings suppresses comments. I couldn't be
>> bothered to edit the in-buffer settings just for this one-off case. Is
>> there a possible way I can achieve this?
>
> Many of the core org-babel functions accept an optional argument named
> `info'. This is a data structure which contains all the relevant
> settings: language, the body, the header args, etc. If this argument is
> provided, then no attempt is made to obtain the settings from the
> buffer. So the way to do this is to construct your own info data
> structure and then pass it to the org-babel function you are using
> (e.g. org-babel-execute-src-block).
>
> Typically, the info structure is created from the buffer using
> org-babel-get-src-block-info. See the docstring of that function for a
> definition of the data structure.
>
> As an example of on-the-fly construction of an info data structure (and
> thus a "virtual" code block that doesn't exist in any buffer), see the
> way Eric implemented #+lob calls in `org-babel-lob-execute' (it's quite
> clever).
>
> Also note in those functions that there is a useful function
> `org-babel-merge-params': In org-babel code, "params" generally means an
> association list of header argument (argument, value)
> pairs. `org-babel-merge-params' allows you to construct the params alist
> from a variety of different sources (the buffer settings, and your own
> settings): later arguments have priority over earlier ones. Grepping for
> org-babel-merge-params in the code shows some examples of using it to
> construct the "params" part of the "info" structure, e.g.:
>
> ob-ref.el:162:        (setq params (org-babel-merge-params params args 
> '((:results . "silent"))))
> ob-table.el:119:                      (org-babel-merge-params '((:results . 
> "silent")) params))))
>
>
> Based on a very quick look, it seems that tangle is gloing to be
> slightly different from execute. For tangle, you might want to use a
> let-binding to bind a temporary value of org-babel-default-header-args,
> constructed using org-babel-merge-params as on line 146 of ob-tangle.el.
>
> Dan
>

I would just add to Dan's suggestions that it may be nice to expose a
function which allows the user to control the params string on an
evaluation by evaluation through an interface which tab-completes header
arguments.  This shouldn't be difficult if done using the
org-babel-header-arg-names and org-babel-header-arg-names:lang
variables.

Cheers -- Eric

>
>
>
>>
>> Jambunathan K.
>>
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Footnotes: 
[1]  

,----
| org-babel-map-src-blocks is a Lisp macro in `ob.el'.
| 
| (org-babel-map-src-blocks FILE &rest BODY)
| 
| Evaluate BODY forms on each source-block in FILE.
| If FILE is nil evaluate BODY forms on source blocks in current
| buffer.  During evaluation of BODY the following local variables
| are set relative to the currently matched code block.
| 
| full-block ------- string holding the entirety of the code block
| beg-block -------- point at the beginning of the code block
| end-block -------- point at the end of the matched code block
| lang ------------- string holding the language of the code block
| beg-lang --------- point at the beginning of the lang
| end-lang --------- point at the end of the lang
| switches --------- string holding the switches
| beg-switches ----- point at the beginning of the switches
| end-switches ----- point at the end of the switches
| header-args ------ string holding the header-args
| beg-header-args -- point at the beginning of the header-args
| end-header-args -- point at the end of the header-args
| body ------------- string holding the body of the code block
| beg-body --------- point at the beginning of the body
| end-body --------- point at the end of the body
`----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]