About org-babel menu

About org-babel menu

[FengShu]

Hi:
Could we add  some org-babel menu items ,so using 
them we can enable and disable the computer languages ?

for example:
#+begin_example
org => org-babel =>  * emacs-lisp
                       sh
                     * R
                       ...
                     * screen

#+end_example

Re: About org-babel menu

[Eric Schulte]

Hi FengShu,

I don't know much about the Emacs customization interface, but it is
certainly the solution to this issue.  There does currently exist a
Babel specific customization group, the nesting is org>babel.  Through
this interface there are menus like the one you mention below available.

One way to access these menus is through the help interface, with
M-x describe-variable RET org-babel-load-languages RET and then select
the "customize" link.

Best,

FengShu <tumashu@gmail.com> writes:

> Hi:
> Could we add  some org-babel menu items ,so using 
> them we can enable and disable the computer languages ?
>
> for example:
> #+begin_example
> org => org-babel =>  * emacs-lisp
>                        sh
>                      * R
>                        ...
>                      * screen
>
> #+end_example

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About org-babel menu

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/03/12 15:22, Eric Schulte wrote:
> Hi FengShu,
> 
> I don't know much about the Emacs customization interface, but it is certainly the solution to
> this issue.  There does currently exist a Babel specific customization group, the nesting is
> org>babel.  Through this interface there are menus like the one you mention below available.
> 
> One way to access these menus is through the help interface, with M-x describe-variable RET
> org-babel-load-languages RET and then select the "customize" link.

Agreed on this point, but I am with FengShu regarding a babel menu. I likely would not use it that
often (I know the shortcuts relevant to me right now), but

1) it would advertise the babel functionality a little bit more if it is shown in the org menu

2) for a beginner, it would be much easier to use org-babel if commands like execute source block
or section, tangle, un-tangle, ... would be in the menu.


So I would see it as a useful way of promoting babel (and therefore org-mode) and also as a nice
reminder of less frequently (but nevertheless usefull) functionality.

Cheers,

Rainer


> 
> Best,
> 
> FengShu <tumashu@gmail.com> writes:
> 
>> Hi: Could we add  some org-babel menu items ,so using them we can enable and disable the
>> computer languages ?
>> 
>> for example: #+begin_example org => org-babel =>  * emacs-lisp sh * R ... * screen
>> 
>> #+end_example
> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9nRY0ACgkQoYgNqgF2egqR+QCfd9JUHONesOzWv/GeVL1sdgAl
J8UAn29QzxY9qxK9Du3n0brq7Orwo6yB
=5vux
-----END PGP SIGNATURE-----

Re: About org-babel menu

[Eric Schulte]

Rainer M Krug <r.m.krug@gmail.com> writes:

> On 19/03/12 15:22, Eric Schulte wrote:
>> Hi FengShu,
>> 
>> I don't know much about the Emacs customization interface, but it is certainly the solution to
>> this issue.  There does currently exist a Babel specific customization group, the nesting is
>> org>babel.  Through this interface there are menus like the one you mention below available.
>> 
>> One way to access these menus is through the help interface, with M-x describe-variable RET
>> org-babel-load-languages RET and then select the "customize" link.
>
> Agreed on this point, but I am with FengShu regarding a babel menu. I likely would not use it that
> often (I know the shortcuts relevant to me right now), but
>
> 1) it would advertise the babel functionality a little bit more if it is shown in the org menu
>
> 2) for a beginner, it would be much easier to use org-babel if commands like execute source block
> or section, tangle, un-tangle, ... would be in the menu.
>
>
> So I would see it as a useful way of promoting babel (and therefore org-mode) and also as a nice
> reminder of less frequently (but nevertheless usefull) functionality.
>

I've had (setq menu-bar-mode nil) in my .emacs for years now and forget
that Emacs even has support for menus.  I don't know anything about how
Emacs implements menus, but if anyone is interested in taking on this
development I'm very happy to consult in the development of and to apply
contributed patches which add Babel menu support.

Best,

>
> Cheers,
>
> Rainer
>
>
>> 
>> Best,
>> 
>> FengShu <tumashu@gmail.com> writes:
>> 
>>> Hi: Could we add  some org-babel menu items ,so using them we can enable and disable the
>>> computer languages ?
>>> 
>>> for example: #+begin_example org => org-babel =>  * emacs-lisp sh * R ... * screen
>>> 
>>> #+end_example
>> 

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About org-babel menu

[Torsten Wagner]

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

My menus are hidden too. However,  if I need them for some reasons there is
some key mouse combo.
Can't remember exactly. Shift right click or C- right click.. something
along this.  The menu will pop up as a context menu close to the mouse
cursor  location. Be aware there is a customization menu too.

Just in case you look for a quick way to use the menu.

Torsten
On Mar 19, 2012 11:53 PM, "Eric Schulte" <eric.schulte@gmx.com> wrote:

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
> > On 19/03/12 15:22, Eric Schulte wrote:
> >> Hi FengShu,
> >>
> >> I don't know much about the Emacs customization interface, but it is
> certainly the solution to
> >> this issue.  There does currently exist a Babel specific customization
> group, the nesting is
> >> org>babel.  Through this interface there are menus like the one you
> mention below available.
> >>
> >> One way to access these menus is through the help interface, with M-x
> describe-variable RET
> >> org-babel-load-languages RET and then select the "customize" link.
> >
> > Agreed on this point, but I am with FengShu regarding a babel menu. I
> likely would not use it that
> > often (I know the shortcuts relevant to me right now), but
> >
> > 1) it would advertise the babel functionality a little bit more if it is
> shown in the org menu
> >
> > 2) for a beginner, it would be much easier to use org-babel if commands
> like execute source block
> > or section, tangle, un-tangle, ... would be in the menu.
> >
> >
> > So I would see it as a useful way of promoting babel (and therefore
> org-mode) and also as a nice
> > reminder of less frequently (but nevertheless usefull) functionality.
> >
>
> I've had (setq menu-bar-mode nil) in my .emacs for years now and forget
> that Emacs even has support for menus.  I don't know anything about how
> Emacs implements menus, but if anyone is interested in taking on this
> development I'm very happy to consult in the development of and to apply
> contributed patches which add Babel menu support.
>
> Best,
>
> >
> > Cheers,
> >
> > Rainer
> >
> >
> >>
> >> Best,
> >>
> >> FengShu <tumashu@gmail.com> writes:
> >>
> >>> Hi: Could we add  some org-babel menu items ,so using them we can
> enable and disable the
> >>> computer languages ?
> >>>
> >>> for example: #+begin_example org => org-babel =>  * emacs-lisp sh * R
> ... * screen
> >>>
> >>> #+end_example
> >>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
>

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

Re: About org-babel menu

[Nick Dokos]

Torsten Wagner <torsten.wagner@gmail.com> wrote:

> My menus are hidden too. However,  if I need them for some reasons
> there is some key mouse combo.  Can't remember exactly. Shift right
> click or C- right click.. something along this.  The menu will pop up
> as a context menu close to the mouse cursor  location. Be aware there
> is a customization menu too.
> 
> Just in case you look for a quick way to use the menu.
> 

Thanks for the useful hint.

