Hi, Dan Davison <davi...@stats.ox.ac.uk> writes:
> Jambunathan K <kjambunat...@gmail.com> 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. >> Emacs-orgmode@gnu.org >> 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 `---- _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
