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.schu...@gmx.com> wrote: > Rainer M Krug <r.m.k...@gmail.com> writes: > >> On 28/03/12 01:07, Bastien wrote: >>> Hi Rainer, >>> >>> Rainer M Krug <r.m.k...@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/ >