One possible gotcha: in my case, C-<mouse3> is undefined, even though
the docs say it should be. I tried emacs -q and emacs -Q as well, just
in case, my init somehow clobbers it: undefined there as well.  So I
have to bind it somehow:

   (global-set-key [C-mouse-3] 'mouse-popup-menubar-stuff)

does not seem to work for me, but

   (global-set-key [mouse-3] 'mouse-popup-menubar-stuff)

does.

GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-01-24

That's good enough I guess but I was wondering if anybody else has these
problems.

Nick

Re: About org-babel menu

[Bernt Hansen]

Nick Dokos <nicholas.dokos@hp.com> writes:

> One possible gotcha: in my case, C-<mouse3> is undefined, even though
> the docs say it should be. I tried emacs -q and emacs -Q as well, just
> in case, my init somehow clobbers it: undefined there as well.  So I
> have to bind it somehow:
>
>    (global-set-key [C-mouse-3] 'mouse-popup-menubar-stuff)
>
> does not seem to work for me, but
>
>    (global-set-key [mouse-3] 'mouse-popup-menubar-stuff)
>
> does.
>
> GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-01-24
>
> That's good enough I guess but I was wondering if anybody else has these
> problems.

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11
on raven, modified by Debian

[C-mouse-3] works for me and I've never customized it to my knowledge.
I also have the menus turned off.  Maybe it's an emacs 24 thing?

Regards,
Bernt

Re: About org-babel menu

[Nick Dokos]

Bernt Hansen <bernt@norang.ca> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > One possible gotcha: in my case, C-<mouse3> is undefined, even though
> > the docs say it should be. I tried emacs -q and emacs -Q as well, just
> > in case, my init somehow clobbers it: undefined there as well.  So I
> > have to bind it somehow:
> >
> >    (global-set-key [C-mouse-3] 'mouse-popup-menubar-stuff)
> >
> > does not seem to work for me, but
> >
> >    (global-set-key [mouse-3] 'mouse-popup-menubar-stuff)
> >
> > does.
> >
> > GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-01-24
> >
> > That's good enough I guess but I was wondering if anybody else has these
> > problems.
> 
> GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11
> on raven, modified by Debian
> 
> [C-mouse-3] works for me and I've never customized it to my knowledge.
> I also have the menus turned off.  Maybe it's an emacs 24 thing?
> 

It might very well be. Thanks for checking!

Nick

Re: About org-babel menu

[Bastien]

Hi Thorsten,

I'm interested in having a menu for Babel.

What I need is (1) the list of functions and contexts in which this menu
should appear and (2) the list of items for such a menu.  When we have
this, we can think of context-aware mouse-menu deeper, adapted to what
is already available in the global menu.

If someone wants to put a stab at (1) and (2), let's go !  Would be a
nice addition for Org 7.9.

Thanks,

-- 
 Bastien

Re: About org-babel menu

[Yagnesh Raghava Yakkala]

Bastien <bzg@gnu.org> writes:

> Hi Thorsten,
>
> I'm interested in having a menu for Babel.
>
> What I need is (1) the list of functions and contexts in which this menu
> should appear and (2) the list of items for such a menu.  When we have
> this, we can think of context-aware mouse-menu deeper, adapted to what
> is already available in the global menu.
>
> If someone wants to put a stab at (1) and (2), let's go !  Would be a
> nice addition for Org 7.9.

I will try and report back soon.

IMO babel can have its own main menu just like OrgTbl. (with a name "ob" or
something).

PS: Even I don't use menus. Just thinking of learning more about org babel

-- 
YYR

Re: About org-babel menu

[Jonathan Leech-Pepin]

On Mon, Mar 19, 2012 at 10:41, Rainer M Krug <r.m.krug@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 19/03/12 15:22, Eric Schulte wrote:
>> Hi FengShu,
>>
>> I don't know much about the Emacs customization interface, but it is certainly the solution to
>> this issue.  There does currently exist a Babel specific customization group, the nesting is
>> org>babel.  Through this interface there are menus like the one you mention below available.
>>
>> One way to access these menus is through the help interface, with M-x describe-variable RET
>> org-babel-load-languages RET and then select the "customize" link.
>
> Agreed on this point, but I am with FengShu regarding a babel menu. I likely would not use it that
> often (I know the shortcuts relevant to me right now), but
>
> 1) it would advertise the babel functionality a little bit more if it is shown in the org menu
>
> 2) for a beginner, it would be much easier to use org-babel if commands like execute source block
> or section, tangle, un-tangle, ... would be in the menu.
>

That would be useful, however I believe what FengShu means is a
sub-menu specifically with a list of all the org-babel languages,
where you can see which are active at the moment.  I'm not sure how
you could deactivate them once they are active however since the
libraries would be loaded, however you could use that menu as a way to
keep track of which languages require confirmation on code blocks and
which will be evaluated without prompting.

>
> So I would see it as a useful way of promoting babel (and therefore org-mode) and also as a nice
> reminder of less frequently (but nevertheless usefull) functionality.
>
> Cheers,
>
> Rainer
>
>
>>
>> Best,
>>
>> FengShu <tumashu@gmail.com> writes:
>>
>>> Hi: Could we add  some org-babel menu items ,so using them we can enable and disable the
>>> computer languages ?
>>>
>>> for example: #+begin_example org => org-babel =>  * emacs-lisp sh * R ... * screen
>>>
>>> #+end_example
>>
>
>
> - --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
> (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :       +33 - (0)9 53 10 27 44
> Cell:       +33 - (0)6 85 62 59 98
> Fax :       +33 - (0)9 58 10 27 44
>
> Fax (D):    +49 - (0)3 21 21 25 22 44
>
> email:      Rainer@krugs.de
>
> Skype:      RMkrug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9nRY0ACgkQoYgNqgF2egqR+QCfd9JUHONesOzWv/GeVL1sdgAl
> J8UAn29QzxY9qxK9Du3n0brq7Orwo6yB
> =5vux
> -----END PGP SIGNATURE-----
>

Re: About org-babel menu

[Bastien]

Hi Rainer,

Rainer M Krug <r.m.krug@gmail.com> writes:

> So I would see it as a useful way of promoting babel (and therefore
> org-mode) and also as a nice reminder of less frequently (but
> nevertheless usefull) functionality.

Agreed.  

Is anyone volunteering for listing the items in such a menu for Babel?

If so, I'm willing to implement this.  

I'm not convince we should have a menu item to (de)activate each
language though -- more a menu that exposes the basics.

Thanks,

-- 
 Bastien

layout org-babel menu WAS: About org-babel menu

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/03/12 01:07, Bastien wrote:
> Hi Rainer,
> 
> Rainer M Krug <r.m.krug@gmail.com> writes:
> 
>> So I would see it as a useful way of promoting babel (and therefore org-mode) and also as a
>> nice reminder of less frequently (but nevertheless usefull) functionality.
> 
> Agreed.
> 
> Is anyone volunteering for listing the items in such a menu for Babel?
> 
> If so, I'm willing to implement this.
OK - let me start this.

Org
|
+ Babel
  |
  + edit
  |  |
  |  + open surce buffer (that C-c ')
  |  + insert source block skeleton
  |  + ...
  |  + ...
  |
  + tangle
  |  |
  |  + tangle buffer
  |  + inverse tangle
  |  + ...
  |  + ...
  |
  + evaluate
  |  |
  |  + evaluate code block
  |  + evaluate subtree
  |  + ...
  |  + ...
  |  + ...
  |  + ...
  |
  + help
  |  |
  |  + Link to info help on header arguments
  |  + Link to info help on how to enable languages
  |  + URL to language specific help on worg
  |  + ...
  |  + ...


So - At the moment this is a skeleton of the babel menu - Comments? forgotten commands (I assume
many?

> 
> I'm not convince we should have a menu item to (de)activate each language though -- more a menu
> that exposes the basics.

Agreed.

Cheers,

Rainer




> 
> Thanks,
> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk99YSUACgkQoYgNqgF2egrBXACfYvFStHF+7qpcmT9PZ0JLhMFl
LToAn3fxPxT4PP1G0Qno3ufsNwAQ9C4x
=0Nuk
-----END PGP SIGNATURE-----

Re: layout org-babel menu WAS: About org-babel menu

[Eric Schulte]

Rainer M Krug <r.m.krug@gmail.com> writes:

> On 28/03/12 01:07, Bastien wrote:
>> Hi Rainer,
>> 
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>> 
>>> So I would see it as a useful way of promoting babel (and therefore org-mode) and also as a
>>> nice reminder of less frequently (but nevertheless usefull) functionality.
>> 
>> Agreed.
>> 
>> Is anyone volunteering for listing the items in such a menu for Babel?
>> 
>> If so, I'm willing to implement this.
> OK - let me start this.
>
> Org
> |
> + Babel
>   |
>   + edit
>   |  |
>   |  + open surce buffer (that C-c ')
>   |  + insert source block skeleton
>   |  + ...
>   |  + ...
>   |
>   + tangle
>   |  |
>   |  + tangle buffer
>   |  + inverse tangle
>   |  + ...
>   |  + ...
>   |
>   + evaluate
>   |  |
>   |  + evaluate code block
>   |  + evaluate subtree
>   |  + ...
>   |  + ...
>   |  + ...
>   |  + ...
>   |
>   + help
>   |  |
>   |  + Link to info help on header arguments
>   |  + Link to info help on how to enable languages
>   |  + URL to language specific help on worg
>   |  + ...
>   |  + ...
>
>
> So - At the moment this is a skeleton of the babel menu - Comments? forgotten commands (I assume
> many?
>

Hi Rainer,

Thanks for starting this.  It looks like a great skeleton.  Here are a
couple of comments which I hope are helpful.

To find more publicly available Babel function you can do C-c C-v h in
an Org-mode buffer or run the org-babel-describe-bindings command

There are two high level sub-menus which I may suggest be added to the
above, namely "languages" and "library of babel", which could list
information on available languages and list library of babel functions
respectively.

I'm not sure how menus are normally used, specifically how Emacs breaks
functionality between the menu, configuration and help sub-systems.  It
is possible that because of such boundaries both the "help" and
"languages" submenus may not be appropriate.

Two other pieces of menu content which occur to me are a list of the
code blocks available in the current buffer including some information
on each block (e.g., name, arguments,), and a way to show the user what
the current file wide header arguments are -- note: there already exists
a function for displaying this information on the code block level
`org-babel-view-source-block-info' which may be sufficient.

Cheers,

>
>> 
>> I'm not convince we should have a menu item to (de)activate each language though -- more a menu
>> that exposes the basics.
>
> Agreed.
>
> Cheers,
>
> Rainer
>
>
>
>
>> 
>> Thanks,
>> 

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: layout org-babel menu WAS: About org-babel menu

[Torsten Wagner]

Hi,

for me the biggest "trouble" with babel is to remember the possible
keywords in the header for different languages.
There were a lot of ongoing syntax change which did not make it easier
for me to remember all this.
Thus a menu which is organised by languages offering all possible
settings for each language would be very helpful.
|
Python
|    |
|  export - code - result - both - none
|    |
|  tangle - no - yes- filename
|   |
|  result - value - output
|  |
| ...
|
...

Not sure how effectual this would be in a main menu. It would be
definitely awesome in a context menu

That would be (copied from worg) [*] indicates cursor position

#+NAME: factorial
#+BEGIN_SRC haskell [*] :results silent :exports code :var n=0

a context menu would appear presenting all possible header arguments for haskell

#+NAME: factorial
#+BEGIN_SRC haskell :results [*] :exports code :var n=0

a context menu presenting all possible values for the header argument
:results in haskell
I guess that together with the possibility to call this menu by
keyboard strokes or alternatively show the same infos in the
minibuffer would be a great win for babel and it would make many
questions here on the list unnecessary.
Furthermore, any change or extension in the syntax for a certain
language would be directly reflected to the end-user. E.g., If I
suddenly see the menu entry :exports 3dprint, I would be curious and
check it out on worg and the manual ;)

Totti



On 5 April 2012 21:44, Eric Schulte <eric.schulte@gmx.com> wrote:
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> On 28/03/12 01:07, Bastien wrote:
>>> Hi Rainer,
>>>
>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>
>>>> So I would see it as a useful way of promoting babel (and therefore org-mode) and also as a
>>>> nice reminder of less frequently (but nevertheless usefull) functionality.
>>>
>>> Agreed.
>>>
>>> Is anyone volunteering for listing the items in such a menu for Babel?
>>>
>>> If so, I'm willing to implement this.
>> OK - let me start this.
>>
>> Org
>> |
>> + Babel
>>   |
>>   + edit
>>   |  |
>>   |  + open surce buffer (that C-c ')
>>   |  + insert source block skeleton
>>   |  + ...
>>   |  + ...
>>   |
>>   + tangle
>>   |  |
>>   |  + tangle buffer
>>   |  + inverse tangle
>>   |  + ...
>>   |  + ...
>>   |
>>   + evaluate
>>   |  |
>>   |  + evaluate code block
>>   |  + evaluate subtree
>>   |  + ...
>>   |  + ...
>>   |  + ...
>>   |  + ...
>>   |
>>   + help
>>   |  |
>>   |  + Link to info help on header arguments
>>   |  + Link to info help on how to enable languages
>>   |  + URL to language specific help on worg
>>   |  + ...
>>   |  + ...
>>
>>
>> So - At the moment this is a skeleton of the babel menu - Comments? forgotten commands (I assume
>> many?
>>
>
> Hi Rainer,
>
> Thanks for starting this.  It looks like a great skeleton.  Here are a
> couple of comments which I hope are helpful.
>
> To find more publicly available Babel function you can do C-c C-v h in
> an Org-mode buffer or run the org-babel-describe-bindings command
>
> There are two high level sub-menus which I may suggest be added to the
> above, namely "languages" and "library of babel", which could list
> information on available languages and list library of babel functions
> respectively.
>
> I'm not sure how menus are normally used, specifically how Emacs breaks
> functionality between the menu, configuration and help sub-systems.  It
> is possible that because of such boundaries both the "help" and
> "languages" submenus may not be appropriate.
>
> Two other pieces of menu content which occur to me are a list of the
> code blocks available in the current buffer including some information
> on each block (e.g., name, arguments,), and a way to show the user what
> the current file wide header arguments are -- note: there already exists
> a function for displaying this information on the code block level
> `org-babel-view-source-block-info' which may be sufficient.
>
> Cheers,
>
>>
>>>
>>> I'm not convince we should have a menu item to (de)activate each language though -- more a menu
>>> that exposes the basics.
>>
>> Agreed.
>>
>> Cheers,
>>
>> Rainer
>>
>>
>>
>>
>>>
>>> Thanks,
>>>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>

Re: layout org-babel menu WAS: About org-babel menu

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/04/12 03:51, Torsten Wagner wrote:
> Hi,

Hi,

> 
> for me the biggest "trouble" with babel is to remember the possible keywords in the header for
> different languages.

True - I use mainly R and basic sh, but the header arguments cause me agauin and again to look in
the help (actually not the worst thing to do...).

> There were a lot of ongoing syntax change which did not make it easier for me to remember all
> this. Thus a menu which is organised by languages offering all possible settings for each
> language would be very helpful. | Python |    | |  export - code - result - both - none |    | 
> |  tangle - no - yes- filename |   | |  result - value - output |  | | ... | ...

A menu entry for each language would be nice - also show which ones are available.

> 
> Not sure how effectual this would be in a main menu. It would be definitely awesome in a
> context menu

Context menu in emacs? I guess something more I did not know? I assume it is not the
"right-mouse-click" kind?

> 
> That would be (copied from worg) [*] indicates cursor position
> 
> #+NAME: factorial #+BEGIN_SRC haskell [*] :results silent :exports code :var n=0
> 
> a context menu would appear presenting all possible header arguments for haskell
> 
> #+NAME: factorial #+BEGIN_SRC haskell :results [*] :exports code :var n=0
> 
> a context menu presenting all possible values for the header argument :results in haskell

When you mentioned header arguments, I thought about tab-completion based on the language. This
would obviously only (?) work for header arguments in the #+begin_src line, bt would be very
useful: when I press tab (or another key like "tag completion) the possible header arguments are
auto-expanded. Next step: auto complete for the options for the specific header argument. But a
menue would also be nice.


> I guess that together with the possibility to call this menu by keyboard strokes or
> alternatively show the same infos in the minibuffer would be a great win for babel and it would
> make many questions here on the list unnecessary.

Ups - similar to what I described above...

> Furthermore, any change or extension in the syntax for a certain language would be directly
> reflected to the end-user. E.g., If I suddenly see the menu entry :exports 3dprint, I would be
> curious and check it out on worg and the manual ;)

True - one huge plus for org babel are the header arguments - and it is easy to stay with the ones
one knows and ignore / forget new ones although they might be very useful.

I just r-organised the menu a bit, separated into general header arguments and language specific
header arguments:

Org
|
+ Babel
  |
  + edit
  |  |
  |  + open surce buffer (that C-c ')
  |  + insert source block skeleton
  |  + ...
  |  + ...
  |
  + header arguments
  |  |
  |  + general
  |  |   + export ...
  |  |   + ...
  |  |
  |  |
  |  + Language specific
  |  |   + R
  |  |   |    + file ...
  |  |   |    + ...
  |  |   |    + ...
  |  |   + Python
  |  |   |    + ...
  |  |   |    + ...
  |  |   |
  |  |   + ...
  |  |
  |  + Show
  |  |    + Header arguments for code block
  |  |    + Header arguments for all code block in buffer
  |  |    + ...
  |
  + tangle
  |  |
  |  + tangle buffer
  |  + inverse tangle
  |  + ...
  |  + ...
  |
  + evaluate
  |  |
  |  + evaluate code block
  |  + evaluate subtree
  |  + ...
  |  + ...
  |  + ...
  |  + ...
  |
  + Library of BABEL
  |  |
  |  + ...
  |
  + help
  |  |
  |  + Link to info help on header arguments
  |  + Link to info help on how to enable languages
  |  + URL to language specific help on worg
  |  + ...
  |  + ...

Eric: you suggestion of Language is really good. Could the language be a sub-menu of the help (or
should it rather be called Documentation?) as it is information only?
I like the "library of babel" submenu - especially as I never used the "library of babel" and I
assume I am missing a lot...

Eric: Displaying information about code block: very good idea - and I think a hierarchical display
would be really nice, so that on can see file wide, subtree properties and block header arguments,
maybe also for the whole file in a tree structure? I included it above.

Any further comments?

Cheers,

Rainer
> 
> Totti
> 
> 
> 
> On 5 April 2012 21:44, Eric Schulte <eric.schulte@gmx.com> wrote:
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>> 
>>> On 28/03/12 01:07, Bastien wrote:
>>>> Hi Rainer,
>>>> 
>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>> 
>>>>> So I would see it as a useful way of promoting babel (and therefore org-mode) and also
>>>>> as a nice reminder of less frequently (but nevertheless usefull) functionality.
>>>> 
>>>> Agreed.
>>>> 
>>>> Is anyone volunteering for listing the items in such a menu for Babel?
>>>> 
>>>> If so, I'm willing to implement this.
>>> OK - let me start this.
>>> 
>>> Org | + Babel | + edit |  | |  + open surce buffer (that C-c ') |  + insert source block
>>> skeleton |  + ... |  + ... | + tangle |  | |  + tangle buffer |  + inverse tangle |  + ... 
>>> |  + ... | + evaluate |  | |  + evaluate code block |  + evaluate subtree |  + ... |  +
>>> ... |  + ... |  + ... | + help |  | |  + Link to info help on header arguments |  + Link to
>>> info help on how to enable languages |  + URL to language specific help on worg |  + ... |
>>> + ...
>>> 
>>> 
>>> So - At the moment this is a skeleton of the babel menu - Comments? forgotten commands (I
>>> assume many?
>>> 
>> 
>> Hi Rainer,
>> 
>> Thanks for starting this.  It looks like a great skeleton.  Here are a couple of comments
>> which I hope are helpful.
>> 
>> To find more publicly available Babel function you can do C-c C-v h in an Org-mode buffer or
>> run the org-babel-describe-bindings command
>> 
>> There are two high level sub-menus which I may suggest be added to the above, namely
>> "languages" and "library of babel", which could list information on available languages and
>> list library of babel functions respectively.
>> 
>> I'm not sure how menus are normally used, specifically how Emacs breaks functionality between
>> the menu, configuration and help sub-systems.  It is possible that because of such boundaries
>> both the "help" and "languages" submenus may not be appropriate.
>> 
>> Two other pieces of menu content which occur to me are a list of the code blocks available in
>> the current buffer including some information on each block (e.g., name, arguments,), and a
>> way to show the user what the current file wide header arguments are -- note: there already
>> exists a function for displaying this information on the code block level 
>> `org-babel-view-source-block-info' which may be sufficient.
>> 
>> Cheers,
>> 
>>> 
>>>> 
>>>> I'm not convince we should have a menu item to (de)activate each language though -- more
>>>> a menu that exposes the basics.
>>> 
>>> Agreed.
>>> 
>>> Cheers,
>>> 
>>> Rainer
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> Thanks,
>>>> 
>> 
>> -- Eric Schulte http://cs.unm.edu/~eschulte/
>> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9+jmIACgkQoYgNqgF2egozjQCeKRLKsrYPtb+1E5PcJtIKImxF
pR4An0IvSrHTTIfZASSFBkH/A6e7VM/4
=acIM
-----END PGP SIGNATURE-----

Re: layout org-babel menu WAS: About org-babel menu

[Thorsten]

Hi, 

>> for me the biggest "trouble" with babel is to remember the possible keywords in the header for
>> different languages.

I prepared a little table for the header keywords, not language specific
and maybe not complete, but at least a systematic summary of headers and
values:

http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-picolisp.html

-- 
cheers,
Thorsten

Re: layout org-babel menu WAS: About org-babel menu

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/04/12 08:48, Thorsten wrote:
> 
> Hi,
> 
>>> for me the biggest "trouble" with babel is to remember the possible keywords in the header
>>> for different languages.
> 
> I prepared a little table for the header keywords, not language specific and maybe not
> complete, but at least a systematic summary of headers and values:
> 
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-picolisp.html
> 
Looks nice - good starting point for a page in work about header arguments.

Cheers,

Rainer

- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9+lA8ACgkQoYgNqgF2egqGjwCeOGTyEwGxQa9Yl43uNf1+3lyR
PRcAoIhdcA53jprpdnvg0N5xM6ykfFWq
=FVvq
-----END PGP SIGNATURE-----

Re: layout org-babel menu WAS: About org-babel menu

[Bastien]

Hi Thorsten,

Thorsten <quintfall@googlemail.com> writes:

> I prepared a little table for the header keywords, not language specific
> and maybe not complete, but at least a systematic summary of headers and
> values:
>
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-picolisp.html

When it's completed and if it's not picolisp specific, maybe you can
move this to a more general page about Babel ?  Or even on a standalone
page?

Thanks!

-- 
 Bastien

Re: layout org-babel menu WAS: About org-babel menu

[Thorsten]

Bastien <bzg@gnu.org> writes:

Hi Bastien,

> Thorsten <quintfall@googlemail.com> writes:
>
>> I prepared a little table for the header keywords, not language specific
>> and maybe not complete, but at least a systematic summary of headers and
>> values:
>>
>> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-picolisp.html
>
> When it's completed and if it's not picolisp specific, maybe you can
> move this to a more general page about Babel ?  Or even on a standalone
> page?

I extracted the tables from the picolisp page to a standalone page
(http://orgmode.org/worg/org-contrib/babel/header-args.html) that may be
accessed via the babel index page (item References and Documentation).
This might be a starting point for a complete and exhaustive overview of
header args and result types in Babel including the language specific
ones. So everyone is invited to improve this page. 

-- 
cheers,
Thorsten

Re: layout org-babel menu WAS: About org-babel menu

[Thomas S. Dye]

Torsten Wagner <torsten.wagner@gmail.com> writes:

> Hi,
>
> for me the biggest "trouble" with babel is to remember the possible
> keywords in the header for different languages.
> There were a lot of ongoing syntax change which did not make it easier
> for me to remember all this.
> Thus a menu which is organised by languages offering all possible
> settings for each language would be very helpful.
> |
> Python
> |    |
> |  export - code - result - both - none
> |    |
> |  tangle - no - yes- filename
> |   |
> |  result - value - output
> |  |
> | ...
> |
> ...
>
> Not sure how effectual this would be in a main menu. It would be
> definitely awesome in a context menu
>
> That would be (copied from worg) [*] indicates cursor position
>
> #+NAME: factorial
> #+BEGIN_SRC haskell [*] :results silent :exports code :var n=0
>
> a context menu would appear presenting all possible header arguments for haskell
>
> #+NAME: factorial
> #+BEGIN_SRC haskell :results [*] :exports code :var n=0
>
> a context menu presenting all possible values for the header argument
> :results in haskell
> I guess that together with the possibility to call this menu by
> keyboard strokes or alternatively show the same infos in the
> minibuffer would be a great win for babel and it would make many
> questions here on the list unnecessary.
> Furthermore, any change or extension in the syntax for a certain
> language would be directly reflected to the end-user. E.g., If I
> suddenly see the menu entry :exports 3dprint, I would be curious and
> check it out on worg and the manual ;)
>
> Totti

Aloha Totti,

I wonder if your context menu idea might be easy to accomplish with a
function template?  YASnippet has a way to choose a value from a list.

All the best,
Tom

>
>
>
> On 5 April 2012 21:44, Eric Schulte <eric.schulte@gmx.com> wrote:
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>
>>> On 28/03/12 01:07, Bastien wrote:
>>>> Hi Rainer,
>>>>
>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>
>>>>> So I would see it as a useful way of promoting babel (and therefore org-mode) and also as a
>>>>> nice reminder of less frequently (but nevertheless usefull) functionality.
>>>>
>>>> Agreed.
>>>>
>>>> Is anyone volunteering for listing the items in such a menu for Babel?
>>>>
>>>> If so, I'm willing to implement this.
>>> OK - let me start this.
>>>
>>> Org
>>> |
>>> + Babel
>>>   |
>>>   + edit
>>>   |  |
>>>   |  + open surce buffer (that C-c ')
>>>   |  + insert source block skeleton
>>>   |  + ...
>>>   |  + ...
>>>   |
>>>   + tangle
>>>   |  |
>>>   |  + tangle buffer
>>>   |  + inverse tangle
>>>   |  + ...
>>>   |  + ...
>>>   |
>>>   + evaluate
>>>   |  |
>>>   |  + evaluate code block
>>>   |  + evaluate subtree
>>>   |  + ...
>>>   |  + ...
>>>   |  + ...
>>>   |  + ...
>>>   |
>>>   + help
>>>   |  |
>>>   |  + Link to info help on header arguments
>>>   |  + Link to info help on how to enable languages
>>>   |  + URL to language specific help on worg
>>>   |  + ...
>>>   |  + ...
>>>
>>>
>>> So - At the moment this is a skeleton of the babel menu - Comments? forgotten commands (I assume
>>> many?
>>>
>>
>> Hi Rainer,
>>
>> Thanks for starting this.  It looks like a great skeleton.  Here are a
>> couple of comments which I hope are helpful.
>>
>> To find more publicly available Babel function you can do C-c C-v h in
>> an Org-mode buffer or run the org-babel-describe-bindings command
>>
>> There are two high level sub-menus which I may suggest be added to the
>> above, namely "languages" and "library of babel", which could list
>> information on available languages and list library of babel functions
>> respectively.
>>
>> I'm not sure how menus are normally used, specifically how Emacs breaks
>> functionality between the menu, configuration and help sub-systems.  It
>> is possible that because of such boundaries both the "help" and
>> "languages" submenus may not be appropriate.
>>
>> Two other pieces of menu content which occur to me are a list of the
>> code blocks available in the current buffer including some information
>> on each block (e.g., name, arguments,), and a way to show the user what
>> the current file wide header arguments are -- note: there already exists
>> a function for displaying this information on the code block level
>> `org-babel-view-source-block-info' which may be sufficient.
>>
>> Cheers,
>>
>>>
>>>>
>>>> I'm not convince we should have a menu item to (de)activate each language though -- more a menu
>>>> that exposes the basics.
>>>
>>> Agreed.
>>>
>>> Cheers,
>>>
>>> Rainer
>>>
>>>
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>
>> --
>> Eric Schulte
>> http://cs.unm.edu/~eschulte/
>>
>
>

-- 
Thomas S. Dye
http://www.tsdye.com

Re: layout org-babel menu WAS: About org-babel menu

[Eric Schulte]

Torsten Wagner <torsten.wagner@gmail.com> writes:

> Hi,
>
> for me the biggest "trouble" with babel is to remember the possible
> keywords in the header for different languages.
> There were a lot of ongoing syntax change which did not make it easier
> for me to remember all this.
> Thus a menu which is organised by languages offering all possible
> settings for each language would be very helpful.
> |
> Python
> |    |
> |  export - code - result - both - none
> |    |
> |  tangle - no - yes- filename
> |   |
> |  result - value - output
> |  |
> | ...
> |
> ...
>
> Not sure how effectual this would be in a main menu. It would be
> definitely awesome in a context menu
>
> That would be (copied from worg) [*] indicates cursor position
>
> #+NAME: factorial
> #+BEGIN_SRC haskell [*] :results silent :exports code :var n=0
>
> a context menu would appear presenting all possible header arguments for haskell
>
> #+NAME: factorial
> #+BEGIN_SRC haskell :results [*] :exports code :var n=0
>
> a context menu presenting all possible values for the header argument
> :results in haskell
> I guess that together with the possibility to call this menu by
> keyboard strokes or alternatively show the same infos in the
> minibuffer would be a great win for babel and it would make many
> questions here on the list unnecessary.
> Furthermore, any change or extension in the syntax for a certain
> language would be directly reflected to the end-user. E.g., If I
> suddenly see the menu entry :exports 3dprint, I would be curious and
> check it out on worg and the manual ;)
>
> Totti
>

Hi,

I've put together a first pass at such support for interactive header
argument look up.  Please evaluate this elisp code [1] in your *scratch*
buffer, then in an Org-mode buffer insert a code block like the
following with the point at [*], and press tab.

#+begin_src R :[*]
  :foo
#+end_src

You should see an auto-completion list showing which header arguments
are available and (for those with known arguments) which arguments may
be specified.  This includes language specific header arguments, i.e.,
the R code block above suggests about twice as many possible header
arguments as an elisp block.  Note this "expand on tab after :" behavior
is active on "#+headers:" lines as well.

This makes use of the `org-babel-common-header-args-w-values' variable
which holds header argument names and completions, as well as the
org-babel-header-arg-names:lang variables.

Does this seem like a good interface?

Is it missing any important functionality?

Best,

Footnotes: 
[1]  
;; Add support for completing-read insertion of header arguments after ":"
(defun org-babel-header-arg-expand ()
  "Call `org-babel-enter-header-arg-w-completion' in appropriate contexts."
  (when (and (= (char-before) ?\:) (org-babel-where-is-src-block-head))
    (org-babel-enter-header-arg-w-completion (match-string 2))))

(defun org-babel-enter-header-arg-w-completion (&optional lang)
  "Insert header argument appropriate for LANG with completion."
  (let* ((lang-headers-var (intern (concat "org-babel-header-arg-names:" lang)))
         (lang-headers (when (boundp lang-headers-var)
                         (mapcar #'symbol-name (eval lang-headers-var))))
         (headers (append (mapcar #'symbol-name org-babel-header-arg-names)
                          lang-headers))
         (header (org-completing-read "Header Arg: " headers))
         (args (cdr (assoc (intern header)
                           org-babel-common-header-args-w-values)))
         (arg (when (and args (listp args))
                (org-completing-read
                 (format "%s: " header)
                 (mapcar #'symbol-name (car args))))))
    (insert (concat header " " (or arg "")))
    (cons header arg)))

(add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: layout org-babel menu WAS: About org-babel menu

[Thomas S. Dye]

Eric Schulte <eric.schulte@gmx.com> writes:

> Torsten Wagner <torsten.wagner@gmail.com> writes:
>
>> Hi,
>>
>> for me the biggest "trouble" with babel is to remember the possible
>> keywords in the header for different languages.
>> There were a lot of ongoing syntax change which did not make it easier
>> for me to remember all this.
>> Thus a menu which is organised by languages offering all possible
>> settings for each language would be very helpful.
>> |
>> Python
>> |    |
>> |  export - code - result - both - none
>> |    |
>> |  tangle - no - yes- filename
>> |   |
>> |  result - value - output
>> |  |
>> | ...
>> |
>> ...
>>
>> Not sure how effectual this would be in a main menu. It would be
>> definitely awesome in a context menu
>>
>> That would be (copied from worg) [*] indicates cursor position
>>
>> #+NAME: factorial
>> #+BEGIN_SRC haskell [*] :results silent :exports code :var n=0
>>
>> a context menu would appear presenting all possible header arguments for haskell
>>
>> #+NAME: factorial
>> #+BEGIN_SRC haskell :results [*] :exports code :var n=0
>>
>> a context menu presenting all possible values for the header argument
>> :results in haskell
>> I guess that together with the possibility to call this menu by
>> keyboard strokes or alternatively show the same infos in the
>> minibuffer would be a great win for babel and it would make many
>> questions here on the list unnecessary.
>> Furthermore, any change or extension in the syntax for a certain
>> language would be directly reflected to the end-user. E.g., If I
>> suddenly see the menu entry :exports 3dprint, I would be curious and
>> check it out on worg and the manual ;)
>>
>> Totti
>>
>
> Hi,
>
> I've put together a first pass at such support for interactive header
> argument look up.  Please evaluate this elisp code [1] in your *scratch*
> buffer, then in an Org-mode buffer insert a code block like the
> following with the point at [*], and press tab.
>
> #+begin_src R :[*]
>   :foo
> #+end_src
>
> You should see an auto-completion list showing which header arguments
> are available and (for those with known arguments) which arguments may
> be specified.  This includes language specific header arguments, i.e.,
> the R code block above suggests about twice as many possible header
> arguments as an elisp block.  Note this "expand on tab after :" behavior
> is active on "#+headers:" lines as well.
>
> This makes use of the `org-babel-common-header-args-w-values' variable
> which holds header argument names and completions, as well as the
> org-babel-header-arg-names:lang variables.
>
> Does this seem like a good interface?
>
> Is it missing any important functionality?
>
> Best,
>
> Footnotes: 
> [1]  
> ;; Add support for completing-read insertion of header arguments after ":"
> (defun org-babel-header-arg-expand ()
>   "Call `org-babel-enter-header-arg-w-completion' in appropriate contexts."
>   (when (and (= (char-before) ?\:) (org-babel-where-is-src-block-head))
>     (org-babel-enter-header-arg-w-completion (match-string 2))))
>
> (defun org-babel-enter-header-arg-w-completion (&optional lang)
>   "Insert header argument appropriate for LANG with completion."
>   (let* ((lang-headers-var (intern (concat "org-babel-header-arg-names:" lang)))
>          (lang-headers (when (boundp lang-headers-var)
>                          (mapcar #'symbol-name (eval lang-headers-var))))
>          (headers (append (mapcar #'symbol-name org-babel-header-arg-names)
>                           lang-headers))
>          (header (org-completing-read "Header Arg: " headers))
>          (args (cdr (assoc (intern header)
>                            org-babel-common-header-args-w-values)))
>          (arg (when (and args (listp args))
>                 (org-completing-read
>                  (format "%s: " header)
>                  (mapcar #'symbol-name (car args))))))
>     (insert (concat header " " (or arg "")))
>     (cons header arg)))
>
> (add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)

Hi Eric,

This is potentially much nicer than a function template.  I tried
filling out an R source code block's header arguments, but I couldn't
find a way to get :results output graphics, which I use frequently for
ggplot2 graphics.  With TAB I could see type arguments, but not
collection or handling arguments.  Is there some way to cycle through
the various completion lists?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: layout org-babel menu WAS: About org-babel menu

[Eric Schulte]

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

tsd@tsdye.com (Thomas S. Dye) writes:

> Eric Schulte <eric.schulte@gmx.com> writes:
>
>> Torsten Wagner <torsten.wagner@gmail.com> writes:
>>
>>> Hi,
>>>
>>> for me the biggest "trouble" with babel is to remember the possible
>>> keywords in the header for different languages.
>>> There were a lot of ongoing syntax change which did not make it easier
>>> for me to remember all this.
>>> Thus a menu which is organised by languages offering all possible
>>> settings for each language would be very helpful.
>>> |
>>> Python
>>> |    |
>>> |  export - code - result - both - none
>>> |    |
>>> |  tangle - no - yes- filename
>>> |   |
>>> |  result - value - output
>>> |  |
>>> | ...
>>> |
>>> ...
>>>
>>> Not sure how effectual this would be in a main menu. It would be
>>> definitely awesome in a context menu
>>>
>>> That would be (copied from worg) [*] indicates cursor position
>>>
>>> #+NAME: factorial
>>> #+BEGIN_SRC haskell [*] :results silent :exports code :var n=0
>>>
>>> a context menu would appear presenting all possible header arguments for haskell
>>>
>>> #+NAME: factorial
>>> #+BEGIN_SRC haskell :results [*] :exports code :var n=0
>>>
>>> a context menu presenting all possible values for the header argument
>>> :results in haskell
>>> I guess that together with the possibility to call this menu by
>>> keyboard strokes or alternatively show the same infos in the
>>> minibuffer would be a great win for babel and it would make many
>>> questions here on the list unnecessary.
>>> Furthermore, any change or extension in the syntax for a certain
>>> language would be directly reflected to the end-user. E.g., If I
>>> suddenly see the menu entry :exports 3dprint, I would be curious and
>>> check it out on worg and the manual ;)
>>>
>>> Totti
>>>
>>
>> Hi,
>>
>> I've put together a first pass at such support for interactive header
>> argument look up.  Please evaluate this elisp code [1] in your *scratch*
>> buffer, then in an Org-mode buffer insert a code block like the
>> following with the point at [*], and press tab.
>>
>> #+begin_src R :[*]
>>   :foo
>> #+end_src
>>
>> You should see an auto-completion list showing which header arguments
>> are available and (for those with known arguments) which arguments may
>> be specified.  This includes language specific header arguments, i.e.,
>> the R code block above suggests about twice as many possible header
>> arguments as an elisp block.  Note this "expand on tab after :" behavior
>> is active on "#+headers:" lines as well.
>>
>> This makes use of the `org-babel-common-header-args-w-values' variable
>> which holds header argument names and completions, as well as the
>> org-babel-header-arg-names:lang variables.
>>
>> Does this seem like a good interface?
>>
>> Is it missing any important functionality?
>>
>> Best,
>>
>> Footnotes: 
>> [1]  
>> ;; Add support for completing-read insertion of header arguments after ":"
>> (defun org-babel-header-arg-expand ()
>>   "Call `org-babel-enter-header-arg-w-completion' in appropriate contexts."
>>   (when (and (= (char-before) ?\:) (org-babel-where-is-src-block-head))
>>     (org-babel-enter-header-arg-w-completion (match-string 2))))
>>
>> (defun org-babel-enter-header-arg-w-completion (&optional lang)
>>   "Insert header argument appropriate for LANG with completion."
>>   (let* ((lang-headers-var (intern (concat "org-babel-header-arg-names:" lang)))
>>          (lang-headers (when (boundp lang-headers-var)
>>                          (mapcar #'symbol-name (eval lang-headers-var))))
>>          (headers (append (mapcar #'symbol-name org-babel-header-arg-names)
>>                           lang-headers))
>>          (header (org-completing-read "Header Arg: " headers))
>>          (args (cdr (assoc (intern header)
>>                            org-babel-common-header-args-w-values)))
>>          (arg (when (and args (listp args))
>>                 (org-completing-read
>>                  (format "%s: " header)
>>                  (mapcar #'symbol-name (car args))))))
>>     (insert (concat header " " (or arg "")))
>>     (cons header arg)))
>>
>> (add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)
>
> Hi Eric,
>
> This is potentially much nicer than a function template.  I tried
> filling out an R source code block's header arguments, but I couldn't
> find a way to get :results output graphics, which I use frequently for
> ggplot2 graphics.  With TAB I could see type arguments, but not
> collection or handling arguments.  Is there some way to cycle through
> the various completion lists?
>
> All the best,
> Tom

Hi Tom,

Currently language specific arguments for header arguments are not
stored in any elisp variables so there is no way to provide this
information to the auto completion function.  I'm adding a new suite of
language-specific variables which may be customized by each language to
provide information on language-specific header-argument arguments.

I've just put together this new code into a patch.  I'm not currently
able to run the test suite without massive failures (with or without
this patch), so I'm just attaching the patch here rather than pushing it
up directly.  If it works well on other people's systems I think it
should be committed.

After this is applied the language-specific header argument variables
will need to be fleshed out.  For example see the value of the
`org-babel-header-args:R' which includes the "graphics" results option.
The arguments of these variables will override the arguments of specific
headers in the global `org-babel-common-header-args-w-values' variable.

Best,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-code-block-languages-may-specify-their-own-headers-a.patch --]
[-- Type: text/x-patch, Size: 9849 bytes --]

From ff3d974ff4d0aa93d3c241709557f6858ebf284f Mon Sep 17 00:00:00 2001
From: Eric Schulte <eric.schulte@gmx.com>
Date: Tue, 10 Apr 2012 19:03:37 -0400
Subject: [PATCH] code-block languages may specify their own headers and
 values

* lisp/ob-R.el (org-babel-header-args:R): Adding values.
* lisp/ob-clojure.el (org-babel-header-args:clojure): Adding values.
* lisp/ob-lisp.el (org-babel-header-args:lisp): Adding values.
* lisp/ob-sql.el (org-babel-header-args:sql): Adding values.
* lisp/ob-sqlite.el (org-babel-header-args:sqlite): Adding values.
* lisp/ob.el (org-babel-combine-header-arg-lists): Combine lists of
  arguments and values.
  (org-babel-insert-header-arg): Use new combined header argument
  lists.
  (org-babel-header-arg-expand): Add support for completing-read
  insertion of header arguments after ":"
  (org-babel-enter-header-arg-w-completion): Completing read insertion
  of header arguments
  (org-tab-first-hook): Adding header argument completion.
  (org-babel-params-from-properties): Combining header argument lists.
* testing/lisp/test-ob.el (ob-test/org-babel-combine-header-arg-lists):
  Test the new header argument combination functionality.
---
 lisp/ob-R.el            |   29 +++++++++++++++++++---
 lisp/ob-clojure.el      |    2 +-
 lisp/ob-lisp.el         |    2 +-
 lisp/ob-sql.el          |    5 ++--
 lisp/ob-sqlite.el       |   14 +++++++++--
 lisp/ob.el              |   62 +++++++++++++++++++++++++++++++++++++----------
 testing/lisp/test-ob.el |   18 ++++++++++++++
 7 files changed, 109 insertions(+), 23 deletions(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 49a8a85..9538dc4 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -40,10 +40,31 @@
 (declare-function ess-eval-buffer "ext:ess-inf" (vis))
 (declare-function org-number-sequence "org-compat" (from &optional to inc))
 
-(defconst org-babel-header-arg-names:R
-  '(width height bg units pointsize antialias quality compression
-	  res type family title fonts version paper encoding
-	  pagecentre colormodel useDingbats horizontal)
+(defconst org-babel-header-args:R
+  '((width		 . :any)
+    (height		 . :any)
+    (bg			 . :any)
+    (units		 . :any)
+    (pointsize		 . :any)
+    (antialias		 . :any)
+    (quality		 . :any)
+    (compression	 . :any)
+    (res		 . :any)
+    (type		 . :any)
+    (family		 . :any)
+    (title		 . :any)
+    (fonts		 . :any)
+    (version		 . :any)
+    (paper		 . :any)
+    (encoding		 . :any)
+    (pagecentre		 . :any)
+    (colormodel		 . :any)
+    (useDingbats	 . :any)
+    (horizontal		 . :any)
+    (results             . ((file list vector table scalar verbatim)
+			    (raw org html latex code pp wrap)
+			    (replace silent append prepend)
+			    (output value graphics))))
   "R-specific header arguments.")
 
 (defvar org-babel-default-header-args:R '())
diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 69d3db8..f389404 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -45,7 +45,7 @@
 (add-to-list 'org-babel-tangle-lang-exts '("clojure" . "clj"))
 
 (defvar org-babel-default-header-args:clojure '())
-(defvar org-babel-header-arg-names:clojure '(package))
+(defvar org-babel-header-args:clojure '((package . :any)))
 
 (defun org-babel-expand-body:clojure (body params)
   "Expand BODY according to PARAMS, return the expanded body."
diff --git a/lisp/ob-lisp.el b/lisp/ob-lisp.el
index 8fb6721..89dbe24 100644
--- a/lisp/ob-lisp.el
+++ b/lisp/ob-lisp.el
@@ -41,7 +41,7 @@
 (add-to-list 'org-babel-tangle-lang-exts '("lisp" . "lisp"))
 
 (defvar org-babel-default-header-args:lisp '())
-(defvar org-babel-header-arg-names:lisp '(package))
+(defvar org-babel-header-args:lisp '((package . :any)))
 
 (defcustom org-babel-lisp-dir-fmt
   "(let ((*default-pathname-defaults* #P%S)) %%s)"
diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 20fbad3..e3f6edd 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -51,8 +51,9 @@
 
 (defvar org-babel-default-header-args:sql '())
 
-(defvar org-babel-header-arg-names:sql
-  '(engine out-file))
+(defvar org-babel-header-args:sql
+  '((engine   . :any)
+    (out-file . :any)))
 
 (defun org-babel-expand-body:sql (body params)
   "Expand BODY according to the values of PARAMS."
diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
index 84d6bb2..2106072 100644
--- a/lisp/ob-sqlite.el
+++ b/lisp/ob-sqlite.el
@@ -37,8 +37,18 @@
 
 (defvar org-babel-default-header-args:sqlite '())
 
-(defvar org-babel-header-arg-names:sqlite
-  '(db header echo bail csv column html line list separator nullvalue)
+(defvar org-babel-header-args:sqlite
+  '((db        . :any)
+    (header    . :any)
+    (echo      . :any)
+    (bail      . :any)
+    (csv       . :any)
+    (column    . :any)
+    (html      . :any)
+    (line      . :any)
+    (list      . :any)
+    (separator . :any)
+    (nullvalue . :any))
   "Sqlite specific header args.")
 
 (defun org-babel-expand-body:sqlite (body params)
diff --git a/lisp/ob.el b/lisp/ob.el
index 726245c..df401b0 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -622,6 +622,19 @@ arguments and pop open the results in a preview buffer."
 		   (mmin (in (1- i) j) (in i (1- j)) (in (1- i) (1- j)))))))
       (in l1 l2))))
 
+(defun org-babel-combine-header-arg-lists (original &rest others)
+  "Combine a number of lists of header argument names and arguments."
+  (let ((results (copy-sequence original)))
+    (dolist (new-list others)
+      (dolist (arg-pair new-list)
+	(let ((header (car arg-pair))
+	      (args (cdr arg-pair)))
+	  (setq results
+		(cons arg-pair (org-remove-if
+				(lambda (pair) (equal header (car pair)))
+				results))))))
+    results))
+
 ;;;###autoload
 (defun org-babel-check-src-block ()
   "Check for misspelled header arguments in the current code block."
@@ -649,12 +662,10 @@ arguments and pop open the results in a preview buffer."
   "Insert a header argument selecting from lists of common args and values."
   (interactive)
   (let* ((lang (car (org-babel-get-src-block-info 'light)))
-	 (lang-headers (intern (concat "org-babel-header-arg-names:" lang)))
-	 (headers (append (if (boundp lang-headers)
-			      (mapcar (lambda (h) (cons h :any))
-				      (eval lang-headers))
-			    nil)
-			  org-babel-common-header-args-w-values))
+	 (lang-headers (intern (concat "org-babel-header-args:" lang)))
+	 (headers (org-babel-combine-header-arg-lists
+		   org-babel-common-header-args-w-values
+		   (if (boundp lang-headers) (eval lang-headers) nil)))
 	 (arg (org-icompleting-read
 	      "Header Arg: "
 	      (mapcar
@@ -679,6 +690,30 @@ arguments and pop open the results in a preview buffer."
 		  "")))
 	    vals ""))))))))
 
+;; Add support for completing-read insertion of header arguments after ":"
+(defun org-babel-header-arg-expand ()
+  "Call `org-babel-enter-header-arg-w-completion' in appropriate contexts."
+  (when (and (= (char-before) ?\:) (org-babel-where-is-src-block-head))
+    (org-babel-enter-header-arg-w-completion (match-string 2))))
+
+(defun org-babel-enter-header-arg-w-completion (&optional lang)
+  "Insert header argument appropriate for LANG with completion."
+  (let* ((lang-headers-var (intern (concat "org-babel-header-args:" lang)))
+         (lang-headers (when (boundp lang-headers-var) (eval lang-headers-var)))
+	 (headers-w-values (org-babel-combine-header-arg-lists
+			    org-babel-common-header-args-w-values lang-headers))
+         (headers (mapcar #'symbol-name (mapcar #'car headers-w-values)))
+         (header (org-completing-read "Header Arg: " headers))
+         (args (cdr (assoc (intern header) headers-w-values)))
+         (arg (when (and args (listp args))
+                (org-completing-read
+                 (format "%s: " header)
+                 (mapcar #'symbol-name (apply #'append args))))))
+    (insert (concat header " " (or arg "")))
+    (cons header arg)))
+
+(add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)
+
 ;;;###autoload
 (defun org-babel-load-in-session (&optional arg info)
   "Load the body of the current source-code block.
@@ -1153,13 +1188,14 @@ may be specified in the properties of the current outline entry."
 		     (cons (intern (concat ":" header-arg))
 			   (org-babel-read val))))
 	      (mapcar
-	       'symbol-name
-	       (append
-		org-babel-header-arg-names
-		(progn
-		  (setq sym (intern (concat "org-babel-header-arg-names:"
-					    lang)))
-		  (and (boundp sym) (eval sym)))))))))))
+	       #'symbol-name
+	       (mapcar
+		#'car
+		(org-babel-combine-header-arg-lists
+		 org-babel-common-header-args-w-values
+		 (progn
+		   (setq sym (intern (concat "org-babel-header-args:" lang)))
+		   (and (boundp sym) (eval sym))))))))))))
 
 (defvar org-src-preserve-indentation)
 (defun org-babel-parse-src-block-match ()
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 4dac696..5cf689a 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -87,6 +87,24 @@
 	  '((:session . "none") (:results . "replace") (:exports . "results"))
 	  org-babel-default-inline-header-args)))
 
+(ert-deftest ob-test/org-babel-combine-header-arg-lists ()
+  (let ((results (org-babel-combine-header-arg-lists
+                  '((foo  . :any)
+                    (bar)
+                    (baz  . ((foo bar) (baz)))
+                    (qux  . ((foo bar baz qux)))
+                    (quux . ((foo bar))))
+                  '((bar)
+                    (baz  . ((baz)))
+                    (quux . :any)))))
+    (dolist (pair '((foo  . :any)
+		    (bar)
+		    (baz  . ((baz)))
+		    (quux . :any)
+		    (qux  . ((foo bar baz qux)))))
+      (should (equal (cdr pair)
+                     (cdr (assoc (car pair) results)))))))
+
 ;;; ob-get-src-block-info
 (ert-deftest test-org-babel/get-src-block-info-language ()
   (org-test-at-marker nil org-test-file-ob-anchor
-- 
1.7.10


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


-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: layout org-babel menu WAS: About org-babel menu

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/04/12 03:40, Eric Schulte wrote:
> tsd@tsdye.com (Thomas S. Dye) writes:
> 
>> Eric Schulte <eric.schulte@gmx.com> writes:
>> 
>>> Torsten Wagner <torsten.wagner@gmail.com> writes:
>>> 
>>>> Hi,
>>>> 
>>>> for me the biggest "trouble" with babel is to remember the possible keywords in the
>>>> header for different languages. There were a lot of ongoing syntax change which did not
>>>> make it easier for me to remember all this. Thus a menu which is organised by languages
>>>> offering all possible settings for each language would be very helpful. | Python |    | |
>>>> export - code - result - both - none |    | |  tangle - no - yes- filename |   | |
>>>> result - value - output |  | | ... | ...
>>>> 
>>>> Not sure how effectual this would be in a main menu. It would be definitely awesome in a
>>>> context menu
>>>> 
>>>> That would be (copied from worg) [*] indicates cursor position
>>>> 
>>>> #+NAME: factorial #+BEGIN_SRC haskell [*] :results silent :exports code :var n=0
>>>> 
>>>> a context menu would appear presenting all possible header arguments for haskell
>>>> 
>>>> #+NAME: factorial #+BEGIN_SRC haskell :results [*] :exports code :var n=0
>>>> 
>>>> a context menu presenting all possible values for the header argument :results in
>>>> haskell I guess that together with the possibility to call this menu by keyboard strokes
>>>> or alternatively show the same infos in the minibuffer would be a great win for babel and
>>>> it would make many questions here on the list unnecessary. Furthermore, any change or
>>>> extension in the syntax for a certain language would be directly reflected to the
>>>> end-user. E.g., If I suddenly see the menu entry :exports 3dprint, I would be curious
>>>> and check it out on worg and the manual ;)
>>>> 
>>>> Totti
>>>> 
>>> 
>>> Hi,
>>> 
>>> I've put together a first pass at such support for interactive header argument look up.
>>> Please evaluate this elisp code [1] in your *scratch* buffer, then in an Org-mode buffer
>>> insert a code block like the following with the point at [*], and press tab.
>>> 
>>> #+begin_src R :[*] :foo #+end_src
>>> 
>>> You should see an auto-completion list showing which header arguments are available and
>>> (for those with known arguments) which arguments may be specified.  This includes language
>>> specific header arguments, i.e., the R code block above suggests about twice as many
>>> possible header arguments as an elisp block.  Note this "expand on tab after :" behavior is
>>> active on "#+headers:" lines as well.
>>> 
>>> This makes use of the `org-babel-common-header-args-w-values' variable which holds header
>>> argument names and completions, as well as the org-babel-header-arg-names:lang variables.
>>> 
>>> Does this seem like a good interface?
>>> 
>>> Is it missing any important functionality?
>>> 
>>> Best,
>>> 
>>> Footnotes: [1] ;; Add support for completing-read insertion of header arguments after ":" 
>>> (defun org-babel-header-arg-expand () "Call `org-babel-enter-header-arg-w-completion' in
>>> appropriate contexts." (when (and (= (char-before) ?\:)
>>> (org-babel-where-is-src-block-head)) (org-babel-enter-header-arg-w-completion (match-string
>>> 2))))
>>> 
>>> (defun org-babel-enter-header-arg-w-completion (&optional lang) "Insert header argument
>>> appropriate for LANG with completion." (let* ((lang-headers-var (intern (concat
>>> "org-babel-header-arg-names:" lang))) (lang-headers (when (boundp lang-headers-var) (mapcar
>>> #'symbol-name (eval lang-headers-var)))) (headers (append (mapcar #'symbol-name
>>> org-babel-header-arg-names) lang-headers)) (header (org-completing-read "Header Arg: "
>>> headers)) (args (cdr (assoc (intern header) org-babel-common-header-args-w-values))) (arg
>>> (when (and args (listp args)) (org-completing-read (format "%s: " header) (mapcar
>>> #'symbol-name (car args)))))) (insert (concat header " " (or arg ""))) (cons header arg)))
>>> 
>>> (add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)
>> 
>> Hi Eric,
>> 
>> This is potentially much nicer than a function template.  I tried filling out an R source
>> code block's header arguments, but I couldn't find a way to get :results output graphics,
>> which I use frequently for ggplot2 graphics.  With TAB I could see type arguments, but not 
>> collection or handling arguments.  Is there some way to cycle through the various completion
>> lists?
>> 
>> All the best, Tom
> 
> Hi Tom,
> 
> Currently language specific arguments for header arguments are not stored in any elisp
> variables so there is no way to provide this information to the auto completion function.  I'm
> adding a new suite of language-specific variables which may be customized by each language to 
> provide information on language-specific header-argument arguments.
> 
> I've just put together this new code into a patch.  I'm not currently able to run the test
> suite without massive failures (with or without this patch), so I'm just attaching the patch
> here rather than pushing it up directly.  If it works well on other people's systems I think
> it should be committed.

Hi

I applied the patch and it seems to be working when used on #+header: but on
#+src_begin R  :[*]
#+end_src

it folds the code block when tab is pressed at [*]

No detailed further tests done.

Cheers,

Rainer

> 
> After this is applied the language-specific header argument variables will need to be fleshed
> out.  For example see the value of the `org-babel-header-args:R' which includes the "graphics"
> results option. The arguments of these variables will override the arguments of specific 
> headers in the global `org-babel-common-header-args-w-values' variable.
> 
> Best,
> 
> 
> 
> 
> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk+FMkIACgkQoYgNqgF2egoWEgCePdfvHHIgCNSB8N83oAGdOS8j
EcAAmK5Kl637U2PXGGSoSnfpU+Cn5WQ=
=miy4
-----END PGP SIGNATURE-----

Re: layout org-babel menu WAS: About org-babel menu

[Eric Schulte]

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

Rainer M Krug <r.m.krug@gmail.com> writes:

> On 11/04/12 03:40, Eric Schulte wrote:
>> tsd@tsdye.com (Thomas S. Dye) writes:
>> 
>>> Eric Schulte <eric.schulte@gmx.com> writes:
>>> 
>>>> Torsten Wagner <torsten.wagner@gmail.com> writes:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> for me the biggest "trouble" with babel is to remember the possible keywords in the
>>>>> header for different languages. There were a lot of ongoing syntax change which did not
>>>>> make it easier for me to remember all this. Thus a menu which is organised by languages
>>>>> offering all possible settings for each language would be very helpful. | Python |    | |
>>>>> export - code - result - both - none |    | |  tangle - no - yes- filename |   | |
>>>>> result - value - output |  | | ... | ...
>>>>> 
>>>>> Not sure how effectual this would be in a main menu. It would be definitely awesome in a
>>>>> context menu
>>>>> 
>>>>> That would be (copied from worg) [*] indicates cursor position
>>>>> 
>>>>> #+NAME: factorial #+BEGIN_SRC haskell [*] :results silent :exports code :var n=0
>>>>> 
>>>>> a context menu would appear presenting all possible header arguments for haskell
>>>>> 
>>>>> #+NAME: factorial #+BEGIN_SRC haskell :results [*] :exports code :var n=0
>>>>> 
>>>>> a context menu presenting all possible values for the header argument :results in
>>>>> haskell I guess that together with the possibility to call this menu by keyboard strokes
>>>>> or alternatively show the same infos in the minibuffer would be a great win for babel and
>>>>> it would make many questions here on the list unnecessary. Furthermore, any change or
>>>>> extension in the syntax for a certain language would be directly reflected to the
>>>>> end-user. E.g., If I suddenly see the menu entry :exports 3dprint, I would be curious
>>>>> and check it out on worg and the manual ;)
>>>>> 
>>>>> Totti
>>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> I've put together a first pass at such support for interactive header argument look up.
>>>> Please evaluate this elisp code [1] in your *scratch* buffer, then in an Org-mode buffer
>>>> insert a code block like the following with the point at [*], and press tab.
>>>> 
>>>> #+begin_src R :[*] :foo #+end_src
>>>> 
>>>> You should see an auto-completion list showing which header arguments are available and
>>>> (for those with known arguments) which arguments may be specified.  This includes language
>>>> specific header arguments, i.e., the R code block above suggests about twice as many
>>>> possible header arguments as an elisp block.  Note this "expand on tab after :" behavior is
>>>> active on "#+headers:" lines as well.
>>>> 
>>>> This makes use of the `org-babel-common-header-args-w-values' variable which holds header
>>>> argument names and completions, as well as the org-babel-header-arg-names:lang variables.
>>>> 
>>>> Does this seem like a good interface?
>>>> 
>>>> Is it missing any important functionality?
>>>> 
>>>> Best,
>>>> 
>>>> Footnotes: [1] ;; Add support for completing-read insertion of header arguments after ":" 
>>>> (defun org-babel-header-arg-expand () "Call `org-babel-enter-header-arg-w-completion' in
>>>> appropriate contexts." (when (and (= (char-before) ?\:)
>>>> (org-babel-where-is-src-block-head)) (org-babel-enter-header-arg-w-completion (match-string
>>>> 2))))
>>>> 
>>>> (defun org-babel-enter-header-arg-w-completion (&optional lang) "Insert header argument
>>>> appropriate for LANG with completion." (let* ((lang-headers-var (intern (concat
>>>> "org-babel-header-arg-names:" lang))) (lang-headers (when (boundp lang-headers-var) (mapcar
>>>> #'symbol-name (eval lang-headers-var)))) (headers (append (mapcar #'symbol-name
>>>> org-babel-header-arg-names) lang-headers)) (header (org-completing-read "Header Arg: "
>>>> headers)) (args (cdr (assoc (intern header) org-babel-common-header-args-w-values))) (arg
>>>> (when (and args (listp args)) (org-completing-read (format "%s: " header) (mapcar
>>>> #'symbol-name (car args)))))) (insert (concat header " " (or arg ""))) (cons header arg)))
>>>> 
>>>> (add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)
>>> 
>>> Hi Eric,
>>> 
>>> This is potentially much nicer than a function template.  I tried filling out an R source
>>> code block's header arguments, but I couldn't find a way to get :results output graphics,
>>> which I use frequently for ggplot2 graphics.  With TAB I could see type arguments, but not 
>>> collection or handling arguments.  Is there some way to cycle through the various completion
>>> lists?
>>> 
>>> All the best, Tom
>> 
>> Hi Tom,
>> 
>> Currently language specific arguments for header arguments are not stored in any elisp
>> variables so there is no way to provide this information to the auto completion function.  I'm
>> adding a new suite of language-specific variables which may be customized by each language to 
>> provide information on language-specific header-argument arguments.
>> 
>> I've just put together this new code into a patch.  I'm not currently able to run the test
>> suite without massive failures (with or without this patch), so I'm just attaching the patch
>> here rather than pushing it up directly.  If it works well on other people's systems I think
>> it should be committed.
>
> Hi
>
> I applied the patch and it seems to be working when used on #+header: but on
> #+src_begin R  :[*]
> #+end_src
>
> it folds the code block when tab is pressed at [*]
>
> No detailed further tests done.
>
> Cheers,
>
> Rainer
>

Thanks for checking this out.  Please try this new attached version
which move the header argument auto completion to the front of the
org-tab-first-hook.

Thanks,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-code-block-languages-may-specify-their-own-headers-a.patch --]
[-- Type: text/x-patch, Size: 10474 bytes --]

From a450373c69f1556bf9838112587352c743097f5d Mon Sep 17 00:00:00 2001
From: Eric Schulte <eric.schulte@gmx.com>
Date: Tue, 10 Apr 2012 19:03:37 -0400
Subject: [PATCH] code-block languages may specify their own headers and
 values

* lisp/ob-R.el (org-babel-header-args:R): Adding values.
* lisp/ob-clojure.el (org-babel-header-args:clojure): Adding values.
* lisp/ob-lisp.el (org-babel-header-args:lisp): Adding values.
* lisp/ob-sql.el (org-babel-header-args:sql): Adding values.
* lisp/ob-sqlite.el (org-babel-header-args:sqlite): Adding values.
* lisp/ob.el (org-babel-combine-header-arg-lists): Combine lists of
  arguments and values.
  (org-babel-insert-header-arg): Use new combined header argument
  lists.
  (org-babel-header-arg-expand): Add support for completing-read
  insertion of header arguments after ":"
  (org-babel-enter-header-arg-w-completion): Completing read insertion
  of header arguments
  (org-tab-first-hook): Adding header argument completion.
  (org-babel-params-from-properties): Combining header argument lists.
* testing/lisp/test-ob.el (ob-test/org-babel-combine-header-arg-lists):
  Test the new header argument combination functionality.
* lisp/org.el (org-tab-first-hook): Adding header argument
  auto-completion to the tab hook.
---
 lisp/ob-R.el            |   29 +++++++++++++++++++----
 lisp/ob-clojure.el      |    2 +-
 lisp/ob-lisp.el         |    2 +-
 lisp/ob-sql.el          |    5 ++--
 lisp/ob-sqlite.el       |   14 +++++++++--
 lisp/ob.el              |   60 +++++++++++++++++++++++++++++++++++++----------
 lisp/org.el             |    4 ++++
 testing/lisp/test-ob.el |   18 ++++++++++++++
 8 files changed, 111 insertions(+), 23 deletions(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 49a8a85..9538dc4 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -40,10 +40,31 @@
 (declare-function ess-eval-buffer "ext:ess-inf" (vis))
 (declare-function org-number-sequence "org-compat" (from &optional to inc))
 
-(defconst org-babel-header-arg-names:R
-  '(width height bg units pointsize antialias quality compression
-	  res type family title fonts version paper encoding
-	  pagecentre colormodel useDingbats horizontal)
+(defconst org-babel-header-args:R
+  '((width		 . :any)
+    (height		 . :any)
+    (bg			 . :any)
+    (units		 . :any)
+    (pointsize		 . :any)
+    (antialias		 . :any)
+    (quality		 . :any)
+    (compression	 . :any)
+    (res		 . :any)
+    (type		 . :any)
+    (family		 . :any)
+    (title		 . :any)
+    (fonts		 . :any)
+    (version		 . :any)
+    (paper		 . :any)
+    (encoding		 . :any)
+    (pagecentre		 . :any)
+    (colormodel		 . :any)
+    (useDingbats	 . :any)
+    (horizontal		 . :any)
+    (results             . ((file list vector table scalar verbatim)
+			    (raw org html latex code pp wrap)
+			    (replace silent append prepend)
+			    (output value graphics))))
   "R-specific header arguments.")
 
 (defvar org-babel-default-header-args:R '())
diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 69d3db8..f389404 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -45,7 +45,7 @@
 (add-to-list 'org-babel-tangle-lang-exts '("clojure" . "clj"))
 
 (defvar org-babel-default-header-args:clojure '())
-(defvar org-babel-header-arg-names:clojure '(package))
+(defvar org-babel-header-args:clojure '((package . :any)))
 
 (defun org-babel-expand-body:clojure (body params)
   "Expand BODY according to PARAMS, return the expanded body."
diff --git a/lisp/ob-lisp.el b/lisp/ob-lisp.el
index 8fb6721..89dbe24 100644
--- a/lisp/ob-lisp.el
+++ b/lisp/ob-lisp.el
@@ -41,7 +41,7 @@
 (add-to-list 'org-babel-tangle-lang-exts '("lisp" . "lisp"))
 
 (defvar org-babel-default-header-args:lisp '())
-(defvar org-babel-header-arg-names:lisp '(package))
+(defvar org-babel-header-args:lisp '((package . :any)))
 
 (defcustom org-babel-lisp-dir-fmt
   "(let ((*default-pathname-defaults* #P%S)) %%s)"
diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 20fbad3..e3f6edd 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -51,8 +51,9 @@
 
 (defvar org-babel-default-header-args:sql '())
 
-(defvar org-babel-header-arg-names:sql
-  '(engine out-file))
+(defvar org-babel-header-args:sql
+  '((engine   . :any)
+    (out-file . :any)))
 
 (defun org-babel-expand-body:sql (body params)
   "Expand BODY according to the values of PARAMS."
diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
index 84d6bb2..2106072 100644
--- a/lisp/ob-sqlite.el
+++ b/lisp/ob-sqlite.el
@@ -37,8 +37,18 @@
 
 (defvar org-babel-default-header-args:sqlite '())
 
-(defvar org-babel-header-arg-names:sqlite
-  '(db header echo bail csv column html line list separator nullvalue)
+(defvar org-babel-header-args:sqlite
+  '((db        . :any)
+    (header    . :any)
+    (echo      . :any)
+    (bail      . :any)
+    (csv       . :any)
+    (column    . :any)
+    (html      . :any)
+    (line      . :any)
+    (list      . :any)
+    (separator . :any)
+    (nullvalue . :any))
   "Sqlite specific header args.")
 
 (defun org-babel-expand-body:sqlite (body params)
diff --git a/lisp/ob.el b/lisp/ob.el
index 726245c..8a514ae 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -622,6 +622,19 @@ arguments and pop open the results in a preview buffer."
 		   (mmin (in (1- i) j) (in i (1- j)) (in (1- i) (1- j)))))))
       (in l1 l2))))
 
+(defun org-babel-combine-header-arg-lists (original &rest others)
+  "Combine a number of lists of header argument names and arguments."
+  (let ((results (copy-sequence original)))
+    (dolist (new-list others)
+      (dolist (arg-pair new-list)
+	(let ((header (car arg-pair))
+	      (args (cdr arg-pair)))
+	  (setq results
+		(cons arg-pair (org-remove-if
+				(lambda (pair) (equal header (car pair)))
+				results))))))
+    results))
+
 ;;;###autoload
 (defun org-babel-check-src-block ()
   "Check for misspelled header arguments in the current code block."
@@ -649,12 +662,10 @@ arguments and pop open the results in a preview buffer."
   "Insert a header argument selecting from lists of common args and values."
   (interactive)
   (let* ((lang (car (org-babel-get-src-block-info 'light)))
-	 (lang-headers (intern (concat "org-babel-header-arg-names:" lang)))
-	 (headers (append (if (boundp lang-headers)
-			      (mapcar (lambda (h) (cons h :any))
-				      (eval lang-headers))
-			    nil)
-			  org-babel-common-header-args-w-values))
+	 (lang-headers (intern (concat "org-babel-header-args:" lang)))
+	 (headers (org-babel-combine-header-arg-lists
+		   org-babel-common-header-args-w-values
+		   (if (boundp lang-headers) (eval lang-headers) nil)))
 	 (arg (org-icompleting-read
 	      "Header Arg: "
 	      (mapcar
@@ -679,6 +690,28 @@ arguments and pop open the results in a preview buffer."
 		  "")))
 	    vals ""))))))))
 
+;; Add support for completing-read insertion of header arguments after ":"
+(defun org-babel-header-arg-expand ()
+  "Call `org-babel-enter-header-arg-w-completion' in appropriate contexts."
+  (when (and (= (char-before) ?\:) (org-babel-where-is-src-block-head))
+    (org-babel-enter-header-arg-w-completion (match-string 2))))
+
+(defun org-babel-enter-header-arg-w-completion (&optional lang)
+  "Insert header argument appropriate for LANG with completion."
+  (let* ((lang-headers-var (intern (concat "org-babel-header-args:" lang)))
+         (lang-headers (when (boundp lang-headers-var) (eval lang-headers-var)))
+	 (headers-w-values (org-babel-combine-header-arg-lists
+			    org-babel-common-header-args-w-values lang-headers))
+         (headers (mapcar #'symbol-name (mapcar #'car headers-w-values)))
+         (header (org-completing-read "Header Arg: " headers))
+         (args (cdr (assoc (intern header) headers-w-values)))
+         (arg (when (and args (listp args))
+                (org-completing-read
+                 (format "%s: " header)
+                 (mapcar #'symbol-name (apply #'append args))))))
+    (insert (concat header " " (or arg "")))
+    (cons header arg)))
+
 ;;;###autoload
 (defun org-babel-load-in-session (&optional arg info)
   "Load the body of the current source-code block.
@@ -1153,13 +1186,14 @@ may be specified in the properties of the current outline entry."
 		     (cons (intern (concat ":" header-arg))
 			   (org-babel-read val))))
 	      (mapcar
-	       'symbol-name
-	       (append
-		org-babel-header-arg-names
-		(progn
-		  (setq sym (intern (concat "org-babel-header-arg-names:"
-					    lang)))
-		  (and (boundp sym) (eval sym)))))))))))
+	       #'symbol-name
+	       (mapcar
+		#'car
+		(org-babel-combine-header-arg-lists
+		 org-babel-common-header-args-w-values
+		 (progn
+		   (setq sym (intern (concat "org-babel-header-args:" lang)))
+		   (and (boundp sym) (eval sym))))))))))))
 
 (defvar org-src-preserve-indentation)
 (defun org-babel-parse-src-block-match ()
diff --git a/lisp/org.el b/lisp/org.el
index 170ddc9..96872ec 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6793,6 +6793,10 @@ Optional arguments START and END can be used to limit the range."
 
 ;; org-tab-after-check-for-cycling-hook
 (add-hook 'org-tab-first-hook 'org-hide-block-toggle-maybe)
+
+;; should proceed the previous function in the `org-tab-first-hook'
+(add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)
+
 ;; Remove overlays when changing major mode
 (add-hook 'org-mode-hook
 	  (lambda () (org-add-hook 'change-major-mode-hook
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 4dac696..5cf689a 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -87,6 +87,24 @@
 	  '((:session . "none") (:results . "replace") (:exports . "results"))
 	  org-babel-default-inline-header-args)))
 
+(ert-deftest ob-test/org-babel-combine-header-arg-lists ()
+  (let ((results (org-babel-combine-header-arg-lists
+                  '((foo  . :any)
+                    (bar)
+                    (baz  . ((foo bar) (baz)))
+                    (qux  . ((foo bar baz qux)))
+                    (quux . ((foo bar))))
+                  '((bar)
+                    (baz  . ((baz)))
+                    (quux . :any)))))
+    (dolist (pair '((foo  . :any)
+		    (bar)
+		    (baz  . ((baz)))
+		    (quux . :any)
+		    (qux  . ((foo bar baz qux)))))
+      (should (equal (cdr pair)
+                     (cdr (assoc (car pair) results)))))))
+
 ;;; ob-get-src-block-info
 (ert-deftest test-org-babel/get-src-block-info-language ()
   (org-test-at-marker nil org-test-file-ob-anchor
-- 
1.7.10


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


>
>> 
>> After this is applied the language-specific header argument variables will need to be fleshed
>> out.  For example see the value of the `org-babel-header-args:R' which includes the "graphics"
>> results option. The arguments of these variables will override the arguments of specific 
>> headers in the global `org-babel-common-header-args-w-values' variable.
>> 
>> Best,
>> 
>> 
>> 
>> 
>> 

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: layout org-babel menu WAS: About org-babel menu

[Thomas S. Dye]

Eric Schulte <eric.schulte@gmx.com> writes:

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> On 11/04/12 03:40, Eric Schulte wrote:
>>> tsd@tsdye.com (Thomas S. Dye) writes:
>>> 
>>>> Eric Schulte <eric.schulte@gmx.com> writes:
>>>> 
>>>>> Torsten Wagner <torsten.wagner@gmail.com> writes:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> for me the biggest "trouble" with babel is to remember the possible keywords in the
>>>>>> header for different languages. There were a lot of ongoing syntax change which did not
>>>>>> make it easier for me to remember all this. Thus a menu which is organised by languages
>>>>>> offering all possible settings for each language would be very helpful. | Python |    | |
>>>>>> export - code - result - both - none |    | |  tangle - no - yes- filename |   | |
>>>>>> result - value - output |  | | ... | ...
>>>>>> 
>>>>>> Not sure how effectual this would be in a main menu. It would be definitely awesome in a
>>>>>> context menu
>>>>>> 
>>>>>> That would be (copied from worg) [*] indicates cursor position
>>>>>> 
>>>>>> #+NAME: factorial #+BEGIN_SRC haskell [*] :results silent :exports code :var n=0
>>>>>> 
>>>>>> a context menu would appear presenting all possible header arguments for haskell
>>>>>> 
>>>>>> #+NAME: factorial #+BEGIN_SRC haskell :results [*] :exports code :var n=0
>>>>>> 
>>>>>> a context menu presenting all possible values for the header argument :results in
>>>>>> haskell I guess that together with the possibility to call this menu by keyboard strokes
>>>>>> or alternatively show the same infos in the minibuffer would be a great win for babel and
>>>>>> it would make many questions here on the list unnecessary. Furthermore, any change or
>>>>>> extension in the syntax for a certain language would be directly reflected to the
>>>>>> end-user. E.g., If I suddenly see the menu entry :exports 3dprint, I would be curious
>>>>>> and check it out on worg and the manual ;)
>>>>>> 
>>>>>> Totti
>>>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I've put together a first pass at such support for interactive header argument look up.
>>>>> Please evaluate this elisp code [1] in your *scratch* buffer, then in an Org-mode buffer
>>>>> insert a code block like the following with the point at [*], and press tab.
>>>>> 
>>>>> #+begin_src R :[*] :foo #+end_src
>>>>> 
>>>>> You should see an auto-completion list showing which header arguments are available and
>>>>> (for those with known arguments) which arguments may be specified.  This includes language
>>>>> specific header arguments, i.e., the R code block above suggests about twice as many
>>>>> possible header arguments as an elisp block.  Note this "expand on tab after :" behavior is
>>>>> active on "#+headers:" lines as well.
>>>>> 
>>>>> This makes use of the `org-babel-common-header-args-w-values' variable which holds header
>>>>> argument names and completions, as well as the org-babel-header-arg-names:lang variables.
>>>>> 
>>>>> Does this seem like a good interface?
>>>>> 
>>>>> Is it missing any important functionality?
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Footnotes: [1] ;; Add support for completing-read insertion of header arguments after ":" 
>>>>> (defun org-babel-header-arg-expand () "Call `org-babel-enter-header-arg-w-completion' in
>>>>> appropriate contexts." (when (and (= (char-before) ?\:)
>>>>> (org-babel-where-is-src-block-head)) (org-babel-enter-header-arg-w-completion (match-string
>>>>> 2))))
>>>>> 
>>>>> (defun org-babel-enter-header-arg-w-completion (&optional lang) "Insert header argument
>>>>> appropriate for LANG with completion." (let* ((lang-headers-var (intern (concat
>>>>> "org-babel-header-arg-names:" lang))) (lang-headers (when (boundp lang-headers-var) (mapcar
>>>>> #'symbol-name (eval lang-headers-var)))) (headers (append (mapcar #'symbol-name
>>>>> org-babel-header-arg-names) lang-headers)) (header (org-completing-read "Header Arg: "
>>>>> headers)) (args (cdr (assoc (intern header) org-babel-common-header-args-w-values))) (arg
>>>>> (when (and args (listp args)) (org-completing-read (format "%s: " header) (mapcar
>>>>> #'symbol-name (car args)))))) (insert (concat header " " (or arg ""))) (cons header arg)))
>>>>> 
>>>>> (add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)
>>>> 
>>>> Hi Eric,
>>>> 
>>>> This is potentially much nicer than a function template.  I tried filling out an R source
>>>> code block's header arguments, but I couldn't find a way to get :results output graphics,
>>>> which I use frequently for ggplot2 graphics.  With TAB I could see type arguments, but not 
>>>> collection or handling arguments.  Is there some way to cycle through the various completion
>>>> lists?
>>>> 
>>>> All the best, Tom
>>> 
>>> Hi Tom,
>>> 
>>> Currently language specific arguments for header arguments are not stored in any elisp
>>> variables so there is no way to provide this information to the auto completion function.  I'm
>>> adding a new suite of language-specific variables which may be customized by each language to 
>>> provide information on language-specific header-argument arguments.
>>> 
>>> I've just put together this new code into a patch.  I'm not currently able to run the test
>>> suite without massive failures (with or without this patch), so I'm just attaching the patch
>>> here rather than pushing it up directly.  If it works well on other people's systems I think
>>> it should be committed.
>>
>> Hi
>>
>> I applied the patch and it seems to be working when used on #+header: but on
>> #+src_begin R  :[*]
>> #+end_src
>>
>> it folds the code block when tab is pressed at [*]
>>
>> No detailed further tests done.
>>
>> Cheers,
>>
>> Rainer
>>
>
> Thanks for checking this out.  Please try this new attached version
> which move the header argument auto completion to the front of the
> org-tab-first-hook.
>
> Thanks,
>
> From a450373c69f1556bf9838112587352c743097f5d Mon Sep 17 00:00:00 2001
> From: Eric Schulte <eric.schulte@gmx.com>
> Date: Tue, 10 Apr 2012 19:03:37 -0400
> Subject: [PATCH] code-block languages may specify their own headers and
>  values
>
> * lisp/ob-R.el (org-babel-header-args:R): Adding values.
> * lisp/ob-clojure.el (org-babel-header-args:clojure): Adding values.
> * lisp/ob-lisp.el (org-babel-header-args:lisp): Adding values.
> * lisp/ob-sql.el (org-babel-header-args:sql): Adding values.
> * lisp/ob-sqlite.el (org-babel-header-args:sqlite): Adding values.
> * lisp/ob.el (org-babel-combine-header-arg-lists): Combine lists of
>   arguments and values.
>   (org-babel-insert-header-arg): Use new combined header argument
>   lists.
>   (org-babel-header-arg-expand): Add support for completing-read
>   insertion of header arguments after ":"
>   (org-babel-enter-header-arg-w-completion): Completing read insertion
>   of header arguments
>   (org-tab-first-hook): Adding header argument completion.
>   (org-babel-params-from-properties): Combining header argument lists.
> * testing/lisp/test-ob.el (ob-test/org-babel-combine-header-arg-lists):
>   Test the new header argument combination functionality.
> * lisp/org.el (org-tab-first-hook): Adding header argument
>   auto-completion to the tab hook.
> ---
>  lisp/ob-R.el            |   29 +++++++++++++++++++----
>  lisp/ob-clojure.el      |    2 +-
>  lisp/ob-lisp.el         |    2 +-
>  lisp/ob-sql.el          |    5 ++--
>  lisp/ob-sqlite.el       |   14 +++++++++--
>  lisp/ob.el              |   60 +++++++++++++++++++++++++++++++++++++----------
>  lisp/org.el             |    4 ++++
>  testing/lisp/test-ob.el |   18 ++++++++++++++
>  8 files changed, 111 insertions(+), 23 deletions(-)
>
> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
> index 49a8a85..9538dc4 100644
> --- a/lisp/ob-R.el
> +++ b/lisp/ob-R.el
> @@ -40,10 +40,31 @@
>  (declare-function ess-eval-buffer "ext:ess-inf" (vis))
>  (declare-function org-number-sequence "org-compat" (from &optional to inc))
>  
> -(defconst org-babel-header-arg-names:R
> -  '(width height bg units pointsize antialias quality compression
> -	  res type family title fonts version paper encoding
> -	  pagecentre colormodel useDingbats horizontal)
> +(defconst org-babel-header-args:R
> +  '((width		 . :any)
> +    (height		 . :any)
> +    (bg			 . :any)
> +    (units		 . :any)
> +    (pointsize		 . :any)
> +    (antialias		 . :any)
> +    (quality		 . :any)
> +    (compression	 . :any)
> +    (res		 . :any)
> +    (type		 . :any)
> +    (family		 . :any)
> +    (title		 . :any)
> +    (fonts		 . :any)
> +    (version		 . :any)
> +    (paper		 . :any)
> +    (encoding		 . :any)
> +    (pagecentre		 . :any)
> +    (colormodel		 . :any)
> +    (useDingbats	 . :any)
> +    (horizontal		 . :any)
> +    (results             . ((file list vector table scalar verbatim)
> +			    (raw org html latex code pp wrap)
> +			    (replace silent append prepend)
> +			    (output value graphics))))
>    "R-specific header arguments.")
>  
>  (defvar org-babel-default-header-args:R '())
> diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
> index 69d3db8..f389404 100644
> --- a/lisp/ob-clojure.el
> +++ b/lisp/ob-clojure.el
> @@ -45,7 +45,7 @@
>  (add-to-list 'org-babel-tangle-lang-exts '("clojure" . "clj"))
>  
>  (defvar org-babel-default-header-args:clojure '())
> -(defvar org-babel-header-arg-names:clojure '(package))
> +(defvar org-babel-header-args:clojure '((package . :any)))
>  
>  (defun org-babel-expand-body:clojure (body params)
>    "Expand BODY according to PARAMS, return the expanded body."
> diff --git a/lisp/ob-lisp.el b/lisp/ob-lisp.el
> index 8fb6721..89dbe24 100644
> --- a/lisp/ob-lisp.el
> +++ b/lisp/ob-lisp.el
> @@ -41,7 +41,7 @@
>  (add-to-list 'org-babel-tangle-lang-exts '("lisp" . "lisp"))
>  
>  (defvar org-babel-default-header-args:lisp '())
> -(defvar org-babel-header-arg-names:lisp '(package))
> +(defvar org-babel-header-args:lisp '((package . :any)))
>  
>  (defcustom org-babel-lisp-dir-fmt
>    "(let ((*default-pathname-defaults* #P%S)) %%s)"
> diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
> index 20fbad3..e3f6edd 100644
> --- a/lisp/ob-sql.el
> +++ b/lisp/ob-sql.el
> @@ -51,8 +51,9 @@
>  
>  (defvar org-babel-default-header-args:sql '())
>  
> -(defvar org-babel-header-arg-names:sql
> -  '(engine out-file))
> +(defvar org-babel-header-args:sql
> +  '((engine   . :any)
> +    (out-file . :any)))
>  
>  (defun org-babel-expand-body:sql (body params)
>    "Expand BODY according to the values of PARAMS."
> diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
> index 84d6bb2..2106072 100644
> --- a/lisp/ob-sqlite.el
> +++ b/lisp/ob-sqlite.el
> @@ -37,8 +37,18 @@
>  
>  (defvar org-babel-default-header-args:sqlite '())
>  
> -(defvar org-babel-header-arg-names:sqlite
> -  '(db header echo bail csv column html line list separator nullvalue)
> +(defvar org-babel-header-args:sqlite
> +  '((db        . :any)
> +    (header    . :any)
> +    (echo      . :any)
> +    (bail      . :any)
> +    (csv       . :any)
> +    (column    . :any)
> +    (html      . :any)
> +    (line      . :any)
> +    (list      . :any)
> +    (separator . :any)
> +    (nullvalue . :any))
>    "Sqlite specific header args.")
>  
>  (defun org-babel-expand-body:sqlite (body params)
> diff --git a/lisp/ob.el b/lisp/ob.el
> index 726245c..8a514ae 100644
> --- a/lisp/ob.el
> +++ b/lisp/ob.el
> @@ -622,6 +622,19 @@ arguments and pop open the results in a preview buffer."
>  		   (mmin (in (1- i) j) (in i (1- j)) (in (1- i) (1- j)))))))
>        (in l1 l2))))
>  
> +(defun org-babel-combine-header-arg-lists (original &rest others)
> +  "Combine a number of lists of header argument names and arguments."
> +  (let ((results (copy-sequence original)))
> +    (dolist (new-list others)
> +      (dolist (arg-pair new-list)
> +	(let ((header (car arg-pair))
> +	      (args (cdr arg-pair)))
> +	  (setq results
> +		(cons arg-pair (org-remove-if
> +				(lambda (pair) (equal header (car pair)))
> +				results))))))
> +    results))
> +
>  ;;;###autoload
>  (defun org-babel-check-src-block ()
>    "Check for misspelled header arguments in the current code block."
> @@ -649,12 +662,10 @@ arguments and pop open the results in a preview buffer."
>    "Insert a header argument selecting from lists of common args and values."
>    (interactive)
>    (let* ((lang (car (org-babel-get-src-block-info 'light)))
> -	 (lang-headers (intern (concat "org-babel-header-arg-names:" lang)))
> -	 (headers (append (if (boundp lang-headers)
> -			      (mapcar (lambda (h) (cons h :any))
> -				      (eval lang-headers))
> -			    nil)
> -			  org-babel-common-header-args-w-values))
> +	 (lang-headers (intern (concat "org-babel-header-args:" lang)))
> +	 (headers (org-babel-combine-header-arg-lists
> +		   org-babel-common-header-args-w-values
> +		   (if (boundp lang-headers) (eval lang-headers) nil)))
>  	 (arg (org-icompleting-read
>  	      "Header Arg: "
>  	      (mapcar
> @@ -679,6 +690,28 @@ arguments and pop open the results in a preview buffer."
>  		  "")))
>  	    vals ""))))))))
>  
> +;; Add support for completing-read insertion of header arguments after ":"
> +(defun org-babel-header-arg-expand ()
> +  "Call `org-babel-enter-header-arg-w-completion' in appropriate contexts."
> +  (when (and (= (char-before) ?\:) (org-babel-where-is-src-block-head))
> +    (org-babel-enter-header-arg-w-completion (match-string 2))))
> +
> +(defun org-babel-enter-header-arg-w-completion (&optional lang)
> +  "Insert header argument appropriate for LANG with completion."
> +  (let* ((lang-headers-var (intern (concat "org-babel-header-args:" lang)))
> +         (lang-headers (when (boundp lang-headers-var) (eval lang-headers-var)))
> +	 (headers-w-values (org-babel-combine-header-arg-lists
> +			    org-babel-common-header-args-w-values lang-headers))
> +         (headers (mapcar #'symbol-name (mapcar #'car headers-w-values)))
> +         (header (org-completing-read "Header Arg: " headers))
> +         (args (cdr (assoc (intern header) headers-w-values)))
> +         (arg (when (and args (listp args))
> +                (org-completing-read
> +                 (format "%s: " header)
> +                 (mapcar #'symbol-name (apply #'append args))))))
> +    (insert (concat header " " (or arg "")))
> +    (cons header arg)))
> +
>  ;;;###autoload
>  (defun org-babel-load-in-session (&optional arg info)
>    "Load the body of the current source-code block.
> @@ -1153,13 +1186,14 @@ may be specified in the properties of the current outline entry."
>  		     (cons (intern (concat ":" header-arg))
>  			   (org-babel-read val))))
>  	      (mapcar
> -	       'symbol-name
> -	       (append
> -		org-babel-header-arg-names
> -		(progn
> -		  (setq sym (intern (concat "org-babel-header-arg-names:"
> -					    lang)))
> -		  (and (boundp sym) (eval sym)))))))))))
> +	       #'symbol-name
> +	       (mapcar
> +		#'car
> +		(org-babel-combine-header-arg-lists
> +		 org-babel-common-header-args-w-values
> +		 (progn
> +		   (setq sym (intern (concat "org-babel-header-args:" lang)))
> +		   (and (boundp sym) (eval sym))))))))))))
>  
>  (defvar org-src-preserve-indentation)
>  (defun org-babel-parse-src-block-match ()
> diff --git a/lisp/org.el b/lisp/org.el
> index 170ddc9..96872ec 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -6793,6 +6793,10 @@ Optional arguments START and END can be used to limit the range."
>  
>  ;; org-tab-after-check-for-cycling-hook
>  (add-hook 'org-tab-first-hook 'org-hide-block-toggle-maybe)
> +
> +;; should proceed the previous function in the `org-tab-first-hook'
> +(add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)
> +
>  ;; Remove overlays when changing major mode
>  (add-hook 'org-mode-hook
>  	  (lambda () (org-add-hook 'change-major-mode-hook
> diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
> index 4dac696..5cf689a 100644
> --- a/testing/lisp/test-ob.el
> +++ b/testing/lisp/test-ob.el
> @@ -87,6 +87,24 @@
>  	  '((:session . "none") (:results . "replace") (:exports . "results"))
>  	  org-babel-default-inline-header-args)))
>  
> +(ert-deftest ob-test/org-babel-combine-header-arg-lists ()
> +  (let ((results (org-babel-combine-header-arg-lists
> +                  '((foo  . :any)
> +                    (bar)
> +                    (baz  . ((foo bar) (baz)))
> +                    (qux  . ((foo bar baz qux)))
> +                    (quux . ((foo bar))))
> +                  '((bar)
> +                    (baz  . ((baz)))
> +                    (quux . :any)))))
> +    (dolist (pair '((foo  . :any)
> +		    (bar)
> +		    (baz  . ((baz)))
> +		    (quux . :any)
> +		    (qux  . ((foo bar baz qux)))))
> +      (should (equal (cdr pair)
> +                     (cdr (assoc (car pair) results)))))))
> +
>  ;;; ob-get-src-block-info
>  (ert-deftest test-org-babel/get-src-block-info-language ()
>    (org-test-at-marker nil org-test-file-ob-anchor
> -- 
> 1.7.10
>
>
>>
>>> 
>>> After this is applied the language-specific header argument variables will need to be fleshed
>>> out.  For example see the value of the `org-babel-header-args:R' which includes the "graphics"
>>> results option. The arguments of these variables will override the arguments of specific 
>>> headers in the global `org-babel-common-header-args-w-values' variable.
>>> 
>>> Best,
>>> 
>>> 
>>> 
>>> 
>>> 

Hi Eric,

Sorry to hear the test suite isn't working for you currently.  I know
you've put a lot of work into it and have come to rely on it.

It will be a few days before I find time to work with the autocompletion
patch, but look forward to it and will get back to you with comments.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: layout org-babel menu WAS: About org-babel menu

[Eric Schulte]

[...]
>>>>> 
>>>>> Hi Eric,
>>>>> 
>>>>> This is potentially much nicer than a function template.  I tried filling out an R source
>>>>> code block's header arguments, but I couldn't find a way to get :results output graphics,
>>>>> which I use frequently for ggplot2 graphics.  With TAB I could see type arguments, but not 
>>>>> collection or handling arguments.  Is there some way to cycle through the various completion
>>>>> lists?
>>>>> 
>>>>> All the best, Tom
>>>> 
>>>> Hi Tom,
>>>> 
>>>> Currently language specific arguments for header arguments are not stored in any elisp
>>>> variables so there is no way to provide this information to the auto completion function.  I'm
>>>> adding a new suite of language-specific variables which may be customized by each language to 
>>>> provide information on language-specific header-argument arguments.
>>>> 
>>>> I've just put together this new code into a patch.  I'm not currently able to run the test
>>>> suite without massive failures (with or without this patch), so I'm just attaching the patch
>>>> here rather than pushing it up directly.  If it works well on other people's systems I think
>>>> it should be committed.

[...]

>>>> After this is applied the language-specific header argument variables will need to be fleshed
>>>> out.  For example see the value of the `org-babel-header-args:R' which includes the "graphics"
>>>> results option. The arguments of these variables will override the arguments of specific 
>>>> headers in the global `org-babel-common-header-args-w-values' variable.
>>>> 
>>>> Best,
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>
> Hi Eric,
>
> Sorry to hear the test suite isn't working for you currently.  I know
> you've put a lot of work into it and have come to rely on it.
>
> It will be a few days before I find time to work with the autocompletion
> patch, but look forward to it and will get back to you with comments.
>
> All the best,
> Tom

Hi,

Thanks for your concern over the test suite.  I believe the problem is
that I've been trying to stick to the version of Org-mode included in
the Emacs24 pre-test, which has changed my load path and means that the
latest version of Org-mode and the test suite take extra care to load.

Since both Rainer and myself have run this successfully I've just pushed
it up to the main repo.  Please let me know if it causes any problems.

At some point in the next couple of weeks we should both flesh out the
language-specific header argument variables and document this new
auto-complete behavior (although I'm not sure where this documentation
should live).

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

[bug?] Re: layout org-babel menu

[Yagnesh Raghava Yakkala]

Hello Eric,

Eric Schulte <eric.schulte@gmx.com> writes:
> Hi,
>
> Thanks for your concern over the test suite.  I believe the problem is
> that I've been trying to stick to the version of Org-mode included in
> the Emacs24 pre-test, which has changed my load path and means that the
> latest version of Org-mode and the test suite take extra care to load.
>
> Since both Rainer and myself have run this successfully I've just pushed
> it up to the main repo.  Please let me know if it causes any problems.
>
> At some point in the next couple of weeks we should both flesh out the
> language-specific header argument variables and document this new
> auto-complete behavior (although I'm not sure where this documentation
> should live).
>
> Best,

A possible bug coming from your commit.

I have message-mode hooks defined as follows,

(add-hook 'message-mode-hook 'turn-on-orgstruct++)
(add-hook 'message-mode-hook 'turn-on-orgtbl)

pressing C-x m to compose new message., I am getting this debugger message

,----
|   debug(error (wrong-type-argument number-or-marker-p nil))
|   org-babel-header-arg-expand()
|   run-hook-with-args-until-success(org-babel-header-arg-expand)
|   org-cycle((4))
|   org-set-startup-visibility()
|   org-mode()
|   org-get-local-variables()
|   orgstruct-setup()
|   orgstruct-mode(1)
|   orgstruct++-mode(1)
|   turn-on-orgstruct++()
|   run-hooks(change-major-mode-after-body-hook text-mode-hook message-mode-hook)
|   apply(run-hooks (change-major-mode-after-body-hook text-mode-hook message-mode-hook))
|   run-mode-hooks(message-mode-hook)
|   message-mode()
|   message-pop-to-buffer("*unsent mail*" nil)
|   message-mail()
|   gnus-summary-mail-other-window(nil)
|   call-interactively(gnus-summary-mail-other-window)
|   gnus-article-read-summary-keys(nil)
|   call-interactively(gnus-article-read-summary-keys nil nil)
| 
`----

Thanks.,
-- 
YYR

Re: [bug?] Re: layout org-babel menu

[Eric Schulte]

Yagnesh Raghava Yakkala <yagnesh@live.com> writes:

> Hello Eric,
>
> Eric Schulte <eric.schulte@gmx.com> writes:
>> Hi,
>>
>> Thanks for your concern over the test suite.  I believe the problem is
>> that I've been trying to stick to the version of Org-mode included in
>> the Emacs24 pre-test, which has changed my load path and means that the
>> latest version of Org-mode and the test suite take extra care to load.
>>
>> Since both Rainer and myself have run this successfully I've just pushed
>> it up to the main repo.  Please let me know if it causes any problems.
>>
>> At some point in the next couple of weeks we should both flesh out the
>> language-specific header argument variables and document this new
>> auto-complete behavior (although I'm not sure where this documentation
>> should live).
>>
>> Best,
>
> A possible bug coming from your commit.
>
> I have message-mode hooks defined as follows,
>
> (add-hook 'message-mode-hook 'turn-on-orgstruct++)
> (add-hook 'message-mode-hook 'turn-on-orgtbl)
>
> pressing C-x m to compose new message., I am getting this debugger message
>
> ,----
> |   debug(error (wrong-type-argument number-or-marker-p nil))

Hi Yagnesh,

Thanks for posting this error.  I've just pushed up a simple fix which
should solve this problem.

Best,

> |   
> |   org-babel-header-arg-expand()
> |   run-hook-with-args-until-success(org-babel-header-arg-expand)
> |   org-cycle((4)) org-set-startup-visibility() org-mode()
> |   org-get-local-variables() orgstruct-setup() orgstruct-mode(1)
> |   orgstruct++-mode(1) turn-on-orgstruct++()
> |   run-hooks(change-major-mode-after-body-hook text-mode-hook
> |   message-mode-hook) apply(run-hooks
> |   (change-major-mode-after-body-hook text-mode-hook
> |   message-mode-hook)) run-mode-hooks(message-mode-hook)
> |   message-mode() message-pop-to-buffer("*unsent mail*" nil)
> |   message-mail() gnus-summary-mail-other-window(nil)
> |   call-interactively(gnus-summary-mail-other-window)
> |   gnus-article-read-summary-keys(nil)
> |   call-interactively(gnus-article-read-summary-keys nil nil)
> | 
> `----
>
> Thanks.,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [bug?] Re: layout org-babel menu

[Nick Dokos]

Eric Schulte <eric.schulte@gmx.com> wrote:

> Yagnesh Raghava Yakkala <yagnesh@live.com> writes:
> 
> > Hello Eric,
> >
> > Eric Schulte <eric.schulte@gmx.com> writes:
> >> Hi,
> >>
> >> Thanks for your concern over the test suite.  I believe the problem is
> >> that I've been trying to stick to the version of Org-mode included in
> >> the Emacs24 pre-test, which has changed my load path and means that the
> >> latest version of Org-mode and the test suite take extra care to load.
> >>
> >> Since both Rainer and myself have run this successfully I've just pushed
> >> it up to the main repo.  Please let me know if it causes any problems.
> >>
> >> At some point in the next couple of weeks we should both flesh out the
> >> language-specific header argument variables and document this new
> >> auto-complete behavior (although I'm not sure where this documentation
> >> should live).
> >>
> >> Best,
> >
> > A possible bug coming from your commit.
> >
> > I have message-mode hooks defined as follows,
> >
> > (add-hook 'message-mode-hook 'turn-on-orgstruct++)
> > (add-hook 'message-mode-hook 'turn-on-orgtbl)
> >
> > pressing C-x m to compose new message., I am getting this debugger message
> >
> > ,----
> > |   debug(error (wrong-type-argument number-or-marker-p nil))
> 
> Hi Yagnesh,
> 
> Thanks for posting this error.  I've just pushed up a simple fix which
> should solve this problem.
> 

Confirmed.

Nick

> Best,
> 
> > |   
> > |   org-babel-header-arg-expand()
> > |   run-hook-with-args-until-success(org-babel-header-arg-expand)
> > |   org-cycle((4)) org-set-startup-visibility() org-mode()
> > |   org-get-local-variables() orgstruct-setup() orgstruct-mode(1)
> > |   orgstruct++-mode(1) turn-on-orgstruct++()
> > |   run-hooks(change-major-mode-after-body-hook text-mode-hook
> > |   message-mode-hook) apply(run-hooks
> > |   (change-major-mode-after-body-hook text-mode-hook
> > |   message-mode-hook)) run-mode-hooks(message-mode-hook)
> > |   message-mode() message-pop-to-buffer("*unsent mail*" nil)
> > |   message-mail() gnus-summary-mail-other-window(nil)
> > |   call-interactively(gnus-summary-mail-other-window)
> > |   gnus-article-read-summary-keys(nil)
> > |   call-interactively(gnus-article-read-summary-keys nil nil)
> > | 
> > `----
> >
> > Thanks.,
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte/
> 

Re: layout org-babel menu WAS: About org-babel menu

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/04/12 23:51, Eric Schulte wrote:
> Torsten Wagner <torsten.wagner@gmail.com> writes:
> 
>> Hi,
>> 
>> for me the biggest "trouble" with babel is to remember the possible keywords in the header
>> for different languages. There were a lot of ongoing syntax change which did not make it
>> easier for me to remember all this. Thus a menu which is organised by languages offering all
>> possible settings for each language would be very helpful. | Python |    | |  export - code -
>> result - both - none |    | |  tangle - no - yes- filename |   | |  result - value - output |
>> | | ... | ...
>> 
>> Not sure how effectual this would be in a main menu. It would be definitely awesome in a
>> context menu
>> 
>> That would be (copied from worg) [*] indicates cursor position
>> 
>> #+NAME: factorial #+BEGIN_SRC haskell [*] :results silent :exports code :var n=0
>> 
>> a context menu would appear presenting all possible header arguments for haskell
>> 
>> #+NAME: factorial #+BEGIN_SRC haskell :results [*] :exports code :var n=0
>> 
>> a context menu presenting all possible values for the header argument :results in haskell I
>> guess that together with the possibility to call this menu by keyboard strokes or
>> alternatively show the same infos in the minibuffer would be a great win for babel and it
>> would make many questions here on the list unnecessary. Furthermore, any change or extension
>> in the syntax for a certain language would be directly reflected to the end-user. E.g., If I 
>> suddenly see the menu entry :exports 3dprint, I would be curious and check it out on worg and
>> the manual ;)
>> 
>> Totti
>> 
> 
> Hi,
> 
> I've put together a first pass at such support for interactive header argument look up.  Please
> evaluate this elisp code [1] in your *scratch* buffer, then in an Org-mode buffer insert a code
> block like the following with the point at [*], and press tab.
> 
> #+begin_src R :[*] :foo #+end_src
> 
> You should see an auto-completion list showing which header arguments are available and (for
> those with known arguments) which arguments may be specified.  This includes language specific
> header arguments, i.e., the R code block above suggests about twice as many possible header 
> arguments as an elisp block.  Note this "expand on tab after :" behavior is active on
> "#+headers:" lines as well.
> 
> This makes use of the `org-babel-common-header-args-w-values' variable which holds header
> argument names and completions, as well as the org-babel-header-arg-names:lang variables.
> 
> Does this seem like a good interface?

That looks really good - and I already seen a few header arguments I was not aware of. I haven't
played a lot with it at the moment, but I would very much have it in org as soon as possible - any
chance of adding it so that more users can try it easily?

Thanks a lot - looks really good, and I would say that with an autocomplete like this, a menu
entry for header arguments (except help section) is not needed any more?

Cheers,

Rainer


> 
> Is it missing any important functionality?
> 
> Best,
> 
> Footnotes: [1] ;; Add support for completing-read insertion of header arguments after ":" 
> (defun org-babel-header-arg-expand () "Call `org-babel-enter-header-arg-w-completion' in
> appropriate contexts." (when (and (= (char-before) ?\:) (org-babel-where-is-src-block-head)) 
> (org-babel-enter-header-arg-w-completion (match-string 2))))
> 
> (defun org-babel-enter-header-arg-w-completion (&optional lang) "Insert header argument
> appropriate for LANG with completion." (let* ((lang-headers-var (intern (concat
> "org-babel-header-arg-names:" lang))) (lang-headers (when (boundp lang-headers-var) (mapcar
> #'symbol-name (eval lang-headers-var)))) (headers (append (mapcar #'symbol-name
> org-babel-header-arg-names) lang-headers)) (header (org-completing-read "Header Arg: "
> headers)) (args (cdr (assoc (intern header) org-babel-common-header-args-w-values))) (arg (when
> (and args (listp args)) (org-completing-read (format "%s: " header) (mapcar #'symbol-name (car
> args)))))) (insert (concat header " " (or arg ""))) (cons header arg)))
> 
> (add-hook 'org-tab-first-hook 'org-babel-header-arg-expand)
> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+D6c8ACgkQoYgNqgF2egpADACdEV42FKP0GzgsuvQmeEjHJ8d1
rWAAoImD7XHqmDlH5OCt0w9rLe0pq4K+
=ssL5
-----END PGP SIGNATURE-----

Re: layout org-babel menu WAS: About org-babel menu

[Bastien]

Guys,

let me know when you have a first stable draft for the structure of the
Babel menu and I'll implement it.

Thanks,

-- 
 Bastien

Re: layout org-babel menu WAS: About org-babel menu

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/04/12 22:35, Bastien wrote:
> Guys,
> 
> let me know when you have a first stable draft for the structure of the Babel menu and I'll
> implement it.

Thanks Bastien - here is my suggestion and if no objections are raised, I would suggest to
implement it:

OK - here it is:

Org
|
+ Babel
  |
  + edit
  |  |
  |  + open surce buffer (that C-c ')
  |  + insert source block skeleton for
  |     + R
  |     + sh
  |     + ... all languages supported
  |
  + header arguments
  |  |
  |  + general
  |  |   + export ...
  |  |   + ...
  |  |
  |  |
  |  + Language specific
  |  |   + R
  |  |   |    + file ...
  |  |   |    + ...
  |  |   |    + ...
  |  |   + Python
  |  |   |    + ...
  |  |   |    + ...
  |  |   |
  |  |   + ...
  |  |
  |  + Show
  |  |    + Header arguments for code block
  |  |    + Header arguments for all code block in buffer
  |  |    + ...
  |
  + tangle
  |  |
  |  + tangle buffer
  |  + tangle subtree (I think this is implemented - isn't it?
  |  + inverse tangle
  |
  + evaluate
  |  |
  |  + evaluate code block
  |  + evaluate subtree
  |
  + Library of BABEL
  |  |
  |  + ... functions in the library - is this feasible?
  |
  + help
  |  |
  |  + Link to info help on header arguments
  |  + Link to info help on how to enable languages
  |  + URL to language specific help on worg
  |  + ...
  |  + ...

I think that is it for the moment - the header arguments section, specifically the language
specific one, should possibly be left out as Eric is working on the autocomplete feature, which
could possibly be called from the menu as well when implemented?

Cheers and thanks,

Rainer


> 
> Thanks,
> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+FLlQACgkQoYgNqgF2egqSJQCePvBoq1tw/4c2I6J/sfOHA9TP
rRUAnAnWSeuz04zbfpAhmbe9PmuKE6Rw
=Jjyu
-----END PGP SIGNATURE-----

Re: layout org-babel menu WAS: About org-babel menu

[Yagnesh Raghava Yakkala]

Rainer M Krug <r.m.krug@gmail.com> writes:

> On 10/04/12 22:35, Bastien wrote:
>> Guys,
>> 
>> let me know when you have a first stable draft for the structure of the Babel menu and I'll
>> implement it.
>
> Thanks Bastien - here is my suggestion and if no objections are raised, I would suggest to
> implement it:

FWIW, I am working on this, I hope to submit initial patch in the coming
weekend. I am kinda slow with my Elisp. 

Thanks
-- 
YYR

Re: layout org-babel menu WAS: About org-babel menu

[Bastien]

Yagnesh Raghava Yakkala <yagnesh@live.com> writes:

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> On 10/04/12 22:35, Bastien wrote:
>>> Guys,
>>> 
>>> let me know when you have a first stable draft for the structure of the Babel menu and I'll
>>> implement it.
>>
>> Thanks Bastien - here is my suggestion and if no objections are raised, I would suggest to
>> implement it:
>
> FWIW, I am working on this, I hope to submit initial patch in the coming
> weekend. I am kinda slow with my Elisp. 

Great, looking forward your patch then.

Please double-check http://orgmode.org/worg/org-contribute.html#sec-5
on how to submit it in a way that makes it easy for us to apply it.

Best,

-- 
 Bastien

Re: layout org-babel menu WAS: About org-babel menu

[Bastien]

Hi Rainer,

Rainer M Krug <r.m.krug@gmail.com> writes:

> Thanks Bastien - here is my suggestion and if no objections are raised, I would suggest to
> implement it:

I don't understand the "..." parts in your example.

> I think that is it for the moment - the header arguments section, specifically the language
> specific one, should possibly be left out as Eric is working on the autocomplete feature, which
> could possibly be called from the menu as well when implemented?

Eric's take.

Thanks!

-- 
 Bastien

Re: layout org-babel menu WAS: About org-babel menu

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed 11 Apr 2012 10:11:01 CEST, Bastien wrote:
> Hi Rainer,
>
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> Thanks Bastien - here is my suggestion and if no objections are raised, I would suggest to
>> implement it:
>
> I don't understand the "..." parts in your example.

e.g. "... all languages supported" means a menu entry should be added
for each language.

Similar in the "header" menu, all headers should be filled in, although
I would leave the header section out at the moment.

Hope this helps,

Rainer


>
>> I think that is it for the moment - the header arguments section, specifically the language
>> specific one, should possibly be left out as Eric is working on the autocomplete feature, which
>> could possibly be called from the menu as well when implemented?
>
> Eric's take.
>
> Thanks!
>



- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+FPR0ACgkQoYgNqgF2egrpJgCcDu6B6WyKWtos4I5RA04qXqFx
XccAnilifrh3wgKadPJUO6VtIYfBowsh
=SvP2
-----END PGP SIGNATURE-----

Re: layout org-babel menu WAS: About org-babel menu

[Eric Schulte]

Rainer M Krug <r.m.krug@gmail.com> writes:

> On Wed 11 Apr 2012 10:11:01 CEST, Bastien wrote:
>> Hi Rainer,
>>
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>
>>> Thanks Bastien - here is my suggestion and if no objections are raised, I would suggest to
>>> implement it:
>>
>> I don't understand the "..." parts in your example.
>
> e.g. "... all languages supported" means a menu entry should be added
> for each language.
>
> Similar in the "header" menu, all headers should be filled in, although
> I would leave the header section out at the moment.
>
> Hope this helps,
>

There are still ambiguous parts, IMO the following should be fully
explicitly expanded

>  + header arguments
> |  |
> |  + general
> |  |   + export ...
> |  |   + ...

> |  + Show
> |  |    + Header arguments for code block
> |  |    + Header arguments for all code block in buffer
> |  |    + ...

>  + help
> |  |
> |  + Link to info help on header arguments
> |  + Link to info help on how to enable languages
> |  + URL to language specific help on worg
> |  + ...
> |  + ...

Additionally there are more evaluation functions which are not included
in the menu, please ensure that every user-visible function shown by
running `org-babel-describe-bindings' in an Org-mode buffer is included.

The other parts can be expanded using the given variables.

>  + Library of BABEL
> |  |
> |  + ... functions in the library - is this feasible?

Should only be displayed if `org-babel-library-of-babel' is non-nil, and
it's contents may be used to expand the menu option.

> |  + Language specific
> |  |   + R
> |  |   |    + file ...
> |  |   |    + ...
> |  |   |    + ...
> |  |   + Python
> |  |   |    + ...
> |  |   |    + ...
> |  |   |
> |  |   + ...

These may be expanded using the language specific header argument
variables which my latest un-applied patch introduces.  These have names
like `org-babel-header-args:lang'.

Best,

>
> Rainer
>
>
>>
>>> I think that is it for the moment - the header arguments section, specifically the language
>>> specific one, should possibly be left out as Eric is working on the autocomplete feature, which
>>> could possibly be called from the menu as well when implemented?
>>
>> Eric's take.
>>
>> Thanks!
>>
>
>
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :       +33 - (0)9 53 10 27 44
> Cell:       +33 - (0)6 85 62 59 98
> Fax :       +33 - (0)9 58 10 27 44
>
> Fax (D):    +49 - (0)3 21 21 25 22 44
>
> email:      Rainer@krugs.de
>
> Skype:      RMkrug

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: layout org-babel menu WAS: About org-babel menu

[Eric Schulte]

Bastien <bzg@gnu.org> writes:

> Hi Rainer,
>
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> Thanks Bastien - here is my suggestion and if no objections are raised, I would suggest to
>> implement it:
>
> I don't understand the "..." parts in your example.
>

I agree, I think explicitly spelling out all options would make this
example more usable.

>
>> I think that is it for the moment - the header arguments section, specifically the language
>> specific one, should possibly be left out as Eric is working on the autocomplete feature, which
>> could possibly be called from the menu as well when implemented?
>
> Eric's take.
>

I see no problem in duplicating functionality/content between the menu
and the auto completion.  Isn't the whole point of menus to duplicate
functionality for the purpose of clarity?

Best,

>
> Thanks!

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/