[BABEL] Seemless editing of Babel Blocks

[BABEL] Seemless editing of Babel Blocks

[Jambunathan K]

I am presenting a code snippet that would make editing of babel blocks
quite seemless. The editor parallels (inline!) editing of table
blocks. A suitable variation thereof could be considered for inclusion
in the core distribution.

Few other suggestions:
1. While invoking babel editor, offer babel guard lines as comment
   blocks in the native mode.
   
2. On saving code blocks, do the reverse.
   
For example, in case of emacs-lisp
   
#+begin_src emacs_lisp:
(message "Hello World")
#+end_src

could be offered as:

;; begin_src emacs_lisp:
(message "Hello World")
;; end_src

One could then add say a ':tangle ...' directive and have it persisted
as 

#+begin_src emacs_lisp: :tangle HelloWorld.el
(message "Hello World")
#+end_src

2. Is it possible to do org-edit-src-exit with more 'natural'
   keybinding like C-x C-w or C-x C-s. Furthermore, C-x C-w could fix
   up '#+srcname: ' directive as well.

   
;; CODE SNIPPET   

;; make org-cycle look for babel blocks
((org-at-babel-p)
 (call-interactively 'org-edit-special))

;; A semicolon followed by <TAB> would invoke the babel editor.
;; A tab within the babel block would invoke the babel editor.

(defconst org-babel-invoke-editor-regexp "^[ \t]*\\(;\\)"
  "Detect beginning of babel src code")

(defun org-at-babel-p () 
  ""
  (beginning-of-line 1)

  (cond 
   ((looking-at org-babel-invoke-editor-regexp)
    (unless  (org-babel-where-is-src-block-head)
      (insert  "#+begin_src emacs-lisp :\n\n")
        
      (insert  "#+end_src")
      (kill-line)
      (forward-line  -1)
      t)
    )

   ((org-babel-where-is-src-block-head) t)
   (t nil)
   )
  )

Re: [BABEL] Seemless editing of Babel Blocks

[Eric Schulte]

Hi Jambunathan,

I like the idea of displaying the begin/end_src lines as commented
sections in the org-edit-special code buffer, and then potentially using
them to change the values of the begin/end_src lines in the original
org-mode buffer after exiting the src-edit buffer.  It would be very
cool to be able to edit header arguments while editing source code.  It
may be hard to implement, but could be worth the effort.

I'm afraid I don't see how the code snippet you pasted below could be
applied, could you reformat it as a patch to Org-mode with usage
instructions?

As for different key-bindings for exiting src edit buffers, you could
certainly setup your own in your personal configuration using the
org-src-mode-hook.

Thanks for the neat idea -- Eric

Jambunathan K <kjambunathan@gmail.com> writes:

> I am presenting a code snippet that would make editing of babel blocks
> quite seemless. The editor parallels (inline!) editing of table
> blocks. A suitable variation thereof could be considered for inclusion
> in the core distribution.
>
> Few other suggestions:
> 1. While invoking babel editor, offer babel guard lines as comment
>    blocks in the native mode.
>    
> 2. On saving code blocks, do the reverse.
>    
> For example, in case of emacs-lisp
>    
> #+begin_src emacs_lisp:
> (message "Hello World")
> #+end_src
>
> could be offered as:
>
> ;; begin_src emacs_lisp:
> (message "Hello World")
> ;; end_src
>
> One could then add say a ':tangle ...' directive and have it persisted
> as 
>
> #+begin_src emacs_lisp: :tangle HelloWorld.el
> (message "Hello World")
> #+end_src
>
> 2. Is it possible to do org-edit-src-exit with more 'natural'
>    keybinding like C-x C-w or C-x C-s. Furthermore, C-x C-w could fix
>    up '#+srcname: ' directive as well.
>
>    
> ;; CODE SNIPPET   
>
> ;; make org-cycle look for babel blocks
> ((org-at-babel-p)
>  (call-interactively 'org-edit-special))
>
> ;; A semicolon followed by <TAB> would invoke the babel editor.
> ;; A tab within the babel block would invoke the babel editor.
>
> (defconst org-babel-invoke-editor-regexp "^[ \t]*\\(;\\)"
>   "Detect beginning of babel src code")
>
> (defun org-at-babel-p () 
>   ""
>   (beginning-of-line 1)
>
>   (cond 
>    ((looking-at org-babel-invoke-editor-regexp)
>     (unless  (org-babel-where-is-src-block-head)
>       (insert  "#+begin_src emacs-lisp :\n\n")
>         
>       (insert  "#+end_src")
>       (kill-line)
>       (forward-line  -1)
>       t)
>     )
>
>    ((org-babel-where-is-src-block-head) t)
>    (t nil)
>    )
>   )
>

I have no idea how/where the above could be applied.

>
> _______________________________________________
> 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

Re: [BABEL] Seemless editing of Babel Blocks

[Jambunathan K]

Eric
Apologize for duplicate post. Ccing the mailing list this time.

    Eric> Hi Jambunathan, I like the idea of displaying the
    Eric> begin/end_src lines as commented sections in the
    Eric> org-edit-special code buffer, and then potentially using them
    Eric> to change the values of the begin/end_src lines in the
    Eric> original org-mode buffer after exiting the src-edit buffer.
    Eric> It would be very cool to be able to edit header arguments
    Eric> while editing source code.  It may be hard to implement, but
    Eric> could be worth the effort.


Based on my experimentation, offering of #+begin_src and #+end_src
lines (or for that matter 'surrounding context' - leading and
trailing) is not problematic as such.

What really gets in the way (in the sense of being irksome to implement)
is the preserving and restoring of indentations while moving between the
org and org-src buffers.

I am giving up my efforts on this proposal.

1 Original Proposal 
~~~~~~~~~~~~~~~~~~~~

What is this in org-buffer


  (defun hello () 
    ""
    (message "Hello World")
    )

gets offered as 

;; #+begin_src emacs-lisp
(defun hello () 
  ""
  (message "Hello World")
  )
;; #+end_src

in org-src buffer.

All that babel has to do is to run 'comment-region' and
'uncomment-region' on leading and trailing contexts before moving into
and out-of org-src buffers. 

(un)comment-region makes sure that this could be done in a target
language agnostic way. 

Furthermore, the way emacs fills out comment blocks (while editing
them) would retain the org-like structure of the surrounding context.

Jambunathan K.

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

[Jambunathan K]

1 Preface 
~~~~~~~~~~
  
  Continuing on my earlier note "Offer surrounding context in org-src
  buffers", I have another idea.
  
  The idea is a bit fanciful and questionable. I also have a prototype
  code that is quite gross. (Don't say that I haven't warned)

2 Motivation 
~~~~~~~~~~~~~
  The primary motivation is that I find transitioning from and to an
  org-src buffer a bit of a psychological drag. It would be good if I
  don't leave the current buffer as such and still be able to edit
  babel blocks.

3 Setting the context 
~~~~~~~~~~~~~~~~~~~~~~

  I believe when I am doing literate programming, I am likely to work
  in phases.
  
  Note: I haven't done literate programming in even lighter sense of
  the word. My understanding down below could be naive and may not be
  as nuanced as that of a practitioner.
  

3.1 Phase-1 
============

   Fix up the overall design/structure. Here I am likely to work with
   a text file (orgmode buffer in our case).
   

3.2 Phase-2: 
=============

   Churn out code by filling out top-level blocks identified in
   Phase-1. Here I am likely to work with a code file (org-src buffer
   in our case).

3.3 Phase-3 
============

   Compile, Test and Fix. Here I am likely to switch quite frequently
   between the org and org-src blocks.
   
   I believe good amount of time would be spent in Phase-3.
   
   It is in this phase that offering of 'surrounding context' becomes
   crucial in org-src buffers. (Here is an item to the WISH list)
   

4 Crux of the idea 
~~~~~~~~~~~~~~~~~~~

  Think of an org buffer as a chain of alternating src and non-src
  blocks. 

  org-buffer = [non-src, src]+
  
  More specifically, when there is a mix of say python and emacs-lisp
  blocks and if I have my emacs-lisp goggles on, I could subsume
  python blocks as non-src blocks.

  Offer a command say 'org-to-org-src-view' which when invoked
  switches the org-mode buffer to target language mode and comments
  out all the non-src blocks.

  Offer a reverse command 'org-src-to-org-view' that switches the
  buffer to org-mode and uncomments the non-src blocks. 
  
  This way I never leave the buffer and I don't have to contend
  anymore with pop-ups (and importantly syncing of parent and daughter
  buffers). Yet I have 'all' the contexts available for my viewing and
  editing pleasure.
  
5 Gross code 
~~~~~~~~~~~~~


diff --git a/lisp/ob.el b/lisp/ob.el
index b5b9d8f..613139e 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -662,19 +662,52 @@ portions of results lines."
          (lambda () (org-add-hook 'change-major-mode-hook
                              'org-babel-show-result-all 'append 'local)))
 
-(defmacro org-babel-map-src-blocks (file &rest body)
+
+(defun org-to-org-src-view () 
+  ""
+  (interactive)
+
+  (emacs-lisp-mode)
+  (org-babel-map-src-blocks (buffer-file-name)
+      (
+       (comment-region beg-org end-org)
+       )
+      )
+  )
+
+(defmacro org-babel-map-src-blocks (file body1 &rest body)
   "Evaluate BODY forms on each source-block in FILE."
   (declare (indent 1))
   `(let ((visited-p (get-file-buffer (expand-file-name ,file)))
-        to-be-removed)
+        to-be-removed
+        (beg-org (make-marker))
+        (end-org (make-marker))
+        (beg-babel (make-marker))
+        (end-babel (make-marker))
+        )
+     
      (save-window-excursion
        (find-file ,file)
        (setq to-be-removed (current-buffer))
+
+       (move-marker end-babel (point-min))
        (goto-char (point-min))
+       
        (while (re-search-forward org-babel-src-block-regexp nil t)
-         (goto-char (match-beginning 0))
-         (save-match-data ,@body)
-         (goto-char (match-end 0))))
+
+        (move-marker beg-org end-babel)
+        (move-marker end-org (match-beginning 0))
+        (move-marker beg-babel (match-beginning 0))
+        (move-marker end-babel (match-end 0))
+
+        (goto-char beg-org)
+        ,@body1
+
+        (goto-char beg-babel)
+         ,@body
+        
+
+         (goto-char end-babel)))
      (unless visited-p
        (kill-buffer to-be-removed))))

6 Illustration 
~~~~~~~~~~~~~~~

  For the sake of illustration, consider an org-mode buffer like this.
  
  
* Heading0
** Heading00
   Print Heading00.
   
#+begin_src emacs-lisp
   (message "Heading00")
#+end_src   
   
** Heading01
   
   Print Heading01.
   #+begin_src emacs-lisp
     (message "Heading01")
   #+end_src   
  
  org-to-org-src-view on this buffer puts it in emacs-lisp mode with
  the following content.
  
;; * Heading0
;; ** Heading00
;;    Print Heading00.
   
#+begin_src emacs-lisp
   (message "Heading00")
#+end_src   
   
;; ** Heading01
   
;;    Print Heading01.
   #+begin_src emacs-lisp
     (message "Heading01")
   #+end_src   
     
  For the sake of brevity, I have left out the commenting of
  meta-lines in the prototype code.
  
Thanks for your consideration,
Jambunathan K.

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

[Dan Davison]

Hi Jambunathan,

>   The primary motivation is that I find transitioning from and to an
>   org-src buffer a bit of a psychological drag. It would be good if I
>   don't leave the current buffer as such and still be able to edit
>   babel blocks.
[...]
> 4 Crux of the idea 
> ~~~~~~~~~~~~~~~~~~~
[...]
>   Offer a command say 'org-to-org-src-view' which when invoked
>   switches the org-mode buffer to target language mode and comments
>   out all the non-src blocks.
> 
>   Offer a reverse command 'org-src-to-org-view' that switches the
>   buffer to org-mode and uncomments the non-src blocks. 

My vote is that this proposal is too drastic.


>   This way I never leave the buffer and I don't have to contend
>   anymore with pop-ups
> 

Have you investigated the different settings of the
`org-src-window-setup' variable?

> (and importantly syncing of parent and daughter
>   buffers).

Could you expand on that a little bit? What syncing problems are you
having?

> Yet I have 'all' the contexts available for my viewing and
>   editing pleasure.


There have been some recent changes with the aim of making code blocks
more pleasant to use in Org, such as fontification and making TAB and
other major-mode commands available in the Org buffer (with a current
master branch, see the variable `org-src-tab-acts-natively' and
`org-babel-do-key-sequence-in-edit-buffer' which is bound to key
bindings C-c C-v x and C-c C-v C-x)

If you really want to use language major mode commands without leaving
the Org buffer, I suggest investigating Lennart Borgman's nxhtml
package[1]. This features a function `org-mumamo-mode' which
automatically switches Org code blocks into native major modes. I have
encountered one bug whch makes R code blocks hard to use, but the author
is responding to them at the bug tracker[2], so I think we should help
out by reporting any bugs there. Here's my config for nxhtml/mumamo (the
third line is just personal taste):

--8<---------------cut here---------------start------------->8---
(load "/usr/local/src/emacs/nxhtml/autostart.el")
(require 'mumamo)
(add-hook 'org-mumamo-mode-hook (lambda () (mumamo-no-chunk-coloring +1)))
--8<---------------cut here---------------end--------------->8---


Dan

Footnotes:

[1] http://www.emacswiki.org/emacs/NxhtmlMode

[2] https://bugs.launchpad.net/nxhtml


> 5 Gross code 
> ~~~~~~~~~~~~~
>
>
> diff --git a/lisp/ob.el b/lisp/ob.el
> index b5b9d8f..613139e 100644
> --- a/lisp/ob.el
> +++ b/lisp/ob.el
> @@ -662,19 +662,52 @@ portions of results lines."
>           (lambda () (org-add-hook 'change-major-mode-hook
>                               'org-babel-show-result-all 'append 'local)))
>  
> -(defmacro org-babel-map-src-blocks (file &rest body)
> +
> +(defun org-to-org-src-view () 
> +  ""
> +  (interactive)
> +
> +  (emacs-lisp-mode)
> +  (org-babel-map-src-blocks (buffer-file-name)
> +      (
> +       (comment-region beg-org end-org)
> +       )
> +      )
> +  )
> +
> +(defmacro org-babel-map-src-blocks (file body1 &rest body)
>    "Evaluate BODY forms on each source-block in FILE."
>    (declare (indent 1))
>    `(let ((visited-p (get-file-buffer (expand-file-name ,file)))
> -        to-be-removed)
> +        to-be-removed
> +        (beg-org (make-marker))
> +        (end-org (make-marker))
> +        (beg-babel (make-marker))
> +        (end-babel (make-marker))
> +        )
> +     
>       (save-window-excursion
>         (find-file ,file)
>         (setq to-be-removed (current-buffer))
> +
> +       (move-marker end-babel (point-min))
>         (goto-char (point-min))
> +       
>         (while (re-search-forward org-babel-src-block-regexp nil t)
> -         (goto-char (match-beginning 0))
> -         (save-match-data ,@body)
> -         (goto-char (match-end 0))))
> +
> +        (move-marker beg-org end-babel)
> +        (move-marker end-org (match-beginning 0))
> +        (move-marker beg-babel (match-beginning 0))
> +        (move-marker end-babel (match-end 0))
> +
> +        (goto-char beg-org)
> +        ,@body1
> +
> +        (goto-char beg-babel)
> +         ,@body
> +        
> +
> +         (goto-char end-babel)))
>       (unless visited-p
>         (kill-buffer to-be-removed))))
>
> 6 Illustration 
> ~~~~~~~~~~~~~~~
>
>   For the sake of illustration, consider an org-mode buffer like this.
>   
>   
> * Heading0
> ** Heading00
>    Print Heading00.
>    
> #+begin_src emacs-lisp
>    (message "Heading00")
> #+end_src   
>    
> ** Heading01
>    
>    Print Heading01.
>    #+begin_src emacs-lisp
>      (message "Heading01")
>    #+end_src   
>   
>   org-to-org-src-view on this buffer puts it in emacs-lisp mode with
>   the following content.
>   
> ;; * Heading0
> ;; ** Heading00
> ;;    Print Heading00.
>    
> #+begin_src emacs-lisp
>    (message "Heading00")
> #+end_src   
>    
> ;; ** Heading01
>    
> ;;    Print Heading01.
>    #+begin_src emacs-lisp
>      (message "Heading01")
>    #+end_src   
>      
>   For the sake of brevity, I have left out the commenting of
>   meta-lines in the prototype code.
>   
> Thanks for your consideration,
> 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

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

[Erik Iverson]

>
> If you really want to use language major mode commands without leaving
> the Org buffer, I suggest investigating Lennart Borgman's nxhtml
> package[1]. This features a function `org-mumamo-mode' which
> automatically switches Org code blocks into native major modes. I have
> encountered one bug whch makes R code blocks hard to use, but the author
> is responding to them at the bug tracker[2],

I too found nxhtml locking up when using R.  It that gets fixed, it
could be a nice package to use with org-mode when editing source code.

However, I think with the improvements just committed today that you
mention, that source code editing got a whole lot better without
switching to the indirect buffer using C-c '.

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

[Tom Short]

On Thu, Sep 2, 2010 at 7:41 PM, Dan Davison <davison@stats.ox.ac.uk> wrote:
> There have been some recent changes with the aim of making code blocks
> more pleasant to use in Org, such as fontification and making TAB and
> other major-mode commands available in the Org buffer (with a current
> master branch, see the variable `org-src-tab-acts-natively' and
> `org-babel-do-key-sequence-in-edit-buffer' which is bound to key
> bindings C-c C-v x and C-c C-v C-x)

I really like the fontification and the tab-acts-natively. Would it be
hard to extend
that to a few more keys? Here's a first try for a nice key to have in
R source blocks
("_"):

(add-hook 'org-mode-hook
   (lambda ()
     (define-key org-mode-map "_"
       '(lambda () (interactive)
          (org-babel-do-key-sequence-in-edit-buffer (kbd "_")))))

That works in R (and other) blocks, but doesn't work outside that. Any hints to
get me a little further?

- Tom

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

[Dan Davison]

Tom Short <tshort.epri@gmail.com> writes:

> On Thu, Sep 2, 2010 at 7:41 PM, Dan Davison <davison@stats.ox.ac.uk> wrote:
>> There have been some recent changes with the aim of making code blocks
>> more pleasant to use in Org, such as fontification and making TAB and
>> other major-mode commands available in the Org buffer (with a current
>> master branch, see the variable `org-src-tab-acts-natively' and
>> `org-babel-do-key-sequence-in-edit-buffer' which is bound to key
>> bindings C-c C-v x and C-c C-v C-x)
>
> I really like the fontification and the tab-acts-natively. Would it be
> hard to extend
> that to a few more keys? Here's a first try for a nice key to have in
> R source blocks
> ("_"):
>
> (add-hook 'org-mode-hook
>    (lambda ()
>      (define-key org-mode-map "_"
>        '(lambda () (interactive)
>           (org-babel-do-key-sequence-in-edit-buffer (kbd "_")))))
>
> That works in R (and other) blocks, but doesn't work outside that. Any hints to
> get me a little further?

Hey Tom,

Good idea. I'll definitely use
that. `org-babel-do-key-sequence-in-edit-buffer' returns nil only if it
is not in a code block[1], so we could use this in
your code above:

    (or (org-babel-do-key-sequence-in-edit-buffer (kbd "_"))
        (org-self-insert-command 1))

Dan


>
> - Tom
>
> _______________________________________________
> 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] To be more exact, it returns nil if org-edit-src-code doesn't
generate an edit buffer.

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

[Jambunathan K]

    >> Offer a command say 'org-to-org-src-view' which when invoked
    >> switches the org-mode buffer to target language mode and comments
    >> out all the non-src blocks.
    >> 
    >> Offer a reverse command 'org-src-to-org-view' that switches the
    >> buffer to org-mode and uncomments the non-src blocks.

    Dan> My vote is that this proposal is too drastic.

What I am proposing is tangling albeit in a loose sense of the word.

Would it sound as drastic if one were to divorce the consideration of
how often this operation gets performed - one time only or very often -
during the lifetime of the org file.

How about providing user-accessible tapping points within
'org-babel-map-src-blocks' (or a variation thereof) that would enable me
have a custom command in my .emacs.

For the sake of record, my suggestion is very closely related to what is
discussed here.

http://eschulte.github.com/babel-dev/PROPOSED-tangle-entire-org-mode-file-in-comments.html

Thanks,
Jambunathan K.

> 5 Gross code 
> ~~~~~~~~~~~~~
>
>
> diff --git a/lisp/ob.el b/lisp/ob.el
> index b5b9d8f..613139e 100644
> --- a/lisp/ob.el
> +++ b/lisp/ob.el
> @@ -662,19 +662,52 @@ portions of results lines."
>           (lambda () (org-add-hook 'change-major-mode-hook
>                               'org-babel-show-result-all 'append 'local)))
>  
> -(defmacro org-babel-map-src-blocks (file &rest body)
> +
> +(defun org-to-org-src-view () 
> +  ""
> +  (interactive)
> +
> +  (emacs-lisp-mode)
> +  (org-babel-map-src-blocks (buffer-file-name)
> +      (
> +       (comment-region beg-org end-org)
> +       )
> +      )
> +  )
> +
> +(defmacro org-babel-map-src-blocks (file body1 &rest body)
>    "Evaluate BODY forms on each source-block in FILE."
>    (declare (indent 1))
>    `(let ((visited-p (get-file-buffer (expand-file-name ,file)))
> -        to-be-removed)
> +        to-be-removed
> +        (beg-org (make-marker))
> +        (end-org (make-marker))
> +        (beg-babel (make-marker))
> +        (end-babel (make-marker))
> +        )
> +     
>       (save-window-excursion
>         (find-file ,file)
>         (setq to-be-removed (current-buffer))
> +
> +       (move-marker end-babel (point-min))
>         (goto-char (point-min))
> +       
>         (while (re-search-forward org-babel-src-block-regexp nil t)
> -         (goto-char (match-beginning 0))
> -         (save-match-data ,@body)
> -         (goto-char (match-end 0))))
> +
> +        (move-marker beg-org end-babel)
> +        (move-marker end-org (match-beginning 0))
> +        (move-marker beg-babel (match-beginning 0))
> +        (move-marker end-babel (match-end 0))
> +
> +        (goto-char beg-org)
> +        ,@body1
> +
> +        (goto-char beg-babel)
> +         ,@body
> +        
> +
> +         (goto-char end-babel)))
>       (unless visited-p
>         (kill-buffer to-be-removed))))

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

[Eric Schulte]

Hi Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

>     >> Offer a command say 'org-to-org-src-view' which when invoked
>     >> switches the org-mode buffer to target language mode and comments
>     >> out all the non-src blocks.
>     >> 
>     >> Offer a reverse command 'org-src-to-org-view' that switches the
>     >> buffer to org-mode and uncomments the non-src blocks.
>
>     Dan> My vote is that this proposal is too drastic.
>
> What I am proposing is tangling albeit in a loose sense of the word.
>
> Would it sound as drastic if one were to divorce the consideration of
> how often this operation gets performed - one time only or very often -
> during the lifetime of the org file.
>
> How about providing user-accessible tapping points within
> 'org-babel-map-src-blocks' (or a variation thereof) that would enable me
> have a custom command in my .emacs.
>
> For the sake of record, my suggestion is very closely related to what is
> discussed here.
>
> http://eschulte.github.com/babel-dev/PROPOSED-tangle-entire-org-mode-file-in-comments.html
>

I've just pushed up an implementation of the functionality described at
the link above, see [1] for examples and details.

Is this sufficient to satisfy the need you were addressing?  If not how
could it be improved?

Thanks -- Eric

>
> Thanks,
> Jambunathan K.
>

Footnotes: 
[1]  http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html

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

[Jambunathan K]

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


Eric

>
> I've just pushed up an implementation of the functionality described at
> the link above, see [1] for examples and details.
>

> Footnotes: 
> [1]  http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>

I have pulled your changes and examined it. Some commets:

Comment #1: Org Manual

> Org Manual - Section 14.8.2.7 comments

> org - Include text from the original org-mode file which preceded the
> code block as a comment which precedes the tangled code.

I suggest the following wording - 

"Include text from the org-mode file as a comment. 

 The text is picked from the leading context of the tangled code and is
 limited by the nearest headline or source block as the case may be."

Comment #2: Perceived gaps

In my original case,

1. Tangling happens in-place.

   The source and target buffers are one and the same only their major
   made changes. i.e., it is destructive. Think of 'replace-region' ...

2. There is no lossage.

   I can tangle to elisp-mode and untangle it to org-mode without any
   round-trip losses.

   With your changes, the following are lost - the 'trailing' text and
   the 'stars' in the headline.


That said, I have upgraded my request to a generic API (see attachment)
and I am not too particular about my original use-case (which I agree as
'contrived', 'drastic' and 'one-off')

Jambunathan K.

Attachments: This for the benefit of the list. 

I had accidentally unicast the reply. My recent transition to gnus has
made me very clumsy.


[-- Attachment #2: Type: text/plain, Size: 3056 bytes --]

From: Jambunathan K <kjambunathan@gmail.com>
To: "Eric Schulte" <schulte.eric@gmail.com>
Subject: Re: [BABEL] [PROPOSAL] Seemless editing of Babel Blocks
References: <4C459236.3@gmail.com> <87k4opu5fk.fsf@gmail.com>
	<81hbivx88y.fsf@gmail.com> <8139ueykvc.fsf_-_@gmail.com>
	<878w3j1zos.fsf@stats.ox.ac.uk> <81k4n13mww.fsf@gmail.com>
	<87r5h9czxf.fsf@gmail.com>
X-Draft-From: ("nntp+news.gmane.org:gmane.emacs.orgmode" 29790)
Date: Sun, 05 Sep 2010 14:28:16 +0530
In-Reply-To: <87r5h9czxf.fsf@gmail.com> (Eric Schulte's message of "Sat, 04
	Sep 2010 09:04:03 -0600")
Message-ID: <81d3ssva6v.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (windows-nt)
--text follows this line--

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.
c) body, body1 => Hooks for user

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?

Jambunathan K.




[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Dan Davison]

Jambunathan K <kjambunathan@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.
> c) body, body1 => Hooks for user

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



>
> 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

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

[Eric Schulte]

Hi,

Dan Davison <davison@stats.ox.ac.uk> writes:

> Jambunathan K <kjambunathan@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
`----

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

[Eric Schulte]

Hi Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> Eric
>
>>
>> I've just pushed up an implementation of the functionality described at
>> the link above, see [1] for examples and details.
>>
>
>> Footnotes: 
>> [1]  http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>>
>
> I have pulled your changes and examined it. Some commets:
>
> Comment #1: Org Manual
>
>> Org Manual - Section 14.8.2.7 comments
>
>> org - Include text from the original org-mode file which preceded the
>> code block as a comment which precedes the tangled code.
>
> I suggest the following wording - 
>
> "Include text from the org-mode file as a comment. 
>
>  The text is picked from the leading context of the tangled code and is
>  limited by the nearest headline or source block as the case may be."
>

Thanks, I've made this change in the manual.

>
> Comment #2: Perceived gaps
>
> In my original case,
>
> 1. Tangling happens in-place.
>
>    The source and target buffers are one and the same only their major
>    made changes. i.e., it is destructive. Think of 'replace-region' ...
>
> 2. There is no lossage.
>
>    I can tangle to elisp-mode and untangle it to org-mode without any
>    round-trip losses.
>
>    With your changes, the following are lost - the 'trailing' text and
>    the 'stars' in the headline.
>
>
> That said, I have upgraded my request to a generic API (see attachment)
> and I am not too particular about my original use-case (which I agree as
> 'contrived', 'drastic' and 'one-off')
>

Great.  I've acted on your API request so hopefully that will supersede
the need for more drastic tangling extensions.

Thanks -- Eric

>
> Jambunathan K.
>
> Attachments: This for the benefit of the list. 
>
> I had accidentally unicast the reply. My recent transition to gnus has
> made me very clumsy.
>
> From: Jambunathan K <kjambunathan@gmail.com>
> To: "Eric Schulte" <schulte.eric@gmail.com>
> Subject: Re: [BABEL] [PROPOSAL] Seemless editing of Babel Blocks
> References: <4C459236.3@gmail.com> <87k4opu5fk.fsf@gmail.com>
> 	<81hbivx88y.fsf@gmail.com> <8139ueykvc.fsf_-_@gmail.com>
> 	<878w3j1zos.fsf@stats.ox.ac.uk> <81k4n13mww.fsf@gmail.com>
> 	<87r5h9czxf.fsf@gmail.com>
> X-Draft-From: ("nntp+news.gmane.org:gmane.emacs.orgmode" 29790)
> Date: Sun, 05 Sep 2010 14:28:16 +0530
> In-Reply-To: <87r5h9czxf.fsf@gmail.com> (Eric Schulte's message of "Sat, 04
> 	Sep 2010 09:04:03 -0600")
> Message-ID: <81d3ssva6v.fsf@gmail.com>
> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (windows-nt)
> --text follows this line--
>
> 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.
> c) body, body1 => Hooks for user
>
> 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?
>
> Jambunathan K.