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

[Rainer M Krug <r.m.krug@gmail.com>]

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