Re: [O] [babel] Producing figures from octave
Ethan Ligon li...@are.berkeley.edu writes: Dan Davison has a brief worg tutorial on using babel with octave at http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-octave-matlab.html Hi Ethan, Amongst other things, he offers the following example block for producing a figure: (Actually, the example is not by me.) #+begin_src octave :output file :file chart.png figure( 1, visible, off ); sombrero; print -dpng chart.png #+end_src :output file is wrong (there's no header arg named :output). :file chart.png says to write the results to that file. The results are whatvever the variable `ans` holds at the end of the block, and I think that must be the file path you're seeing. One way to write that example is: #+begin_src octave :results file figure( 1, visible, off ); sombrero; print -dpng chart.png; ans = chart.png; #+end_src :results file says to interpret the result as a file path. I've updated the worg page. Dan However, rather than delivering the png figure, the file chart.png consists solely of the string /usr/share/octave/packages/3.2. I'm not sure where this string is coming from: it's *not* part of the stuff that octave writes to stdout when the interpreter is invoked (my first guess). I suspect that the options that need to be offered on the #+begin_src line have changed somehow since that worg page was last updated at the end of April of this year, but don't really know. Help! -Ethan
Re: [O] org-icons package
Hi Renzo, org-icons needs to be moved into contrib/, hooked in via a lightweight patch against org.el, instead of being implemented as a monolithic change to org.el. I made a start on that in this branch: https://github.com/dandavison/org-devel/tree/org-icons but I'm not sure that I got very far. Note that that is a branch in a clone of the org repo, as opposed to the org-icons repos which are standalone repos and do not contain org. I thought org-icons was interesting because it offers the possibility of allowing users to make arbitrary superficial changes to org aesthetics. For example, the #+begin_src...#+end_src boilerplate is rather heavy for some peoples' tastes. At one point I had it replacing that with a little (ruby, snake) for (ruby, python) code... But I think it also allows the possibility of overlaying with text. I'd be happy to give you push access to that repo, but, you may as well just fork it as I have no plans to work on it. I don't know how to contact Nicolas. I believe that he is on record as saying he did not plan to develop org-icons further. Good luck, Dan On Thu, Aug 18, 2011 at 1:13 PM, Renzo Been swangdood...@gmail.com wrote: Hi Dan, Nicolas and list, In my previous mail I wrote about using (and upgrading it for use with the latest version of org-mode) Nicolas Girard's org-icons package, see: http://news.gmane.org/find-root.php?group=gmane.emacs.orgmodearticle=44834 I've tried to contact Nicolas Girard (via e-mail and a google search). But I have not heard back from him as yet. When I checked the github for org-icons again I discovered that there was a second branch by Dan Davison. https://github.com/ngirard/org-icons/tree/dan Dan, Do you know how I can get in contact with Nicolas? Or do you have access to the github for org-icons, so that it's code can be updated to work with the latest version of org-mode? Did you and Nicolas ever think about including org-icons into org-mode? As for me, I'm happily using org-icons with org-mode 7.7, I've attached a new and updated patch file that works on the latest org.el Copy the patch org-icons.patch to the directory where you keep your org.el cd to that directory And then apply the patch like this: patch -b org.el org-icons.patch Of-course, if neither of you has the time to work on org-icons... I could make a fork of the git repo, and make the changes myself. However, I do not have much elisp knowledge... Ciao, Renzo On 25 July 2011 12:12, Renzo Been swangdood...@gmail.com wrote: Bastien bzg at altern.org writes: Hi Philipp, Philipp Haselwarter philipp.haselwarter at gmx.de writes: Is there any particular reason for it to be hardcoded? Apart from the fact that /well it just is this way right now/ I mean. Nothing carved in stone, but here are the two reasons I see: - we don't want users to use arbitrary regexp to match headlines as they are very likely to shoot themselves in the foot (Harven's example of using - instead of * is a good example of that.) - Given this, I am not able to imagine a good way of limiting the number of allowed characters. That'd be useful information for anyone interested in changing it. I'd interested in any solution to the problems above. Then you can still just tell them to write a patch if they care that much ('cause even in org-mode-land patches don't write themselves just yet) :) [I just had the most awesome idea for a feature request]. Please share! If it's just about inheriting from a variable in some 300 places it could at least be discussed. Yep -- if you have the energy to go through the code and see where it is hardcoded while it should not, please do. Thanks, Hi, I was just thinking... If you want to change the look of the org-headlines. Does one really need to change the code? I have been using Nicolas Girard's org-icons package for quite a while. And that makes org-buffers look pretty nice. You can even customise the icons, to make it look the way you want. However, some things about the org-icons package... It seems to be a little outdated. Are there many org-moders out there still using it? Were there ever any plans to include it in the org-distribution? Right now it needs to be installed by hand, because the patch to org.el is outdated... Also, I need to load it two times in my .emacs before the icons work... Ciao, Renzo The org-icons can be found here: Download from Nicolas Girard's github http://github.com/ngirard/org-icons On the Worg site I could only find screenshots, no other information... http://orgmode.org/worg/org-screenshots.html The list-message announcement for org-icons http://news.gmane.org/find-root.php?message_id=%3c87zl2962um.fsf%40stats.ox.ac.uk%3e And some list-messages discussing including the org-icons-patch into org-mode http://news.gmane.org/find-root.php?message_id=%3c87zlbx3kvf.fsf
Re: [O] PATCH: New options for latex src code export
Bastien bastien.gue...@wikimedia.fr writes: Hi Dan, Dan Davison dandavis...@gmail.com writes: My questions are 1. It would be nice if users didn't have to worry about step 4. Can anyone suggest a sensible way to have the -shell-escape option passed to pdflatex under the appropriate circumstances? These conditions include: 1. minted is being used for export 2. pdflatex is being used, a.o.t. e.g. rubber or some other latex make tool. A bit hackish, but maybe the attached patch would do? This patch has been applied. So now with the pygments package installed [1] (providing the `pygmentize` executable), minted pdf export of source code requires only #+begin_src emacs-lisp (require 'org-latex) (setq org-export-latex-listings 'minted) (add-to-list 'org-export-latex-packages-alist '( minted)) #+end_src Dan Footnotes: [1] - linux :: apt-get install python-pygments - OSX / linux :: 'pip install pygments' or 'easy_install pygments' diff --git a/lisp/org-latex.el b/lisp/org-latex.el index c558043..f9b2c1c 100644 --- a/lisp/org-latex.el +++ b/lisp/org-latex.el @@ -984,7 +984,13 @@ when PUB-DIR is set, use this as the publishing directory. (file (buffer-file-name lbuf)) (base (file-name-sans-extension (buffer-file-name lbuf))) (pdffile (concat base .pdf)) - (cmds org-latex-to-pdf-process) + (cmds (if (eq org-export-latex-listings 'minted) +;; automatically add -shell-escape when needed +(mapcar (lambda (cmd) + (replace-regexp-in-string + pdflatex pdflatex -shell-escape cmd)) +org-latex-to-pdf-process) + org-latex-to-pdf-process)) (outbuf (get-buffer-create *Org PDF LaTeX Output*)) (bibtex-p (with-current-buffer lbuf (save-excursion
Re: [O] [patch] race condition in org-babel R
Christophe Rhodes cs...@cantab.net writes: Hi, A substantial fraction of times when exporting my org-babel document (with many R session code blocks), I get code block produced no value. I think this is because of a race condition between waiting for the transfer.file to exist and actually populating it with output; the scenario is: 1. write.table() creates its output file 2. emacs notices its existence, and reads it 3. write.table() gets round to writing .Last.value to the file. The attached patch has made exporting much more reliable for me. Thanks, I agree that the race condition seems plausible, and I've applied a slight modification of your patch (the initial evaluation of the object argument looks pointless, but was there to ensure that errors in user code are not smothered by the subsequent exception handling.) Dan Best, Christophe
[O] Re: [Babel] Handling of errors when using Ledger
Hi Eric, Seb and any other ledger users, Is anyone using a version of ledger that does not support reading from stdin with -f - ? Thanks, Dan Eric S Fraga e.fr...@ucl.ac.uk writes: Dan Davison dandavis...@gmail.com writes: [...] Hi Eric, I've asked on the ledger list and the 3.0 (and perhaps some older) versions of ledger do support -f - to read from stdin. Could you try this version of the patch? I was about to say that I could not because the most up to date version on Debian (testing) is 2.6.2 and this version does not support the -f - option. However, I have just noticed that version 3.0.0 is now in Debian experimental. I will have a look to see what kind of repercussions there may be from installing that version on my systems and I will get back to you (but probably not until after xmas...).
[O] Re: [PATCH] Re: [BUG] htmlp and latexp
Bastien b...@altern.org writes: Hi Dan, Dan Davison dandavis...@gmail.com writes: Incidentally, I would suggest that org-current-export-file and org-current-export-dir are renamed so that they are within the org-export-* namespace. Agreed. Please provide a patch if you have time. OK. There are other areas of Org where I think the naming should be standardised, notably in org-src.el: the distinction between org-src-* and org-edit-src-* is unclear IMO. I leave this decision to Erik, this is *his* namespace :) I'm not sure this is Eric's task, git blame lisp/org-src.el | cut -d' ' -f 3 | sort | uniq -c 352 Davison 434 Dominik 3 Guerry 9 Rooke 9 Schulte 5 Sperber but Carsten may have a view. I also want to change the customize group of a lot of those variables: a lot of the org-src-* and org-edit-src-* variables are filed in Customize under Org Structure - Org Edit Structure which has to be one of the least intuitive things in the whole of Org! There's a question of whether we have an Org Src customize group in addition to the Babel customize group, and how we keep them distinct. In fact, that may be what has prevented this from being sorted out thus far. Dan I think this is kind of important, because in learning emacs one does makes use of these namespace conventions, e.g. C-h v initial-letters TAB. I agree. How much change would there be if we demanded that *all* variables defined in org-foo.el are named within the org-foo-* namespace? I don't know. Let's undertake this work progressively. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [O] Let's stick to one list for now
Julien Danjou jul...@danjou.info writes: On Mon, Feb 28 2011, Bastien wrote: The point is that there's no gain in telling people to add [DEV] since they will forget (I will), and there is _no_ lose by splitting a list. I Hi Julien, No, I disagree with that. The two lists would have distinct compositions of the reader audience and that does have downsides. For example, - Those participating in a USER thread cannot rely to the same extent on DEVs listening, or as easily direct comments to DEVs, without messy cross-postings. DEV threads often start life as USER threads; that trajectory would be disrupted. - The probability of pure USERs learning DEV skills is reduced, since they have to actively seek the DEV list. I'm another one who came to Org as a USER with no abilities in elisp programming. Dan already splitted user list in some project and nothing bad happened. :) Julien, I guess your life would be easier if you get push access to the Org repo and an account on the patchwork -- so that you can test patches and improve them if needed. Would that be okay for you? Well, access to the patchwork will at least allow me to contrate and work on dev things that have a patch, for sure. This decision is not carved in stone -- but I'm about to release Org 7.5 and I don't want to undertake a mailing list split in the middle of this process. I understand that. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Org Babel and R issue with pdf latex export
Ben Ward benjamin.w...@bathspa.org writes: Hi, I recently installed emacs, org-mode fresh on a new install of Arch Linux. Before I had it working on Ubuntu. I've installed everything as before and used the same .emacs file I had, but if I use org to write out some R script and export to pdf via latex, then I get an empty pdf document, with only the title and Contents heading. However if I export to anything else such as html it works, and shows me code and results. Hi Ben, Are you sure this problem concerns babel/R? What happens when you export an Org document to pdf without any babel stuff? Can you provide an example Org file that you are having trouble exporting to pdf? The problem is probably in your local configuration, so if no-one can jump to the solution then start from a minimal working config and try to find the part of your .emacs which is causing the problem. Dan I've tried even installing a version of org mode from source, using the build system my distro has, so as it's made and installed to exactly the right place, but I still don't have any luck. The texlive version I'm using is from my distro's package manager. Using C-c C-c to evaluate on the fly works. I had an issue getting org and babel to work with R on Windows 7 as well, but it was because certain tex packages were missing and I recieved a message when I tried to export, but nothing comes up here. Would the recent change: Org-babel is now inside org, remove (require 'org-babel-init) and alike from your .emacs. Look at http://orgmode.org/Changes.html#ob-configuration-changes for overview of the settings. Be causing the entire issue? The .tex file I get out is thus: % Created 2011-02-28 Mon 03:47 \documentclass[11pt]{article} \usepackage[utf8]{inputenc} \usepackage[T1]{fontenc} \usepackage{fixltx2e} \usepackage{graphicx} \usepackage{longtable} \usepackage{float} \usepackage{wrapfig} \usepackage{soul} \usepackage{textcomp} \usepackage{marvosym} \usepackage{wasysym} \usepackage{latexsym} \usepackage{amssymb} \usepackage{hyperref} \tolerance=1000 \providecommand{\alert}[1]{\textbf{#1}} \begin{document} \title{Test} \author{Ben J. Ward} \date{28 February 2011} \maketitle \setcounter{tocdepth}{3} \tableofcontents \vspace*{1cm} \end{document} Thanks, Ben W. (Apologies if this has been sent twice, first time an error occured) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Startup page
Matthew Sauer improv.philoso...@gmail.com writes: As a relatively newer emacs and org-mode user I have found it very interesting to see what people have in their .emacs file. This has spawned my curiosity, what do you have for a startup page? eshell (nevertheless, I do use bash terminals outside emacs much more than eshell) Dan Do you just have it go to the scratch buffer, the standard page or something else? Maybe a custom designed page with links or something else? Might be something interesting to share on worg as well if you have a unique start page for emacs. Just a thought/curiosity as I am working on designing one for my emacs for my use as a student/father/employee. Matthew Sauer ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Re: [BUG] htmlp and latexp
Bastien bastien.gue...@wikimedia.fr writes: Hi Dan, Dan Davison dandavis...@gmail.com writes: I was thinking that if it were defvard in org.el, say as (defvar org-export-current-backend nil) then any code could use (null org-export-current-backend) to test whether org is currently exporting or not. Otherwise, the code has to be certain that it has been called during export if it is going to access the variable. I agree this would be a good idea. If you have time, please send a patch. Otherwise, I just put it [somewhere] in my own todo list... Here's a patch. I note that Eric S pointed out in a separate thread that org-current-export-file can be used for a similar purpose. Incidentally, I would suggest that org-current-export-file and org-current-export-dir are renamed so that they are within the org-export-* namespace. There are other areas of Org where I think the naming should be standardised, notably in org-src.el: the distinction between org-src-* and org-edit-src-* is unclear IMO. I think this is kind of important, because in learning emacs one does makes use of these namespace conventions, e.g. C-h v initial-letters TAB. How much change would there be if we demanded that *all* variables defined in org-foo.el are named within the org-foo-* namespace? Dan commit ac9baa44c7c0baeb8ed3133ed79bc22c4eb6acc7 Author: Dan Davison dandavis...@gmail.com Date: Sun Feb 20 08:55:39 2011 -0800 New variable storing current export backend symbol, or nil. * lisp/org-exp.el (org-export-current-backend): Variable to hold current export backend symbol when export is in progress. (org-export-preprocess-string): Bind `org-export-current-backend' to backend symbols during export. * lisp/org-exp-blocks.el (org-export-blocks-format-ditaa): Dynamically scoped variable `backend' renamed as `org-export-current-backend' (org-export-blocks-format-dot): Dynamically scoped variable `backend' renamed as `org-export-current-backend' (org-export-blocks-format-comment): Dynamically scoped variable `backend' renamed as `org-export-current-backend' * lisp/org-exp.el (org-export-convert-protected-spaces): Dynamically scoped variable `backend' renamed as `org-export-current-backend' * lisp/org-publish.el (org-publish-project-alist): Dynamically scoped variable `backend' renamed as `org-export-current-backend' (org-export-current-backend): Dynamically scoped variable `backend' renamed as `org-export-current-backend' (org-publish-aux-preprocess): Dynamically scoped variable `backend' renamed as `org-export-current-backend' * lisp/org-special-blocks.el (org-export-current-backend): Dynamically scoped variable `backend' renamed as `org-export-current-backend' (org-special-blocks-make-special-cookies): Dynamically scoped variable `backend' renamed as `org-export-current-backend' diff --git a/lisp/org-exp-blocks.el b/lisp/org-exp-blocks.el index 1fac3bf..15549b8 100644 --- a/lisp/org-exp-blocks.el +++ b/lisp/org-exp-blocks.el @@ -242,7 +242,7 @@ passed to the ditaa utility as command line arguments. \n))) (prog1 (cond - ((member backend '(html latex docbook)) + ((member org-export-current-backend '(html latex docbook)) (unless (file-exists-p out-file) (mapc ;; remove old hashed versions of this file (lambda (file) @@ -301,7 +301,7 @@ digraph data_relationships { (out-file (concat (car out-file-parts) _ hash . (cdr out-file-parts (prog1 (cond - ((member backend '(html latex docbook)) + ((member org-export-current-backend '(html latex docbook)) (unless (file-exists-p out-file) (mapc ;; remove old hashed versions of this file (lambda (file) @@ -333,7 +333,7 @@ other backends, it converts the comment into an EXAMPLE segment. (let ((owner (if headers (car headers))) (title (if (cdr headers) (mapconcat 'identity (cdr headers) (cond - ((eq backend 'html) ;; We are exporting to HTML + ((eq org-export-current-backend 'html) ;; We are exporting to HTML (concat #+BEGIN_HTML\n div class=\org-comment\ (if owner (format id=\org-comment-%s\ owner)) diff --git a/lisp/org-exp.el b/lisp/org-exp.el index 9a35b00..e239c25 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -584,6 +584,14 @@ table.el tables. (defconst org-level-max 20) +(defvar org-export-current-backend nil + During export, this will be bound to a symbol such as 'html, + 'latex, 'docbook, 'ascii, etc, indicating which of the export + backends is in use. Otherwise it has the value nil. Users + should not attempt to change the value of this variable + directly, but it can be used in code to test whether export is + in progress, and if so, what the backend is.) + (defvar org-current-export-file nil) ; dynamically scoped parameter (defvar org-current
[Orgmode] Re: Two questions about using a =#+begin_src emacs-lisp= block
Eric Schulte schulte.e...@gmail.com writes: Chris Malone chris.m.mal...@gmail.com writes: Hi, First off, my =org-mode= is up-to-date - just did a =git pull make clean make=. Needless to say, the following were an issue before then... * Question 1: Is there a way to force, upon export, an =emacs-lisp= session to be run within the current buffer? For instance, the following code === #+begin_src emacs-lisp :exports both (buffer-file-name) #+end_src === exports to LaTeX as === \begin{verbatim} (buffer-file-name) \end{verbatim} === In other words, as far as I can tell, the code is passed to the interpreter, which does not know about the current buffer information, and therefore the result of the =emacs-lisp= code is an empty string. By contrast, if I use =C-c C-c= to evaluate the code block, then I get the proper result printed in the =.org= buffer: Hi Chris, This is due to the fact that during export Org-mode copies the entire buffer contents into a new export buffer (which is not associated with any file, hence `buffer-file-name' returning nothing). This is done so that the exporter can operate destructively on the file contents without affecting the original buffer. Ideally this should be an implementation detail that is completely hidden from the user. So I'd say that the fact that execution on export does not behave like interactive execution is a bug. Should we consider fixing this? There is a way to work around this issue. The header arguments to code blocks are calculated in the original buffer (so that things like references will correctly resolve). Given this, the following code block will generate the output you are seeking... #+begin_src emacs-lisp :var file-name=(buffer-file-name) :exports both file-name #+end_src === #+results: : /home/cmalone/org_tests/python_class_lstings.org === Ultimately, I'd like to, upon export, have a =emacs-lisp= code block that does a regexp search on the file and returns a list of matches, which can then be placed in a =latex= code block. This sort of action suffers from the same issue as the =(buffer-file-name)= code - in essence this is a minimal (non)working example. * Question 2: Why does the following code, upon export, ask if I want to evaluate the =emacs-lisp= code *TWICE* and then give a /Invalid read syntax: #/ error in the message window?: === #+begin_src emacs-lisp :exports both (buffer-file-name) #+end_src #+begin_src sh :exports both ls -l #+end_src === Note that this works fine as long as the =:exports= tag for the =emacs-lisp= code block is *NOT* =both= or =results=. Also note that the value of the =:exports= tag on the =sh= code block is irelevant for this error to appear. Also, it doesn't have to be this particular combination of =emacs-lisp= and =sh= blocks; for instance it fails with an =emacs-lisp= and a =python= source block. I can't reproduce this bug, try setting `org-confirm-babel-evaluate' to nil. Best -- Eric Is this a bug? Chris ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Context-sensitive word count in org mode (elisp)
Hi Paul, Sounds useful to me. Is it appropriate to use the existing org function `org-in-regexps-block-p'? Or `org-context'? (Not speaking from any experience of using these functions I just noticed them.) Dan Christian Moe m...@christianmoe.com writes: Hi, This would be really neat to have as a part of org-mode eventually. Another itch scratched. You can probably replace your custom predicate functions with the existing org-at-table-p and org-in-commented-line (works for me). Maybe there's something to replace the latex-macro-regexp too. Yours, Christian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BUG] htmlp and latexp
Christian Moe m...@christianmoe.com writes: On 2/15/11 11:23 PM, Dan Davison wrote: Commit ed6d6760268 removed variables htmlp and latexp from `org-export-preprocess-string'. Nothing wrong with that, but I think it has broken export for those using org-special-blocks Confirmed. Exporting the following example stops with a void-variable error in org-special-blocks-make-special-cookies. I was about to make a temporary fix but I see Bastien's just fixed it. Bastien -- should we give that `backend' variable a name within the org-* namespace (and maybe defvar it in org.el?) so that it is a more respectable way to test for am I doing export now?? (This issue just came up in a separate babel thread). Dan Some text. #+begin_sidebar Some details left out of the main text. #+end_sidebar (Incidentally -- org-special-blocks.el still says it's not currently part of GNU Emacs, but as of Org-mode 7.4 it is, isn't it?) CM ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: A mail client that is org-mode compatible
Mohamed HIBTI mohamed.hi...@gmail.com writes: Hi every one, I would like to move to an emacs mail client that may be org-mode and MIME compatible. Have you any idea ? gnus is an obvious candidate. It can be a bit of a steep learning curve initially. I use it to interact with two different gmail accounts via imap, as well as a few nntp groups, like this one. I'm finding the development version of gnus a pleasure to use for this: it is fast, and there's a very nice search facility both for imap and for nntp groups. (E.g. I used to find it hard to reply in an old thread, but not any longer) As for org compatibility, isolated begin_src fragments are fontified as if they were in org-mode which is very nice (so the languages are fontified correctly if you turn on org-src-fontify-natively). This is thanks to Seb Vauban, and Julien Danjou. Also attached text files are fontified in the correct major mode. I don't really know how it works, but the end result is that often when reading this list in gnus, I see fragments of org-mode markup, and emacs-lisp and other languages, fully fontified in my email. As for MIME, do you know the org-mime-* functions, contributed by Eric Schulte? They work very nicely; I'm looking forward to finding some spare time to work out how best to fit them into my day-to-day emailing. Dan Regards, Mohamed P.S. any configuration stuff is welcome ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BUG] htmlp and latexp
Bastien bastien.gue...@wikimedia.fr writes: Hi Dan, Dan Davison dandavis...@gmail.com writes: I was about to make a temporary fix but I see Bastien's just fixed it. Bastien -- should we give that `backend' variable a name within the org-* namespace (and maybe defvar it in org.el?) so that it is a more respectable way to test for am I doing export now?? (This issue just came up in a separate babel thread). backend is dynamically scoped, so I think there is no need to defvar it in org.el -- only in org-*-blocks.el, to avoid compilation warnings. Let me know if you think otherwise. Hi Bastien, I was thinking that if it were defvard in org.el, say as (defvar org-export-current-backend nil) then any code could use (null org-export-current-backend) to test whether org is currently exporting or not. Otherwise, the code has to be certain that it has been called during export if it is going to access the variable. For example, babel code can get called both during interactive evaluation with C-c C-c, and also during export. It might be helpful for that code to be able to inspect the value of org-export-current-backend to see what the current context is. Dan But it's a good idea to rename it to org-export-backend. Can you do it? ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-babel: Bugs with inline src_* blocks
Paul Sexton psex...@xnet.co.nz writes: Eric Schulte schulte.eric at gmail.com writes: Hi, I agree with your intuition here, but I changed the default inline header argument so that others would be able to use inline code blocks and have the results inserted. To regain the behavior you describe, simply adjust the value of `org-babel-default-inline-header-args' as follows in your .emacs file. #+begin_src emacs-lisp (setf org-babel-default-inline-header-args '((:session . none) (:results . silent) (:exports . results))) #+end_src Thanks Eric. The 'default' behaviour I experienced where inline blocks were inheriting behaviour from elsewhere seems odd however. Hi Paul, Eric, Paul -- I do agree with you. I've had to manually delete unwanted inline src output a few times in the last few days. I think we did have the behaviour we want before -- replacement during export but no modification of the buffer in interactive use. Could we make the default behave so that it does replace during export and silent during normal interactive evaluation? (Or some similar change to ob-exp.el?) Dan Is it intended to work this way? Paul ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Nice python listings colors, or solution to beamer + minted brokenness?
Christopher Allan Webber cweb...@dustycloud.org writes: Hello all, I currently am trying to export something vaguely like this for a presentation in beamer: #+BEGIN_SRC python :exports code class ReferenceDeskPanel(bpy.types.Panel): bl_label = 'Reference Desk' bl_space_type = 'VIEW_3D' bl_region_type = 'TOOLS' def draw(self, context): layout = self.layout row = layout.row() row.prop( context.scene, 'refdesk_search', text=, icon='VIEWZOOM') search_string = context.scene.get('refdesk_search') #+END_SRC I've tried using listings with: #+begin_LaTeX \definecolor{keywords}{RGB}{255,0,90} \definecolor{comments}{RGB}{60,179,113} \lstset{ language=\Python, keywordstyle=\color{keywords}, commentstyle=\color{comments}emph, procnamestyle=\color{blue}\textbf, emphstyle=\color{black}\bfseries, } #+end_LaTeX in my document but I can't figure out how to get the class name (ReferenceDeskPanel) to be highlighted in any form. I've read through the listings manual but I can't find any reference on how to do this. I also tried using minted, but I'm running into the problem discussed in this thread: http://article.gmane.org/gmane.emacs.orgmode/32147/match=minted Hi Christopher, I believe I have just fixed the problem with minted and beamer. Please pull latex org from git and restart emacs, or (setq org-beamer-fragile-re ^[ \t]*begin{\\(verbatim\\|lstlisting\\|minted\\)}) Personally I think that minted will be preferable to listings for your application. Dan I'm at wit's end... I just want to figure out how to syntax highlight my whole python snippet! Any examples of good color sets in listings to use would be *greatly* appreciated! Or a solution to that minted + beamer problem! Either one! Super, ultra thanks in advance, - cwebb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Nice python listings colors, or solution to beamer + minted brokenness?
Christopher Allan Webber cweb...@dustycloud.org writes: Dan Davison dandavis...@gmail.com writes: Hi Christopher, I believe I have just fixed the problem with minted and beamer. Please pull latex org from git and restart emacs, or ^^^ Oops, I meant to write latest org. I.e. just pull as normal. (setq org-beamer-fragile-re ^[ \t]*begin{\\(verbatim\\|lstlisting\\|minted\\)}) Personally I think that minted will be preferable to listings for your application. Dan Dan: It works! That looks *fantastic.* Great. If you want to play around with styles, you can use a line like #+latex_header: \usemintedstyle{tango} To see all the available styles, use the command pygmentize -L styles (my output is below) Also, if you'd like to experiment with the different options for the \begin{minted} environment, and if you're comfortable switching between git branches, then try the branch minted of the main org git repo, and look at the variable `org-export-latex-minted-options'. For example (setq org-export-latex-minted-options '((frame lines))) puts a frame around the src block. Of course, see minted.pdf for the options. Dan $ pygmentize -L styles Pygments version 1.4, (c) 2006-2008 by Georg Brandl. Styles: ~~~ * monokai: This style mimics the Monokai color scheme. * manni: A colorful style, inspired by the terminal highlighting style. * perldoc: Style similar to the style used in the perldoc code blocks. * borland: Style similar to the style used in the borland IDEs. * colorful: A colorful style, inspired by CodeRay. * default: The default style (inspired by Emacs 22). * murphy: Murphy's style from CodeRay. * vs: * trac: Port of the default trac highlighter design. * tango: The Crunchy default Style inspired from the color palette from the Tango Icon Theme Guidelines. * fruity: Pygments version of the native vim theme. * autumn: A colorful style, inspired by the terminal highlighting style. * bw: * emacs: The default style (inspired by Emacs 22). * vim: Styles somewhat like vim 7.0 * pastie: Style similar to the pastie default style. * friendly: A modern style based on the VIM pyte theme. * native: Pygments version of the native vim theme. Thank you *so* much! :D :D :D - cwebb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Feature request] org-backup
Marcelo de Moraes Serpa celose...@gmail.com writes: Hi Dan, I don't think I understood -- AFAIK, git repos are per directory and I can't add something from another directory to it ? Hi Marcelo, Let's say the base directory of a git repo is the one in which you issued git init and which contains a hidden .git subdirectory. You can add files from anywhere in the directory tree rooted at the base directory. In other words, if you make a git repo in your home directory cd ~ git init you can add files from any subdirectory of your home directory. Just an idea. Dan Symlinking could be a possibility, like keeping everything inside ~/org and symlink to another dirs. Cheers, Marcelo. On Mon, Feb 14, 2011 at 6:38 AM, Dan Davison dandavis...@gmail.com wrote: Marcelo de Moraes Serpa celose...@gmail.com writes: Hi Dan! I already do this, but sometimes the files are spread around *many* directories. I.e, the model of having everything in a version-controlled directory is unpractical, so that's why I think it would be useful. A couple of possibilities: A git repo doesn't have to be limited to a single directory. You could have a git repo in your home directory, and git add org files, wherever they may be located using a command something like find . -type f -name '*.org' -exec git add '{}' \; You could use symlinks where posible, so that your org files are all in one directory, and project directories contain symlinks to those org files. Dan Marcelo. On Sun, Feb 13, 2011 at 3:49 PM, Dan Davison dandavis...@gmail.com wrote: Marcelo de Moraes Serpa celose...@gmail.com writes: Hi list, Although I try to keep all my org files inside a ~/org directory, I often find myself creating org files outside of this directory context, for example, as a bucket for a new project I'm working on, to keep notes, todos, etc. It'd be nice if we had a org-backup function that would fetch all files from the agenda + linked files and create a compressed backup of them. What do you think? Hi Marcelo, I think backing up text files is a job for other tools; not emacs. I'd recommend using a version control tool such as git for this. Dan Cheers, Marcelo. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Something like SETUPFILE, but in .emacs?
Gary Oberbrunner ga...@oberbrunner.com writes: On Sun, Feb 13, 2011 at 10:53 AM, Darlan Cavalcante Moreira darc...@gmail.com wrote: You can use auto-insert for this. I guess I'm really not using org-mode in the way it was intended -- everyone thinks I should put these values into each one of my org-mode files. Hi Gary, What did you think of the suggestion I made? http://article.gmane.org/gmane.emacs.orgmode/37408 I believe it pointed you in the right direction. You need to (a) find the variables that control the export behavior in question, and (b) set those variables in your .emacs. My reply gave a source of many of the relevant variables, i.e. the default value of the variable `org-export-plist-vars'. An example of one of those variables is [...] As an example, I *never* want to export the creator line. `org-export-creator-info'. Let us know if you have trouble finding the appropriate variable for something, or if setting the variables isn't behaving the way you want. Dan But most of the comments on this list seem to say I should modify my .org files (at least to include #+SETUPFILE), so I guess I'll consider that as standard practice. Would anyone be interested if I were to create a way to specify export values in a global file somewhere (~/.org-site-defaults or something) in the same syntax as SETUPFILE (#+kwd: value) that would set up all the defaults for _every_ org file? ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] unset :var definitions for subtree
Eric Schulte schulte.e...@gmail.com writes: [...] Maybe we could extend the :var header argument to support the following syntax... #+begin_src emacs-lisp :var A=1 B=3 ;; code #+end_src or ** two vars in a properties block :PROPERTIES: :var: test1=7 test2=8 :END: That shouldn't be overly difficult, and should solve our requirements. Yes, that looks good. In the following Org file --- #+property: :var a=1 b=2 * h1 :PROPERTIES: :var: c=3 :END: ** h11 :PROPERTIES: :var: d=4 e=5 b=7 :END: #+begin_src sh :var f=6 # code here #+end_src --- if we follow programming languages by analogy then the behavior we should aim for is for variables a,b,c,d,e to all be set in the src block, with b having the value 7. I've made a start on a patch to do that -- it involves treating :var differently from other header args. Whereas normal property inheritance searches up the tree until the specified property is encountered, my patch searches up the tree to the root, collecting all the :var assignments encountered. Maybe we should do this sort of exhaustive search for *all* header argument types. Are there any header arguments aside from :var which could possibly want to take multiple values collected at different levels of inheritance? I suppose :results may also take multiple values which could reasonably be collected across multiple levels of hierarchy. So perhaps we should go for a solution involving both the new :var a=1 b=2 syntax (to allow multiple :var in the same block), and the pluralistic inheritance described above (to allow :var to be collected from all levels in the hierarchy). That sounds good to me. Is this code up in a repository somewhere, or should be send patches back and forth? This is in branch ob-inherit at https://github.com/dandavison/org-devel. I've given you write access to the repo. The branch isn't ready to go yet, just a first pass. Currently, with this file - #+property: var a=1 #+property: var b=2 * h1 :PROPERTIES: :var: c=3 :END: ** h11 :PROPERTIES: :var: b=4 :END: #+begin_src sh :var d=5 # code here #+end_src - C-c C-v C-v in the src block gives - c=3 a=1 b=2 d=5 # code here - (so b has the wrong value, but there will be more issues than just that) Dan Best -- Eric Dan Sound good? -- Eric ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Help with Babel and using SQL
yesare email@gmail.com writes: Thanks. I opened up ob-sql.el and read the code to see if I can figure it out. I think I have answered my first question. I wrote the following and hit C-c C-c and I got the result set back. #+srcname: sampsql #+begin_src sql :engine mysql :cmdline -h hostname -u username -pmypass -D dbname select * from tablename; #+end_src regarding my 2nd question (reading orgtables), I am thinking that one can't read orgtables in the same way as you read a db table. But you can use an org table to extract data snippets to pass as variables to a sql or build a dynamic sql. Is my understanding correct? I'm not sure yet. Could you give a concrete example of something that you think is not possible? Then it shouldn't be too hard for us to say whether it is or isn't possible. I was also experimenting on passing variables. I modified the above example as shown below but I did not get any results I'm not the best person to help here (Eric Schulte and Seb Vauban would know more about using babel with sql) but your example does seem to work to me. If I put point on the block and issue C-c C-v C-v (org-babel-expand-src-block), then I see select * from tablename; but if I get rid of the :var then I see select * from $table; demonstrating that the :var substitution has been performed What do you get when you expand the block? Dan #+srcname: sampsql #+begin_src sql :engine mysql :cmdline -h hostname -u username -pmypass -D dbname :var table=tablename select * from $table; #+end_src On Sun, Feb 13, 2011 at 3:08 AM, Bastien bastien.gue...@wikimedia.frwrote: Hi Yesare, I'm not familiar enough with Babel to give you useful guidance, but others on the list may help you. yesare email@gmail.com writes: I am trying to do two things. 1. Query a mysql or oracle table and post results in orgtable format 2. Select data from an existing orgtable in current buffer and do further processing with them (example: insert them into Oracle). I am sorry if this is vague but I am just looking for some initial guidance on how to get around. Can you post the code your tried? What you expected? What happened instead? This will help people to know where and why you're stuck. Thanks! -- Bastien ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Allow property retrieval before first heading?
Currently (org-entry-get) throws an error if point is before the first heading. Is there a reason that this must be so? Org is too essential for headings to be obligatory! An example of when it would be useful to get properties is in a buffer containing src blocks but no headings (babel takes header args from Org properties). I make heavy use of such buffers as a scratch pad. I'm not sure to what extent speed is essential in these functions, and therefore unsure whether the calls to `org-before-first-heading-p' are acceptable. Dan Allow properties to be retrieved before first heading in file. * lisp/org.el (org-entry-get): Don't look for a property drawer if we are before the first heading in the file. (org-entry-get-with-inheritance): Don't attempt to move up the tree if we are before the first heading in the file. Also, enclose less of the function in the save-excursion. diff --git a/lisp/org.el b/lisp/org.el index 0104007..a676ec4 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13567,7 +13567,8 @@ when a \nil\ value can supersede a non-nil value higher up the hierarchy. ;; We need a special property. Use `org-entry-properties' to ;; retrieve it, but specify the wanted property (cdr (assoc property (org-entry-properties nil 'special property))) - (let ((range (org-get-property-block))) + (let ((range (unless (org-before-first-heading-p) + (org-get-property-block (if (and range (goto-char (car range)) (re-search-forward @@ -13680,6 +13681,7 @@ should be considered as undefined (this is the meaning of nil here). However, if LITERAL-NIL is set, return the string value \nil\ instead. (move-marker org-entry-property-inherited-from nil) (let (tmp) +(unless (org-before-first-heading-p) (save-excursion (save-restriction (widen) @@ -13690,11 +13692,12 @@ However, if LITERAL-NIL is set, return the string value \nil\ instead. (move-marker org-entry-property-inherited-from (point)) (throw 'ex tmp)) (or (org-up-heading-safe) (throw 'ex nil) + )) (setq tmp (or tmp (cdr (assoc property org-file-properties)) (cdr (assoc property org-global-properties)) (cdr (assoc property org-global-properties-fixed - (if literal-nil tmp (org-not-nil tmp) + (if literal-nil tmp (org-not-nil tmp (defvar org-property-changed-functions nil Hook called when the value of a property has changed. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] Allow property retrieval before first heading?
Dan Davison dandavis...@gmail.com writes: Currently (org-entry-get) throws an error if point is before the first heading. Is there a reason that this must be so? Org is too essential for headings to be obligatory! An example of when it would be useful to get properties is in a buffer containing src blocks but no headings (babel takes header args from Org properties). Hmm, for the record I was confused on that point; Eric already has a workaround for the error to the effect that babel will take header args from a #+PROPERTY line in a buffer with no headings. But my question stands, as this error is a gotcha, requiring code like this (or (condition-case nil (org-entry-get (point) header-arg t) (error nil)) (cdr (assoc header-arg org-file-properties Dan I make heavy use of such buffers as a scratch pad. I'm not sure to what extent speed is essential in these functions, and therefore unsure whether the calls to `org-before-first-heading-p' are acceptable. Dan Allow properties to be retrieved before first heading in file. * lisp/org.el (org-entry-get): Don't look for a property drawer if we are before the first heading in the file. (org-entry-get-with-inheritance): Don't attempt to move up the tree if we are before the first heading in the file. Also, enclose less of the function in the save-excursion. diff --git a/lisp/org.el b/lisp/org.el index 0104007..a676ec4 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13567,7 +13567,8 @@ when a \nil\ value can supersede a non-nil value higher up the hierarchy. ;; We need a special property. Use `org-entry-properties' to ;; retrieve it, but specify the wanted property (cdr (assoc property (org-entry-properties nil 'special property))) - (let ((range (org-get-property-block))) + (let ((range (unless (org-before-first-heading-p) +(org-get-property-block (if (and range (goto-char (car range)) (re-search-forward @@ -13680,6 +13681,7 @@ should be considered as undefined (this is the meaning of nil here). However, if LITERAL-NIL is set, return the string value \nil\ instead. (move-marker org-entry-property-inherited-from nil) (let (tmp) +(unless (org-before-first-heading-p) (save-excursion (save-restriction (widen) @@ -13690,11 +13692,12 @@ However, if LITERAL-NIL is set, return the string value \nil\ instead. (move-marker org-entry-property-inherited-from (point)) (throw 'ex tmp)) (or (org-up-heading-safe) (throw 'ex nil) + )) (setq tmp (or tmp (cdr (assoc property org-file-properties)) (cdr (assoc property org-global-properties)) (cdr (assoc property org-global-properties-fixed - (if literal-nil tmp (org-not-nil tmp) + (if literal-nil tmp (org-not-nil tmp (defvar org-property-changed-functions nil Hook called when the value of a property has changed. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel][R] buffer-wide and code block specific use of :session
Bernd Weiss bernd.we...@uni-koeln.de writes: Org-mode version 7.4 (release_7.4.348.g6132) Dear all, I am preparing a document which contains text and R code/output. In particular, I'd like to print out a (correlation) matrix. This is my org-mode document (I intentionally have two code blocks): #-- #+ Does not work #+BABEL: :session *R* #+BEGIN_SRC R :results silent :tangle simcorrdata.R cormat - c(1.0, 0.2, 0.4, 0.2, 1.0, -0.3, 0.4, -0.3, 1.0) cormat - matrix(cormat, ncol = 3, byrow = TRUE) #+END_SRC So, the correlation matrix looks as follows: #+BEGIN_SRC R :exports both :tangle simcorrdata.R print(cormat) #+END_SRC #-- Since I have two code blocks, I need to use :session. If I define :session buffer-wide as #+BABEL: :session *R* then the matrix cormat is unknown within the second code block (object 'cormat' not found). However, if I specify :session for each code block seperately then it works as expected. Hi Bernd, The above does work for me. Some things to check: 1. After altering the #+BABEL line, it's necessary to refresh Org's file-local options, for example with C-c C-c on the #+BABEL line. (Same is true for #+OPTIONS, #+PROPERTY, etc) 2. I've just fixed a bug which was causing it to fail to work on the first attempt... But it did work on second and subsequent attempts. Please note that it is possible to make an equivalent setting using #+PROPERTY: session *R* In fact, I suspect we are going to drop #+BABEL entirely, so please consider it deprecated and use this form instead. After evaluating the first block, an ESS R buffer named *R* should exist, in which the variable cormat should be defined. Let me know if your problem persists. Dan #-- #+ Does work #+BEGIN_SRC R :session :results silent :tangle simcorrdata.R cormat - c(1.0, 0.2, 0.4, 0.2, 1.0, -0.3, 0.4, -0.3, 1.0) cormat - matrix(cormat, ncol = 3, byrow = TRUE) #+END_SRC So, the correlation matrix looks as follows: #+BEGIN_SRC R :session :exports both :tangle simcorrdata.R print(cormat) #+END_SRC #-- Does this happen due to my poor understanding of the :session argument? Or is this a bug? Thanks for your help, Bernd ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] unset :var definitions for subtree
Eric Schulte schulte.e...@gmail.com writes: [...] It seems that what you want to do can be described as disabling inheritance of the :var properties for a specific block. Agreed - that would solve my problem. So I'm suggesting that it may be more parsimonious to do this with the existing Org inheritance mechanisms than to introduce new babel header arguments specifically for this purpose. Agreed here. If this is possible, then I'm all for it, however I do not think that it is currently possible to disinherit specific properties. Note: do to the way babel collects properties, I don't think that temporarily changing the value of `org-use-property-inheritance' will be sufficient. [...] So how can I now define multiple variables? I don't know :) Could Eric help here? in a properties drawer multiple :var does not work? Could you give a simple example how to define variables A and B? Yes, I've always been a bit uncomfortable with this. As Eric says, Org properties are supposed to be a bit like a hash, with unique keys. So based on this, I can only define a single variable per properties drawer? I'm not sure how this should be solved. Would it be possible/desirable to allow multiple settings of the same key in Org-mode properties? That seems like it could be a destructive change across all of Org-mode. Maybe we could extend the :var header argument to support the following syntax... #+begin_src emacs-lisp :var A=1 B=3 ;; code #+end_src or ** two vars in a properties block :PROPERTIES: :var: test1=7 test2=8 :END: That shouldn't be overly difficult, and should solve our requirements. Yes, that looks good. In the following Org file --- #+property: :var a=1 b=2 * h1 :PROPERTIES: :var: c=3 :END: ** h11 :PROPERTIES: :var: d=4 e=5 b=7 :END: #+begin_src sh :var f=6 # code here #+end_src --- if we follow programming languages by analogy then the behavior we should aim for is for variables a,b,c,d,e to all be set in the src block, with b having the value 7. I've made a start on a patch to do that -- it involves treating :var differently from other header args. Whereas normal property inheritance searches up the tree until the specified property is encountered, my patch searches up the tree to the root, collecting all the :var assignments encountered. So perhaps we should go for a solution involving both the new :var a=1 b=2 syntax (to allow multiple :var in the same block), and the pluralistic inheritance described above (to allow :var to be collected from all levels in the hierarchy). Dan Sound good? -- Eric ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] unset :var definitions for subtree
Eric Schulte schulte.e...@gmail.com writes: [...] I agree, the things I was talking about don't end up being simpler in terms of usage for this case. My thinking was that variable unsetting might be something that would be required fairly rarely, and so it might be worth appropriate to support it as part of a more general/powerful mechanism tied into Org properties, or even that hook. It does sound like if there were a way to disable inheritance for certain properties for certain sub-trees of a document, then that would be ideal -- although I can't imagine how such functionality would be implemented. Can we think of an Org-wide syntax for disinheriting specific properties? I'm not sure whether or how this fits it, but it's worth noting that Org currently documents the following , | org-entry-get-with-inheritance is a Lisp function in `org.el'. | | (org-entry-get-with-inheritance PROPERTY optional LITERAL-NIL) | | Get entry property, and search higher levels if not present. | The search will stop at the first ancestor which has the property defined. | If the value found is nil, return nil to show that the property | should be considered as undefined (this is the meaning of nil here). | However, if LITERAL-NIL is set, return the string value nil instead. ` so that seems to suggest :var nil as a way of knocking out all :var assignments, but doesn't immediately suggest how to knock out on a per-variable basis. :var a=nil ? (Which otherwise would look for a src block named nil) Before we proceed with the variable unsetting, could someone provide a motivating example, just to convince ourselves that the extra features are justified? (The conclusion of another message was that the torque script example was more a motivating example for shebang/preamble processing than for variable unsetting.) Certainly. 1. taking Rainer's first example, lets say that you want a variable specified for all but one code block in a file (maybe that one code block is the source of the value of the variable). In this case it would be much simpler to specify the variable file-wide, and then unset the variable for that one code block. Agreed. It's not clean, but currently in this situation one could just set the offending variable to some other value. 2. say you want the same session for /nearly/ every code block in a file. 3. same for :dir, :file, or :shebang... I'd just note that some of these already have natural values that can be used to unset :session none :dir . :shebang :file not sure about this one, but maybe none should be used... Dan So, in summary, I am all for a general org-mode wide solution for disinheriting specific properties, however, if we are unable to find such a solution then I would lean towards implementing this for Babel specifically. Best -- Eric ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] unset :var definitions for subtree
Rainer M Krug r.m.k...@gmail.com writes: On 02/10/2011 05:48 PM, Eric Schulte wrote: Rainer M Krug r.m.k...@gmail.com writes: On 02/10/2011 02:27 AM, Eric Schulte wrote: Rainer M Krug r.m.k...@gmail.com writes: Hi For one project, I am usinr org to write submit scripte to a cluster runing torqu. The important bit in this is, that between the shebang and the code, no other executable line must occur. As I am using variables in org (:var) they will occur just after the shebang, which causes a problem for torque. So, my question is, is there a way to unset variables defined by using :var for a subtree? Hi Rainer, Interesting question... unfortunately I don't think that removing variables from header arguments is possible under the current setup. Perhaps in your case you could add a function to the post-tangle hook, which recognizes when it is being called in a just-tangled torqu script (maybe by searching for a series of #PBS lines), and then removes any lines between the shebang and the first #PBS line? That is also an option - what I am using at the moment is to use :no-expand as a code block specific header argument. But this raises the other question: Can I set the :no-expand in a properties block? As far as I understand, in the properties block I have the argument and the value - but what do I do with :noexpand? :PROPERTIES: :var: A=13 :no-expand :END: You can just set it to yes or really any value you like (the value will be ignored). I did however have to add no-expand to the list of header argument names searched for in property blocks -- I just pushed up a patch to this effect. Thanks - I'll try it today and come back if it does not work. More generally, I wonder what a natural method would be to allow unsetting of pre-set header arguments for local blocks or subtrees? This may only apply to the :var header argument, as most others have a default setting which can be actively set. If you have any ideas for a natural syntax for such an operation I'd be happy to hear it. First solution (probably the easiest to implement) would be along the lines of the :no-expand header argument - :expand-var yes and :expand-var no This could possibly be expanded to :expand-var A B C which would expand only the variables A B and C One step further: one could define groups of variables, like :var-group X=A,B,C or a similar syntax and then :expand-var X would expand A B and C This all would not be real unset - but a possibility for unsetting would be :var B= or :var-unset B i.e. if no value is specified in :var, the variable will be removed (i.e. unset) - one could also use a null value (if it exists in elisp): :var B=(null) Thanks for the ideas, I think you're right that something along the lines of the above should be the easiest to implement, however after reading these suggestions, I'm thinking that more generally there are a couple of other header arguments which could need to be unset, namely - file - dir - session - shebang some of these (like session) accept a none value which has the effect of un-setting the header argument. True - haven't thought about those (and did not know about :dir useful one!). And the :session might definitely come in handy - I have cases, where I reset it manually before evaluating certain sections of the block. It would be nice to generalize whatever solution we apply across all types of header argument (both for implementation and for user simplicity). Absolutely - coherent solutions are definitely the best. The simplest option would probably be to ensure that setting any header argument to :none would remove all instances of that header argument. Agreed - makes perfect sense. But probably for readibility use something like: : header :remove() or :header :remove The only problem there is cases like var, where you might not want to remove all :var's. Maybe this could be expanded s.t. :none could take arguments, e.g. :header :none(A, B) which would remove all instances of the header header argument whose value is or is named A or B? I would stick to the name of the variable - that is more consistent. But instead of :none() I would suggest :remove : :header :remove(A, B) and if one wants to remove all variables with *value A*, one could use :header :remove(A) Or does that look too funky? No - I like it. I'm concerned that all this is looking rather complex. And I'm a bit dubious about the :xxx syntax -- those should correspond to keys in an association list. Could we step back a moment -- would someone mind giving me a concrete example of a problem whose solution requires these new features? For consistency, one could also have a function :set() which could be used as follow: :header :set(A=12, B=13) to set the header header argument A to 12 and B to 13. And then probably use :unset instead of :remove? Just
[Orgmode] Re: [BABEL] unset :var definitions for subtree
Rainer M Krug r.m.k...@gmail.com writes: On 02/11/2011 10:32 AM, Dan Davison wrote: Rainer M Krug r.m.k...@gmail.com writes: On 02/10/2011 05:48 PM, Eric Schulte wrote: Rainer M Krug r.m.k...@gmail.com writes: On 02/10/2011 02:27 AM, Eric Schulte wrote: Rainer M Krug r.m.k...@gmail.com writes: Hi For one project, I am usinr org to write submit scripte to a cluster runing torqu. The important bit in this is, that between the shebang and the code, no other executable line must occur. As I am using variables in org (:var) they will occur just after the shebang, which causes a problem for torque. So, my question is, is there a way to unset variables defined by using :var for a subtree? Hi Rainer, Interesting question... unfortunately I don't think that removing variables from header arguments is possible under the current setup. Perhaps in your case you could add a function to the post-tangle hook, which recognizes when it is being called in a just-tangled torqu script (maybe by searching for a series of #PBS lines), and then removes any lines between the shebang and the first #PBS line? That is also an option - what I am using at the moment is to use :no-expand as a code block specific header argument. But this raises the other question: Can I set the :no-expand in a properties block? As far as I understand, in the properties block I have the argument and the value - but what do I do with :noexpand? :PROPERTIES: :var: A=13 :no-expand :END: You can just set it to yes or really any value you like (the value will be ignored). I did however have to add no-expand to the list of header argument names searched for in property blocks -- I just pushed up a patch to this effect. Thanks - I'll try it today and come back if it does not work. More generally, I wonder what a natural method would be to allow unsetting of pre-set header arguments for local blocks or subtrees? This may only apply to the :var header argument, as most others have a default setting which can be actively set. If you have any ideas for a natural syntax for such an operation I'd be happy to hear it. First solution (probably the easiest to implement) would be along the lines of the :no-expand header argument - :expand-var yes and :expand-var no This could possibly be expanded to :expand-var A B C which would expand only the variables A B and C One step further: one could define groups of variables, like :var-group X=A,B,C or a similar syntax and then :expand-var X would expand A B and C This all would not be real unset - but a possibility for unsetting would be :var B= or :var-unset B i.e. if no value is specified in :var, the variable will be removed (i.e. unset) - one could also use a null value (if it exists in elisp): :var B=(null) Thanks for the ideas, I think you're right that something along the lines of the above should be the easiest to implement, however after reading these suggestions, I'm thinking that more generally there are a couple of other header arguments which could need to be unset, namely - file - dir - session - shebang some of these (like session) accept a none value which has the effect of un-setting the header argument. True - haven't thought about those (and did not know about :dir useful one!). And the :session might definitely come in handy - I have cases, where I reset it manually before evaluating certain sections of the block. It would be nice to generalize whatever solution we apply across all types of header argument (both for implementation and for user simplicity). Absolutely - coherent solutions are definitely the best. The simplest option would probably be to ensure that setting any header argument to :none would remove all instances of that header argument. Agreed - makes perfect sense. But probably for readibility use something like: : header :remove() or :header :remove The only problem there is cases like var, where you might not want to remove all :var's. Maybe this could be expanded s.t. :none could take arguments, e.g. :header :none(A, B) which would remove all instances of the header header argument whose value is or is named A or B? I would stick to the name of the variable - that is more consistent. But instead of :none() I would suggest :remove : :header :remove(A, B) and if one wants to remove all variables with *value A*, one could use :header :remove(A) Or does that look too funky? No - I like it. I'm concerned that all this is looking rather complex. And I'm a bit dubious about the :xxx syntax -- those should correspond to keys in an association list. Could we step back a moment -- would someone mind giving me a concrete example of a problem whose solution requires these new features? Hi Rainer, Here is my situation: I am using org-babel to write analysis for a cluster environment, which uses torque. To make my scripts flexible
[Orgmode] Re: [BABEL] unset :var definitions for subtree
Eric Schulte schulte.e...@gmail.com writes: Rainer M Krug r.m.k...@gmail.com writes: On 02/10/2011 02:27 AM, Eric Schulte wrote: Rainer M Krug r.m.k...@gmail.com writes: Hi For one project, I am usinr org to write submit scripte to a cluster runing torqu. The important bit in this is, that between the shebang and the code, no other executable line must occur. As I am using variables in org (:var) they will occur just after the shebang, which causes a problem for torque. So, my question is, is there a way to unset variables defined by using :var for a subtree? Hi Rainer, Interesting question... unfortunately I don't think that removing variables from header arguments is possible under the current setup. Perhaps in your case you could add a function to the post-tangle hook, which recognizes when it is being called in a just-tangled torqu script (maybe by searching for a series of #PBS lines), and then removes any lines between the shebang and the first #PBS line? That is also an option - what I am using at the moment is to use :no-expand as a code block specific header argument. But this raises the other question: Can I set the :no-expand in a properties block? As far as I understand, in the properties block I have the argument and the value - but what do I do with :noexpand? :PROPERTIES: :var: A=13 :no-expand :END: You can just set it to yes or really any value you like (the value will be ignored). I did however have to add no-expand to the list of header argument names searched for in property blocks -- I just pushed up a patch to this effect. More generally, I wonder what a natural method would be to allow unsetting of pre-set header arguments for local blocks or subtrees? This may only apply to the :var header argument, as most others have a default setting which can be actively set. If you have any ideas for a natural syntax for such an operation I'd be happy to hear it. First solution (probably the easiest to implement) would be along the lines of the :no-expand header argument - :expand-var yes and :expand-var no This could possibly be expanded to :expand-var A B C which would expand only the variables A B and C One step further: one could define groups of variables, like :var-group X=A,B,C or a similar syntax and then :expand-var X would expand A B and C This all would not be real unset - but a possibility for unsetting would be :var B= or :var-unset B i.e. if no value is specified in :var, the variable will be removed (i.e. unset) - one could also use a null value (if it exists in elisp): :var B=(null) Thanks for the ideas, I think you're right that something along the lines of the above should be the easiest to implement, however after reading these suggestions, I'm thinking that more generally there are a couple of other header arguments which could need to be unset, namely - file - dir - session - shebang some of these (like session) accept a none value which has the effect of un-setting the header argument. It would be nice to generalize whatever solution we apply across all types of header argument (both for implementation and for user simplicity). Some half thought-through suggestions. Sorry if this is a bit disorganized. I wonder whether we should be using Org property inheritance here. If it were possible to turn off property inheritance temporarily for the execution of the block, then it could be prevented from inheriting the header args that you don't want it to inherit. Perhaps babel could offer a :bind header argument, which specifies the values of lisp variables in a let-binding which encloses the src block execution? #+header: :bind org-babel-use-property-inheritance nil #+begin_src sh :tangle script.sh :shebang #!/bin/bash #$ -cwd #+end_src with a patch along these lines +(defvar org-babel-use-property-inheritance t + When looking for org-babel header arguments in in-buffer + properties, this variable is passed as the INHERIT argument to + the function `org-enrty-get') + (defvar org-file-properties) (defun org-babel-params-from-properties (optional lang) Retrieve parameters specified as properties. @@ -864,7 +870,7 @@ may be specified in the properties of the current outline entry. (lambda (header-arg) (and (setq val (or (condition-case nil - (org-entry-get (point) header-arg t) + (org-entry-get (point) header-arg org-babel-use-property-inheritance) (error nil)) (cdr (assoc header-arg org-file-properties (cons (intern (concat : header-arg)) In fact, that might be more widely useful in Org -- it would offer a sort of 'subtree local variables', as an analog of buffer local variables. Like any other babel variable, BIND could be set in a property drawer, but perhaps
[Orgmode] Re: [BABEL] unset :var definitions for subtree
Rainer M Krug r.m.k...@gmail.com writes: On 02/11/2011 01:19 PM, Dan Davison wrote: Eric Schulte schulte.e...@gmail.com writes: Rainer M Krug r.m.k...@gmail.com writes: On 02/10/2011 02:27 AM, Eric Schulte wrote: Rainer M Krug r.m.k...@gmail.com writes: Hi For one project, I am usinr org to write submit scripte to a cluster runing torqu. The important bit in this is, that between the shebang and the code, no other executable line must occur. As I am using variables in org (:var) they will occur just after the shebang, which causes a problem for torque. So, my question is, is there a way to unset variables defined by using :var for a subtree? Hi Rainer, Interesting question... unfortunately I don't think that removing variables from header arguments is possible under the current setup. Perhaps in your case you could add a function to the post-tangle hook, which recognizes when it is being called in a just-tangled torqu script (maybe by searching for a series of #PBS lines), and then removes any lines between the shebang and the first #PBS line? That is also an option - what I am using at the moment is to use :no-expand as a code block specific header argument. But this raises the other question: Can I set the :no-expand in a properties block? As far as I understand, in the properties block I have the argument and the value - but what do I do with :noexpand? :PROPERTIES: :var: A=13 :no-expand :END: You can just set it to yes or really any value you like (the value will be ignored). I did however have to add no-expand to the list of header argument names searched for in property blocks -- I just pushed up a patch to this effect. More generally, I wonder what a natural method would be to allow unsetting of pre-set header arguments for local blocks or subtrees? This may only apply to the :var header argument, as most others have a default setting which can be actively set. If you have any ideas for a natural syntax for such an operation I'd be happy to hear it. First solution (probably the easiest to implement) would be along the lines of the :no-expand header argument - :expand-var yes and :expand-var no This could possibly be expanded to :expand-var A B C which would expand only the variables A B and C One step further: one could define groups of variables, like :var-group X=A,B,C or a similar syntax and then :expand-var X would expand A B and C This all would not be real unset - but a possibility for unsetting would be :var B= or :var-unset B i.e. if no value is specified in :var, the variable will be removed (i.e. unset) - one could also use a null value (if it exists in elisp): :var B=(null) Thanks for the ideas, I think you're right that something along the lines of the above should be the easiest to implement, however after reading these suggestions, I'm thinking that more generally there are a couple of other header arguments which could need to be unset, namely - file - dir - session - shebang some of these (like session) accept a none value which has the effect of un-setting the header argument. It would be nice to generalize whatever solution we apply across all types of header argument (both for implementation and for user simplicity). Some half thought-through suggestions. Sorry if this is a bit disorganized. I wonder whether we should be using Org property inheritance here. If it were possible to turn off property inheritance temporarily for the execution of the block, then it could be prevented from inheriting the header args that you don't want it to inherit. Perhaps babel could offer a :bind header argument, which specifies the values of lisp variables in a let-binding which encloses the src block execution? The whole logic in org is that, if I understand correctly, of the smaller unit (e.g. file - subtree - ... - code block) inheriting properties, variables, ... from the next larger unit - introducing a possibility to disable inheritance, would introduce a completely new level of complexity. I think that one should rather introduce a way of unsetting e.g. variable values to have the same effect, but still sticking with the whole inheritance logic. I reslly think that it might be dangerous to open the possibility to break this inheritance principle. Hi Rainer, Org already has a way to disable inheritance in general, and on a property-by-property basis. See http://orgmode.org/manual/Property-inheritance.html#Property-inheritance and the docstrings for the variable org-use-property-inheritance and the function org-entry-get. It seems that what you want to do can be described as disabling inheritance of the :var properties for a specific block. So I'm suggesting that it may be more parsimonious to do this with the existing Org inheritance mechanisms than to introduce new babel header arguments specifically for this purpose. #+header: :bind org-babel-use
[Orgmode] Re: [BABEL] unset :var definitions for subtree
[...] 2. It should be possible somehow to include the options together with the shebang, or to replace :shebang with a more general preamble concept. Or to make :shebang accept a code block as its value. #+BABEL: :var A=13 #+BABEL: :var B=14 #+header: :shebang #!/bin/bash #$ -cwd #+begin_src sh :tangle script.sh # empty #+end_src Similar to above - should work, but now the options for torque are hidden in the shebang - which is not to nice, but should work - although changing the options is not nearly as nice as if the options are in the source block. It seems that we should be able to put the preamble lines in a src block. This works, but only after making an alteration to the sbe function (below) so that it will allow multiple line results. Maybe Eric will have some ideas here. --- #+BABEL: :var A=13 #+BABEL: :var B=14 #+srcname: sheb #+begin_src sh :results output echo '#!/bin/bash' echo '#$ -cwd' #+end_src #+header: :shebang (sbe sheb) #+begin_src sh :tangle script.sh # empty #+end_src --- (setq source-block (symbol-name source-block))) -(org-babel-table-truncate-at-newline ;; org-table cells can't be multi-line (if (and source-block ( (length source-block) 0)) (let ((params (eval `(org-babel-parse-header-arguments @@ -116,7 +115,7 @@ example above. )) (org-babel-execute-src-block nil (list emacs-lisp results params) '((:results . silent - + ))) Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] unset :var definitions for subtree
Eric Schulte schulte.e...@gmail.com writes: Hi Dan, Many interesting suggestions, but I don't see how any of them are simpler (either conceptually or in terms of implementation) than defining a way to unset a variable previously set at a higher level of generality. Is it the concept or the syntax of the previous suggestions that you find objectionable? I thought that either the :remove or :unset options suggested by Rainer seemed intuitive. I understand your point about not using a keyword, and I agree (especially as our parsing is currently based on the assumption that keywords are header arguments). So maybe the following... this would unset all variables #+begin_src emacs-lisp :var unset ;; code #+end_src this would unset only the variable A #+begin_src emacs-lisp :var unset(A) ;; code #+end_src approaching this from another direction, we could have an :unset header argument, which takes as arguments the names of other header arguments to unset. Could be used like this... #+begin_src emacs-lisp :unset '(var noweb) ;; code #+end_src although it's not clear how to use such a construct to unset particular variables... So what do you think? Should we explore syntactic options, or is there something wrong with the very idea of a way of unsetting previously bound header arguments? I agree, the things I was talking about don't end up being simpler in terms of usage for this case. My thinking was that variable unsetting might be something that would be required fairly rarely, and so it might be worth appropriate to support it as part of a more general/powerful mechanism tied into Org properties, or even that hook. Before we proceed with the variable unsetting, could someone provide a motivating example, just to convince ourselves that the extra features are justified? (The conclusion of another message was that the torque script example was more a motivating example for shebang/preamble processing than for variable unsetting.) Dan Thanks -- Eric More Comments in-line below: [...] It would be nice to generalize whatever solution we apply across all types of header argument (both for implementation and for user simplicity). Some half thought-through suggestions. Sorry if this is a bit disorganized. I wonder whether we should be using Org property inheritance here. If it were possible to turn off property inheritance temporarily for the execution of the block, then it could be prevented from inheriting the header args that you don't want it to inherit. Turning off property inheritance would break inheritance of *all* types of header argument (which is probably not desirable) and would not be useful for default values set in e.g., org-babel-default-header-args. Also, how is this simpler than unsetting header arguments? Perhaps babel could offer a :bind header argument, which specifies the values of lisp variables in a let-binding which encloses the src block execution? hmm, that is certainly an interesting Idea, and (separate from this discussion of the need to unset variables) may be very useful in some contexts -- although changing the lexical scope during the execution of a code block probably wouldn't be normal usage. In fact in many cases this would have no effect because we explicitly ensure variables have the value needed my our code, so often the user would end up with situations like the following ;; babel code (let ((some-org-variable 'user-desired-value)) ;; more babel processing ;; ... ;; variable is about to be used (let ((some-org-variable 'babel-default-value)) ; - we set explicitly ;; code that uses `some-org-variable' )) #+header: :bind org-babel-use-property-inheritance nil #+begin_src sh :tangle script.sh :shebang #!/bin/bash #$ -cwd #+end_src with a patch along these lines +(defvar org-babel-use-property-inheritance t + When looking for org-babel header arguments in in-buffer + properties, this variable is passed as the INHERIT argument to + the function `org-enrty-get') + (defvar org-file-properties) (defun org-babel-params-from-properties (optional lang) Retrieve parameters specified as properties. @@ -864,7 +870,7 @@ may be specified in the properties of the current outline entry. (lambda (header-arg) (and (setq val (or (condition-case nil - (org-entry-get (point) header-arg t) + (org-entry-get (point) header-arg org-babel-use-property-inheritance) (error nil)) (cdr (assoc header-arg org-file-properties (cons (intern (concat : header-arg)) So you dealt with the issue I noticed above by defining a separate variable which the user *could* override with a `let'. This would work but would require - rewriting of our code to use custom babel versions of many
[Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org
Julien Danjou jul...@danjou.info writes: Hi, Following my short presentation at the Paris OrgCamp, I've now written a page and officially released org-contacts. It is a contact manager based on Org, that can possibly replace BBDB for certain usage. http://julien.danjou.info/org-contacts.html Hi Julien, I'm using it (with gnus). Looks great and seems to work very nicely so far. One little thing: I don't seem to be getting case-insensitive completion, despite having org-contacts-completion-ignore-case set to t. Side-issue: Columns view is going to be nice for editing our org-contacts file. Can someone tell me if there is a way to instruct a file (or subtree) to start up in columns view, rather than having to issue C-c C-x C-c manually? (Like #+startup: columns or something)? Thanks very much, Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org
Julien Danjou jul...@danjou.info writes: On Thu, Feb 10 2011, Dan Davison wrote: Hi Julien, I'm using it (with gnus). Looks great and seems to work very nicely so far. One little thing: I don't seem to be getting case-insensitive completion, despite having org-contacts-completion-ignore-case set to t. Your the second one to report that to me, but it does work for me with Emacs 24 at least. I'm using Emacs 24 on OS X cocoa. I did have a quick look at the code; I'm not familiar with the common lisp constructs, so maybe it will be educational for me to look again. Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: python :session and org_babel_python_eoe
Myles English mylesengl...@gmail.com writes: Hello, Is this behaviour expected?: #+begin_src python :session import sys #+end_src #+results: But in the python interpreter there is this: import sys open('/home/myles/tmp/scratch/python-4938gzQ', 'w').write(str(_)) 'org_babel_python_eoe' Traceback (most recent call last): File stdin, line 1, in module NameError: name '_' is not defined 'org_babel_python_eoe' Hi Myles, Firstly, I'm aware that python sessions are a little rough round the edges in places. I've recently started to use them quite a bit and would like to improve them, so any reports of problems you encounter will be appreciated. Yes, this is expected, although we could do without it. Since you did not specify :results, you are in the default value mode, which attempts to return to the org buffer the last value computed, using the special variable _. However, _ does not yet exist as you haven't computed anything. You could do #+begin_src python :session import sys None #+end_src Or you could use :results output here, which will result in a cleaner session buffer in this particular case. I wonder whether it would make sense to support :results nil, meaning I know in advance that I want the result to be nil, so don't try to retrieve any results for me. That may be useful in order to execute a src block that would return an extremely large result -- one which you really don't want emacs to try to deal with at all. Perhaps the value of :results could even be allowed to be a lisp form in general, in addition to output and value and silent. The open(...).write(str(_)) is org-babel internals -- that's how Org gets the value out of python and back to the org buffer. Ideally, it would not be exposed to the user -- but so far R is the only babel language where we've hidden it. So the solution in terms of babel development could be 1. Test for the existence of _ before attempting to write it. Perhaps using locals().get('_') is None and 2. Don't echo that stuff to the python session buffer Also, the 'org_babel_python_eoe', shouldn't really be there -- it only makes sense in :results output mode. Dan The sys module did indeed import correctly though. And that file (/home/myles/tmp/scratch/python-4938gzQ) is empty. Versions: - Python 2.7.1 (r271:86832, Jan 6 2011, 11:45:30) [GCC 4.5.2] on linux2 - orgmode from git 7473e3 Wed Feb 9 17:30 - GNU Emacs 23.2.1(x86_64-unknown-linux-gnu) It looks related to the issue, described as being fixed, in this thread: (org-babel :session breaks returning things with python?) http://news.gmane.org/find-root.php?message_id=%3c871v669swp.fsf%40gmail.com%3e Thanks, Myles ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Something like SETUPFILE, but in .emacs?
Gary Oberbrunner ga...@oberbrunner.com writes: First time poster on this list, but old-school Emacs user since 1982. And I have to say, org-mode is amazing. I'm running current git master on emacs 24.0.50.1 on Windows. I've put all my org-mode export template stuff into a setup file in my home dir, and I make all my org-mode files use it by putting #+SETUPFILE: ~/my-setup.org My question is can I make this totally automatic, so every .org file I load gets that setupfile automatically? Hi Gary, I haven't actually tried doing this, but I think some of the answers may be in C-h v org-export-plist-vars. Dan org-export-plist-vars is a variable defined in `org-exp.el'. Its value is shown below. This variable is potentially risky when used as a file local variable. Documentation: List of properties that represent export/publishing variables. Each element is a list of 3 items: 1. The property that is used internally, and also for org-publish-project-alist 2. The string that can be used in the OPTION lines to set this option, or nil if this option cannot be changed in this way 3. The customization variable that sets the default for this option. Value: ((:link-up nil org-export-html-link-up) (:link-home nil org-export-html-link-home) (:language nil org-export-default-language) (:keywords nil org-export-page-keywords) (:description nil org-export-page-description) (:customtime nil org-display-custom-times) (:headline-levels H org-export-headline-levels) (:section-numbers num org-export-with-section-numbers) (:section-number-format nil org-export-section-number-format) (:table-of-contents toc org-export-with-toc) (:preserve-breaks \\n org-export-preserve-breaks) (:archived-trees nil org-export-with-archived-trees) (:emphasize * org-export-with-emphasize) (:sub-superscript ^ org-export-with-sub-superscripts) (:special-strings - org-export-with-special-strings) (:footnotes f org-export-with-footnotes) (:drawers d org-export-with-drawers) (:tags tags org-export-with-tags) (:todo-keywords todo org-export-with-todo-keywords) (:priority pri org-export-with-priority) (:TeX-macros TeX org-export-with-TeX-macros) (:LaTeX-fragments LaTeX org-export-with-LaTeX-fragments) (:latex-listings nil org-export-latex-listings) (:skip-before-1st-heading skip org-export-skip-text-before-1st-heading) (:fixed-width : org-export-with-fixed-width) (:timestamps org-export-with-timestamps) (:author-info author org-export-author-info) (:email-info email org-export-email-info) (:creator-info creator org-export-creator-info) (:time-stamp-file timestamp org-export-time-stamp-file) (:tables | org-export-with-tables) (:table-auto-headline nil org-export-highlight-first-table-line) (:style-include-default nil org-export-html-style-include-default) (:style-include-scripts nil org-export-html-style-include-scripts) (:style nil org-export-html-style) (:style-extra nil org-export-html-style-extra) (:agenda-style nil org-agenda-export-html-style) (:convert-org-links nil org-export-html-link-org-files-as-html) (:inline-images nil org-export-html-inline-images) (:html-extension nil org-export-html-extension) (:xml-declaration nil org-export-html-xml-declaration) (:html-table-tag nil org-export-html-table-tag) (:expand-quoted-html @ org-export-html-expand) (:timestamp nil org-export-html-with-timestamp) (:publishing-directory nil org-export-publishing-directory) (:preamble nil org-export-html-preamble) (:postamble nil org-export-html-postamble) (:auto-preamble nil org-export-html-auto-preamble) (:auto-postamble nil org-export-html-auto-postamble) (:author nil user-full-name) (:email nil user-mail-address) (:select-tags nil org-export-select-tags) (:exclude-tags nil org-export-exclude-tags) (:latex-image-options nil org-export-latex-image-default-option)) btw, here's my settings in my setup file in case anyone's interested. Mostly export stuff for HTML and LaTeX so the output comes out nice. ## Emacs org-mode settings. Include into a .org file at the end like this: ## #+SETUPFILE: ~/emacs-org-mode-setup.org #+AUTHOR:me #+EMAIL: ga...@example.org #+DATE: #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en #+OPTIONS: H:2 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t :t author:nil email:nil creator:nil timestamp:nil #+OPTIONS: TeX:t LaTeX:auto skip:nil d:nil todo:t pri:nil tags:not-in-toc #+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path: http://orgmode.org/org-info.js #+EXPORT_SELECT_TAGS: export #+EXPORT_EXCLUDE_TAGS: noexport #+LINK_UP: #+LINK_HOME: # Page formatting, use full page w/ less whitespace: #+LaTeX_HEADER: \usepackage[cm]{fullpage} #+LaTeX_HEADER: \usepackage[compact]{titlesec} # Snug up lists: #+LaTeX_HEADER: \usepackage{paralist} #+LaTeX_HEADER: \let\itemize\compactitem #+LaTeX_HEADER: \let\description\compactdesc #+LaTeX_HEADER: \let\enumerate\compactenum # Colors: #+LaTeX_HEADER: \usepackage{color}
[Orgmode] Re: Fontification of blocks
Just quickly, one thing I noticed is that the begin/end lines were visible even inside folded trees. I.e., in a folded org file, containing many src blocks, I could see the coloured backgrounds poking out of the folded sections, extending to the right of the screen. [...] E.g. this file - * heading #+begin_src emacs-lisp 1 #+end_src - I could reproduce it with your above file, if the file ends on the end_src line. The following: * heading #+begin_src emacs-lisp 1 #+end_src * other heading also exhibits the problem, but this one: * heading #+begin_src emacs-lisp 1 #+end_src * other heading does not. So, it is related to the fact that the block is the last line of the subtree or of the file. As I always have newlines before headings, I don't see such a problem on my docs. Dan, can you confirm the above observation? Confirm. Good point. Knowing this, do you have an idea on how to fix it? No. I do see things like this from time to time with outline-minor-mode. Can anyone suggest how to solve this folding/overlay/visibility problem? Dan If not, I'll try having a play with the patched file. Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [babel] After Tangle Change File Permission
Ian Barton li...@manor-farm.org writes: I am starting to use babel to maintain my collection of shell scripts. I want to automate the process as much as possible, so I would like to be able to set the execute bit on my tangled .sh scripts after the tangle process. I see that there is an after-tangle hook. Can anyone give me some hints as to how I might use this to execute a chmod *.sh on the directory containing my tangles shell scripts. Hi Ian, It looks like Eric has already implemented this particular case in a different way: if the :shebang header arg is set, then the file will be made executable. E.g. :shebang #!/bin/bash. However, to use the hook function, does something like this not work? #+begin_src emacs-lisp (defun dan/make-tangled-shell-files-executable () (shell-command chmod +x *.sh)) (add-hook 'org-babel-post-tangle-hook 'dan/make-tangled-shell-files-executable) #+end_src I admit I was getting some inconsistent results just then that I didn't understand. It should be possible to use #+begin_src emacs-lisp (add-hook 'org-babel-post-tangle-hook 'dan/make-tangled-shell-files-executable nil 'local) #+end_src so that the hook is set locally for the buffer in question. The code is #+begin_src emacs-lisp (when org-babel-post-tangle-hook (mapc (lambda (file) (org-babel-with-temp-filebuffer file (run-hooks 'org-babel-post-tangle-hook))) path-collector)) #+end_src , where `path-collector' is a list of tangled files. I believe that this implies that, each time the hook is run, default-directory will be equal to the directory containing the file in question, so the shell-command should run in that directory. Otoh, the above shows that the hook is run for each tangled file, so chmod +x *.sh would be executed more times than necessary. Dan Ian. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] Editing dot blocks with org-exp-blocks
Eric S Fraga e.fr...@ucl.ac.uk writes: Chris Maier christopher.ma...@gmail.com writes: The begin_dot is part of org-exp-blocks, as I understand it, and appears required to make it evaluate the Dot code, create the image file, and then incorporate that into the exported document (LaTeX, HTML, etc.) Thanks, Chris On Wed, Feb 9, 2011 at 3:56 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Chris Maier christopher.ma...@gmail.com writes: In normal Org code blocks (e.g. #+begin_src clojure #+end_src) it's possible to hit C-c ' and edit the block code in a separate buffer with the appropriate mode. This doesn't appear to work when using org-exp-blocks to edit a begin_dot block. Is there a command to do this? No idea but what about using #+begin_src dot ... #+end_src? -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.4 (release_7.4.324.gca7a) Yes, I know; I used to use begin_dot and begin_ditaa quite a bit. My understanding is that babel knows about dot and therefore provides the same functionality, albeit in a different way, I vote for removing / deprecating the dot and ditaa functionality of org-exp-blocks. possibly more confusing but definitely more customisable and hence more powerful. babel gives you access to features such as fontification, mode specific editing, caching. I am not sure what the intended long term development for these special export blocks might be? org's long term growth (development of features) is organic and responsive, not planned per se (and I mean this in a positive way as planned software projects seldom achieve their goals...) so it may be that nobody can answer this question! In any case, I didn't mean to imply that you cannot continue using these specific export blocks or that they don't do the job they were intended for. Simply that maybe babel is the route to go if you want to be able to use mode specific editing. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [babel] Execute checks before trying to load Babel languages
Hey Seb, I am sharing my .emacs file, and this is beginning to cause problems with people who don't have the same environment as I do. In particular with the following: #+begin_src emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '( (C . t) (R . t) (calc . t) (ditaa . t) [...] (sqlite . t))) #+end_src A couple of ideas: 1. I use this, which loads all languages supported in the current version of Org. dan/org-babel-list-supported-languages is a personal function, code below. #+begin_src emacs-lisp (setq org-babel-load-languages (mapcar (lambda (lang) (cons lang t)) (dan/org-babel-list-supported-languages))) (org-babel-do-load-languages 'org-babel-load-languages org-babel-load-languages) #+end_src [...] In fact, this is much more general than checking the Org-version: it addresses as well installed packages such as - Rterm (R and ess-mode) - ditaa (requires =sudo aptitude install openjdk-6-jre=) - gnuplot (requires gnuplot-mode) I don't think any of these are required in order to load the language. They should only be required when executing a block (and in the case of 'ess, when :session is used) - ledger (requires that =ob-ledger= is found...) - org (requires that =ob-org= is found...) 2. Seeing as you're sharing config files, maybe the solution is to accept that some bits of the configuration are by their nature specific to a paticular user and not robust across different installations. So in your main shared config file you could make a conservative decision to activate only emacs-lisp, or a set of core languages that you are confident will be present on your colleagues' systems. Then in addition you would have your own personal config file that gets loaded after the shared config, which activates your own languages. Dan #+begin_src emacs-lisp (require 'cl) (defun dan/org-babel-list-supported-languages () (interactive) (sort (set-difference (mapcar (lambda (s) (intern (progn (string-match ^ob-\\(.+\\)\.el$ s) (match-string 1 s (directory-files (save-window-excursion (file-name-directory (buffer-file-name (find-library ob nil ^ob-.+\.el$)) '(comint eval exp keys lob ref table tangle)) (lambda (x y) (string (downcase (symbol-name x)) (downcase (symbol-name y)) #+end_src - ruby Do I have to check myself for such executables in a way similar to: #+begin_src emacs-lisp (when (find-exec Rterm) ... add R language ... ) (when (file-exists-p ob-ledger) ... add ledger language ... ) #+end_src or could we come up with some more generic and compact solution that would easily be usable by all of us? Maybe such a check should be made, by default, in every language file? Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] Editing dot blocks with org-exp-blocks
Chris Maier christopher.ma...@gmail.com writes: I fixed my problem... had to dig around in the source of ob-dot.el, though, since it doesn't appear to be on the website [1]. There are some additional undocumented header parameters that ob-dot adds to the standard Babel params. With org-exp-blocks you do this: #+begin_dot foo.png -Tpng ... dot code ... #+end_dot With plain old Babel, you do this: #+begin_src dot :file foo.png :cmdline -Tpng ... dot code ... #+end_src Knowing this now, I'd argue for deprecating org-exp-blocks, too. Now my question changes slightly. With the src block configured as above, I can export and execute the code fine, but when I type C-c ' to edit the Dot code in a separate buffer, it goes into fundamental mode, even though I have graphviz-dot-mode [2] installed and working fine. I suspect it might be because it's called graphviz-dot-mode instead of just dot-mode (that's just speculation on my part, though). Is there a way to explicitly associate an major mode with a particular kind of language block? Hi Chris, Yes, see the variable org-src-lang-modes. Use customize, or something like this: #+begin_src emacs-lisp (aput 'org-src-lang-modes dot 'graphviz-dot) #+end_src (Elisp question: I can't remember why we don't use aput in org-mode? What's the idiomatic org way of doing that? This #+begin_src emacs-lisp (setq org-src-lang-modes (append '((dot . graphviz-dot)) (delq (assoc dot org-src-lang-modes) org-src-lang-modes))) #+end_src doesn't work if there's already more than one entry for dot) Dan Thanks, Chris [1] http://orgmode.org/worg/org-contrib/babel/languages.html [2] http://users.skynet.be/ppareit/projects/graphviz-dot-mode/graphviz-dot-mode.html On Wed, Feb 9, 2011 at 10:14 AM, Dan Davison dandavis...@gmail.com wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: Chris Maier christopher.ma...@gmail.com writes: The begin_dot is part of org-exp-blocks, as I understand it, and appears required to make it evaluate the Dot code, create the image file, and then incorporate that into the exported document (LaTeX, HTML, etc.) Thanks, Chris On Wed, Feb 9, 2011 at 3:56 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Chris Maier christopher.ma...@gmail.com writes: In normal Org code blocks (e.g. #+begin_src clojure #+end_src) it's possible to hit C-c ' and edit the block code in a separate buffer with the appropriate mode. This doesn't appear to work when using org-exp-blocks to edit a begin_dot block. Is there a command to do this? No idea but what about using #+begin_src dot ... #+end_src? -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.4 (release_7.4.324.gca7a) Yes, I know; I used to use begin_dot and begin_ditaa quite a bit. My understanding is that babel knows about dot and therefore provides the same functionality, albeit in a different way, I vote for removing / deprecating the dot and ditaa functionality of org-exp-blocks. possibly more confusing but definitely more customisable and hence more powerful. babel gives you access to features such as fontification, mode specific editing, caching. I am not sure what the intended long term development for these special export blocks might be? org's long term growth (development of features) is organic and responsive, not planned per se (and I mean this in a positive way as planned software projects seldom achieve their goals...) so it may be that nobody can answer this question! In any case, I didn't mean to imply that you cannot continue using these specific export blocks or that they don't do the job they were intended for. Simply that maybe babel is the route to go if you want to be able to use mode specific editing. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [babel] Problem using noweb
Eric S Fraga e.fr...@ucl.ac.uk writes: andy andy.cho...@gmail.com writes: I want to take advantage of babel's noweb capabilities, but I can't seem to get it to work. [...] * Foo ** Bar #+src_name: bar #+begin_src R :noweb yes :session *R* test-block print(I am here) a #+end_src * test-block #+src_name: test-block #+begin_src R :session *R* a - c(1,2,3,4,5) #+end_src Hey Andy, I hope this didn't detain you too long, because you were basically doing nothing wrong. Except... #+srcname has no underscore in it! I believe that you need to specify noweb on every source block, including the one you wish to include. Nope. :) Only bar needs :noweb above. Dan That's what I had to do, in any case, if I remember correctly... haven't tried it on your code as my train is pulling into the station and I have to run! ;) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Fontification of blocks
Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hi Dan, Dan Davison wrote: Sébastien Vauban wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-XMD5yJDbdMSQIYZ4X/+iSw@public.gmane.orgrg writes: Dan Davison wrote: Just quickly, one thing I noticed is that the begin/end lines were visible even inside folded trees. I.e., in a folded org file, containing many src blocks, I could see the coloured backgrounds poking out of the folded sections, extending to the right of the screen. Do you see that? Yes, but that's already the current situation today, *when using faces with background*. My (future) patch does not change that, and I'm not sure whether it should or not. In a way, I find this better: it makes it very clear there is a code block folded at that point in the document. Yes, I definitively prefer it that way -- if you don't mind. Hi Seb, hmm, maybe we're talking about different things. I think so as well. I was thinking you were talking about the delimiter line (begin_src and end_src) going up to the right end of the screen if the fully expanded view. Your picture shows it when folded. I would say this is a bug. Indeed, that's definitely a bug. A key part of Org's visual model is that folding hides content. Imo. I'm not saying I know how to fix it, but that's a separate issue. Here are three screenshots: org-overview: org-content: show-all: Can you send me your file, for me to test if I have the same problem? I don't have that file any longer, but the problem occurs with all files. It is somewhat unpredictable -- I mess about with block show/hide, and global visibility cycling, and it happens eventually if not at first. E.g. this file - * heading #+begin_src emacs-lisp 1 #+end_src - FYI, I've seen that once when working on my patch[1], but never ever since the last versions. Hence, just checking (plizz don't mind), are you really using the version committed in the trunk, yes, clean, HEAD is 88b793946. Note I'm on OS X (cocoa builds). Maybe someone else with OSX could try to reproduce this? It occurs with a distributed binary of aquamacs, and when loading nothing but Org, so it doesn't seem to be any local stuff of mine that's the problem. Dan or some older version I may have sent on this list? (Btw, that's with the box face attribute set with your patch. Just playing with it to see if I like it.) Maybe make a try with underline and overline -- discovered not that long ago. I find that the nicest combination... As well for headings 1 and 2. I'll send my newest color theme very soon for you to see this, if you're interested. Nope: correction, I'll put it directly on Worg. I'll ask for access, and try being autonomous for such things. Best regards, Seb Footnotes: [1] IIRC, Eric Fraga did see that as well, at some point in time. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] make export dispatcher go away promptly
Following on from Stephen's recent post, a thing-that-slightly-bothers-me is the way the export dispatcher window doesn't go away until export is complete. I've briefly looked at the code twice now and it wasn't obvious to me why the save-window-excursion (line 941 org-exp.el) wasn't already doing what I wanted. However, the change below seems to have the effect I wanted. While this particular solution may be a hack, I wonder whether people would prefer its behaviour? E.g. try exporting this: #+title: title #+begin_src sh :exports results sleep 5 echo hello #+end_src export can often take several seconds and it's nice to be able to zone out looking at your org document rather than the dispatcher window. Modified lisp/org-exp.el diff --git a/lisp/org-exp.el b/lisp/org-exp.el index 13fa549..3d291e2 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -963,6 +963,7 @@ value of `org-export-run-in-background'. (setq r1 (read-char-exclusive))) (error No enclosing node with LaTeX_CLASS or EXPORT_FILE_NAME) ) +(redisplay) (and bpos (goto-char bpos)) (setq r2 (if ( r1 27) (+ r1 96) r1)) (unless (setq ass (assq r2 cmds)) (I see that (sit-for .0001) is used in a couple of places in Org for this effect, so maybe that should be used instead.) Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: silent evaluation during export
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, I have several code blocks that must be evaluated during export, but silently, i.e. I do not want code/output/anything to appear in the export. How do I achieve this? The obvious :export none also disables evaluation. Hi Andreas, :exports results :results silent Dan Regards, Andreas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: inline code block results
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, just found out: the inline block works when I explicitly state :results replace. So both questions from the previous email collapse to: why is that necessary? Regards, Andreas Am 04.02.2011 17:13, schrieb Andreas Leha: Hi all, I have two questions: (1) How do I get resuts from code block evaluation (e.g. a single number) inline into text during (LaTeX-)export? Something like: We use a level of #+call: getLevel() (2) Why do these two subheadings produce different output during (LaTeX-)export? * Test ** Normal source code block The number is #+srcname: success_parameter_one #+begin_src R :session :results value :exports results tmp - rnorm(1) #+end_src ** Inline source code block The number is src_R[:session :results value :exports results]{tmp - rnorm(1)} Hi Andreas, This is a bug, thanks. They should both produce the number (and no code) in the exported material. It bisects to d0ca215105 which is a recent commit re-working export of inline- and regular src blocks. I believe the fix may be as below but I'll let Eric S check that. Note that in your inline src block :results value and :exports results are usually unnecessary, as they are the default values for inline src blocks. Dan diff --git a/lisp/ob.el b/lisp/ob.el index b899410..3fecbbd 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -297,7 +297,7 @@ specific header arguments as well.) Default arguments to use when evaluating a source block.) (defvar org-babel-default-inline-header-args - '((:session . none) (:results . silent) (:exports . results)) + '((:session . none) (:results . replace) (:exports . results)) Default arguments to use when evaluating an inline source block.) (defvar org-babel-current-buffer-properties nil Thanks in advance! Andreas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [babel] How to kill two birds with one stone?
Hi Seb, Cool post. I hope someone has some good ideas in this thread. Some quick responses / questions below. #+TITLE: Document a shell script as separate blocks #+DATE: 2011-02-04 #+LANGUAGE: en_US * Abstract When writing shell scripts, I'd like to kill *two* birds with one Babel stone: - Be able to *execute the script in situ*, so that I get a copy of the results stored in (and versioned with) my documentation. - Be able to *chain the code blocks*, so that I tangle a natural script into a file for later execution. I guess I currently miss some points in order to reach that goal in a clean way. Could you give me advice on how to get a step further down the route? * Sample code For the sake of clarity, let's take a simple problem: I'd like to generate a DOT graph of links between all files from a directory tree. So if file a.org contains - jhasg [[file:b.org]] [[file:c.org]] hbjgv - then you want an arrow from node a to node b and from node a to node c, right? The procedure: 1. (Recursively) list all files inside the directory. 2. For each file, (recursively) search for its name referenced in all the files. 3. Generate a DOT representation of the link between files. ** List all files under current directory #+srcname: dw-file-tree #+begin_src sh :results output cd ~/Some-Project-Dir find . -type f -print | grep -v .svn | head -n 5 #+end_src #+results: dw-file-tree #+begin_example ./.cvsignore ./charge_dim ./charge_fct ./compte ./controle_config #+end_example Here, I voluntary limit the number of results to the first 5 files, for the compactness of this example. This sample does not include any file from subdirectories, but it doesn't matter. ** Search recursively for anything about a file Search through all files (ignoring =.svn= directories) for any reference to filename given as parameter. #+srcname: search-files-pointing-to-this-file #+begin_src sh :results output :var f=charge_dim cd ~/Some-Project-Dir find . -not \( -name .svn -prune \) -type f -print0 |\ xargs -0 grep -i --files-with-matches $f #+end_src #+results: search-files-pointing-to-this-file #+begin_example ./.cvsignore ./charge_dim ./compte ./IFP/Chrg_dim ./IFP/Chrg_dim.avant_simple_recovery_mode_2008_03_12 ./principal.env ./29Aalst/Chrg_dim ./29Aalst/Chrg_dim_interactif ./29Aalst/Publ_dim_interactif #+end_example HERE, I'M GIVING A FILENAME AS DEFAULT VALUE OF =f= IN ORDER TO SEE A SAMPLE RESULTS. ** Convert to a DOT representation For every file pointing to the file given in parameter, generate an arrow (edge) in DOT representation. #+srcname: dot-arrow-from-files-pointing-to-this-file #+begin_src sh :results output :var f=charge_dim :var data=search-files-pointing-to-this-file for i in $(echo $data); do echo $(basename $i) - $f; done #+end_src #+results: dot-arrow-from-files-pointing-to-this-file #+begin_example .cvsignore - charge_dim charge_dim - charge_dim compte - charge_dim Chrg_dim - charge_dim Chrg_dim.avant_simple_recovery_mode_2008_03_12 - charge_dim principal.env - charge_dim Chrg_dim - charge_dim Chrg_dim_interactif - charge_dim Publ_dim_interactif - charge_dim #+end_example HERE, I'M WORKING GIVING ONCE AGAIN THE SAME DEFAULT VALUE FOR TESTING (AND DOCUMENTATION) PURPOSE. * Problem All of the above nicely answer my first goal (Be able to execute the script in situ, so that I get a copy of the results stored in my documentation). It does not allow for the second one: *how to chain the calls together*? For example, just for chaining steps 2 and 3 (the easier to chain, I think), I'd like to be able to write something like this: #+srcname: search-links-and-generate-dot-arrow #+begin_src sh :results output :var f=charge_dim :var data=search-files-pointing-to-this-file :noweb yes for i in ( search-files-pointing-to-this-file); do echo $(basename $i) - $f; done #+end_src Don't forget about C-c C-v C-v `org-babel-expand-src-block' when debugging this problem. I've started using that a lot. My shell scripting may be too weak to help here. (Which is one point, I'd be tempted to bail out to another language on this one) What exactly are you doing there? Executing the code from the other block in a subshell and using the stdout as the set to loop over? You're sure you don't want parentheses search-files-pointing-to-this-file() ? Or $( ... ) / backticks ? How are you going to pass arguments to the search-files-pointing src block? #+results: search-links-and-generate-dot-arrow But it yields an error: #+begin_src text :eval no sh: line 14: syntax error near unexpected token `(' sh: line 14: `for i in (' #+end_src Note, in the latter code block, that I did not even tried to really chain steps 2 and 3: I'm rewriting step 3, including step 2 inside it. *I certainly miss a smarter way* to achieve the above. I think a relevant
[Orgmode] Re: Suppressing src block evaluationon publish?
Loris Bennett loris.benn...@fu-berlin.de writes: Erik Iverson er...@ccbr.umn.edu writes: Loris Bennett wrote: Hi, I have an org file containing several src blocks which generate images using ditaa. When I publish to PDF via LaTeX, the images are all generated every time, which makes publishing rather slow. Is there some way to toggle the evaluation of the src blocks on and off when the file is published? You could try the :cache header argument, http://orgmode.org/org.html#cache Ah, thanks. There is a slight gotcha here, though. I added :cache yes to the source headers and exported again, but nothing changed; all the images were generated again. Also, no SHA1 hash was added to the +results header. After some fruitless fiddling I was about to write to the list again and moan, when I did a slightly random C-c C-c in the begin_src line and, hey presto, the hash was added to the results header. I then did this for all the images and found that the image were no longer regenerated on export, as advertised. Hi Loris, Yes. It does seem that it would be nice if in this situation, the first export added the SHA1s, and subsequent exports recognized that evaluation wasn't required. I think the reason this does not happen is that behind-the-scenes Org makes a copy of the buffer for export preprocessing (including src block evaluation). But Eric S is the expert -- he may have more to say here. A couple of things that might be relevant here: the variable `org-export-babel-evaluate' can also be used to prevent evaluation on export (but the :cache approach has advantages). And C-c C-v C-b / C-c C-v C-s (`org-babel-evaluate-buffer' / `org-babel-execute-subtree') could be used to update the SHA1s. Perhaps the documentation of :cache could be extended to mention the necessity of evaluating the source block before exporting. I've added that to the TODO list. Dan Loris ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Fontification of blocks
Hi Seb, Just quickly, one thing I noticed is that the begin/end lines were visible even inside folded trees. I.e., in a folded org file, containing many src blocks, I could see the coloured backgrounds poking out of the folded sections, extending to the right of the screen. Do you see that? Also, Eric Schulte wrote: I think that adding a new block delimiter face which inherits from the org-meta face as you've suggested is the way to go. I would recommend however that rather than removing/changing the org-meta-line, quote and verse delimiting faces to cover the entire line you simply add the org-block-begin/end-line face overtop of these existing faces. That way the default behavior is not changed by the patch, and users have more control over the final display. In fact rather than having the org-block-begin/end-line faces inherit from org-meta-line why not have them begin as empty faces. Do you think this sounds like a good way to go? If so would you mind submitting a patch which - doesn't remove existing faces but rather adds these new faces overtop of them - includes of definition of the org-block-begin/end-line faces to empty faces (otherwise the elisp compiler will warn of references to undefined variables) Could you clarify whether the above suggestions have been adopted or rejected? At the moment the code below alters the background color of the begin/end lines by default; but presumably the final version will not alter any appearances by default? How will that work? Would you be able to supply a patch, or better, put your work in a publicly accessible git branch? It's hard to see exactly what changes you have made with the full code as below. (Please contact me for write access if you'd like to use the fork at https://github.com/dandavison/org-devel.) Dan Also, could you share an example code snippet which initializes the org-block-begin/end-line faces initialized (either here and/or on worg)? Here a proposition that goes in that direction -- not yet a real patch, but something for you to have a look at. Should be easy to test, at least, that's what I tried to achieve. #+TITLE: Patch for block fontification #+DATE: 2011-02-01 #+LANGUAGE: en_US * Abstract This is the new code that I will supply as a patch. To test it, just evaluate the next source block, and please report any problem. What it does: - add 2 faces for the lines delimiting the beginning and the end of the source block - fixes a tiny bug (affecting the begin delimiter line of source blocks) when in native fontification (from Dan Davison) FOR PEOPLE BEING MORE EXPERTS THAN I AM, it shows what I tried for adding a yellow (very visible, for test purpose) background to the natively fontified source blocks. This does not work, but is commented -- so it does not impact anything unless you uncomment it... See line NOK. * Code #+begin_src emacs-lisp :results silent (defface org-block-begin-line '((t (:inherit org-meta-line :underline light grey :foreground #008ED1 :background #EAEAFF))) Face used for the line delimiting the begin of source blocks.) (defface org-block-end-line '((t (:inherit org-meta-line :overline light grey :foreground #008ED1 :background #EAEAFF))) Face used for the line delimiting the end of source blocks.) (defface org-block-background '((t (:background #00))) Face used for the source block background.) (defun org-fontify-meta-lines-and-blocks (limit) Fontify #+ lines and blocks, in the correct ways. (let ((case-fold-search t)) (if (re-search-forward ^\\([ \t]*#\\+\\(\\([a-zA-Z]+:?\\| \\|$\\)\\(_\\([a-zA-Z]+\\)\\)?\\)[ \t]*\\(\\([^ \t\n]*\\)[ \t]*\\(.*\\)\\)\\) limit t) (let ((beg (match-beginning 0)) (block-start (match-end 0)) (block-end nil) (lang (match-string 7)) (beg1 (line-beginning-position 2)) (dc1 (downcase (match-string 2))) (dc3 (downcase (match-string 3))) end end1 quoting block-type) (cond ((member dc1 '(html: ascii: latex: docbook:)) ;; a single line of backend-specific content (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0)) (remove-text-properties (match-beginning 0) (match-end 0) '(display t invisible t intangible t)) (add-text-properties (match-beginning 1) (match-end 3) '(font-lock-fontified t face org-meta-line)) (add-text-properties (match-beginning 6) (+ (match-end 6) 1) '(font-lock-fontified t face org-block)) ; for backend-specific code t) ((and (match-end 4) (equal dc3 begin)) ;; Truly a block (setq block-type (downcase (match-string 5)) quoting (member
[Orgmode] PATCH: New options for latex src code export
Tom Dye and I have been working on providing more user control over latex export of src code via the listings and minted latex packages. The main code change is 2 commits in branch minted of the org repo, and pasted below as a single patch for patchwork. These changes allow Org users to set all the available options for the \lstset and \begin{minted} commands[1], and also to specify custom latex environments on a per-language basis to be used for exporting src blocks. I'd like to ask for advice on a couple of things: Currently, in order for a user to use minted for colored latex export of src code, s/he would 1. install pygments - linux :: apt-get install python-pygments - OSX / linux :: 'pip install pygments' or 'easy_install pygments' 2. (setq org-export-latex-listings 'minted) 3. Add the minted package to `org-export-latex-packages-alist', via customize, or #+begin_src emacs-lisp (require 'org-latex) (add-to-list 'org-export-latex-packages-alist '( minted)) #+end_src 4. Configure `org-latex-to-pdf-process' so that the -shell-escape option is passed to pdflatex. My questions are 1. It would be nice if users didn't have to worry about step 4. Can anyone suggest a sensible way to have the -shell-escape option passed to pdflatex under the appropriate circumstances? These conditions include: 1. minted is being used for export 2. pdflatex is being used, a.o.t. e.g. rubber or some other latex make tool. 2. Regarding step (2), it might be preferable to have a variable `org-export-latex-src' which takes a single value in the set '(listings minted). Does anyone think it's worth making such a backward-incompatible change? Minted support has been in Org for a while, but I think I'm guilty of not having properly described it on list. See C-h v org-export-latex-listings. It has the advantage over listings of creating pretty coloured pdf export of source code without any user latex customization. My understanding is that minted.sty is in major latex distributions (e.g. TexLive, MacTex). Patch and commit log follow. ('git show -w' shows the changes more helpfully.) Dan Footnotes: [1] It might be possible to code all the available options into the Customize interface? New UI for configuring latex src code export. Three new user-customizable variables: org-export-latex-listings-options (default nil) ~~~ Association list of options for the latex listings package. These options are supplied as a comma-separated list to the \\lstset command. Each element of the association list should be a list containing two strings: the name of the option, and the value. For example, (setq org-export-latex-listings-options '((\basicstyle\ \\\small\) (\keywordstyle\ \\\color{black}\\bfseries\\underbar\))) will typeset the code in a small size font with underlined, bold black keywords. Note that the same options will be applied to blocks of all languages. See ftp://ftp.tex.ac.uk/tex-archive/macros/latex/contrib/listings/listings.pdf customization group: org-export-latex org-export-latex-minted-options (default nil) ~ Association list of options for the latex minted package. These options are supplied within square brackets in \\begin{minted} environments. Each element of the alist should be a list containing two strings: the name of the option, and the value. For example, (setq org-export-latex-minted-options '((\bgcolor\ \bg\) (\frame\ \lines\))) will result in src blocks being exported with \\begin{minted}[bgcolor=bg,frame=lines]{LANG} as the start of the minted environment. Note that the same options will be applied to blocks of all languages. customization group: org-export-latex See minted.googlecode.com/files/minted.pdf org-export-latex-custom-lang-environments (default nil) ~~~ Association list mapping languages to language-specific latex environments used during export of src blocks by the listings and minted latex packages. For example, (setq org-export-latex-custom-lang-environments '((python \pythoncode\))) * lisp/org-exp.el (org-export-format-source-code-or-example): Support new user-customizable options (org-export-latex-custom-lang-environments): Ensure new variable is defined (org-export-latex-listings-options): Ensure new variable is defined (org-export-latex-minted-options): Ensure new variable is defined * lisp/org-latex.el (org-export-latex-listings-options): New variable (org-export-latex-minted-options): New variable
[Orgmode] Re: Overlays and elisp code
Jeff Horn jrhorn...@gmail.com writes: I can reproduce this. emacs 23.1 and org 7.4 On Mon, Jan 31, 2011 at 5:04 AM, Andrea Crotti andrea.crott...@gmail.com wrote: I found a strange behaviour which might be a bug, but maybe of my configuration. This is org mode version: Org-mode version 7.4 (release_7.4.199.g8be1.dirty) and emacs: GNU Emacs 23.2.1 (x86_64-apple-darwin10.3.0, NS apple-appkit-1038.29) of 2010-05-09 on linc To reproduce the bug I do - go over an elisp code block - C-c ' to edit in the overlay - C-c ' to go back when done And it works perfectly, BUT if for example I remove a parenthesis before pressing C-c ', I can't go back. C-c ' becomes undefined and I have to kill both the overlay and the original buffer. While I was writing I also found the cause of the problem, Paredit! Removing the hook from emacs-lisp-mode-hook fixes this, but paredit is really useful with elisp, maybe someone has an idea of why this happens? Hi Andrea, So it looks like paredit-mode refuses to start up (throws an error) if the parentheses are unbalanced. So how about we use #+begin_src emacs-lisp (add-hook 'emacs-lisp-mode-hook (lambda () (condition-case nil (paredit-mode) (error (message Failed to activate paredit mode) #+end_src At the moment this message gets stamped on by a message which org-edit-src always issues in the echo-area. I'm going to submit a patch to control that in a subsequent email. Oh no. You got me editing elisp with paredit mode turned on. Maybe it will last more than 5 minutes this time :) Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Overlays and elisp code
On Mon, Jan 31, 2011 at 5:04 AM, Andrea Crotti andrea.crott...@gmail.com wrote: I found a strange behaviour which might be a bug, but maybe of my configuration. [...] - go over an elisp code block - C-c ' to edit in the overlay - C-c ' to go back when done And it works perfectly, BUT if for example I remove a parenthesis before pressing C-c ', I can't go back. C-c ' becomes undefined and I have to kill both the overlay and the original buffer. [...] So it looks like paredit-mode refuses to start up (throws an error) if the parentheses are unbalanced. So how about we use #+begin_src emacs-lisp (add-hook 'emacs-lisp-mode-hook (lambda () (condition-case nil (paredit-mode) (error (message Failed to activate paredit mode) #+end_src At the moment this message gets stamped on by a message which org-edit-src always issues in the echo-area. When using C-c ', currently we can turn off the persistent message at the top of the screen by setting `org-edit-src-persistent-message' to nil, but we can't prevent the echo-area message without more code. The echo area message may be useful for new users, but for experienced users it is unnecessary and risks obscuring more useful messages. This patch provides control over both messages. The relevant customizable variable has a different name: `org-edit-src-messages'. Dan Change user option for controlling edit buffer messages * lisp/org-src.el (org-edit-src-messages): Change UI for controlling educational messages when src-code generating edit buffer. (org-edit-src-code): Implement control over persistent header message and echo-area message. #+begin_src diff diff --git a/lisp/org-src.el b/lisp/org-src.el index f55e292..ea9be6c 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -113,13 +113,16 @@ editing it with \\[org-edit-src-code]. Has no effect if If non-nil, blank lines are removed when exiting the code edit buffer.) -(defcustom org-edit-src-persistent-message t - Non-nil means show persistent exit help message while editing src examples. -The message is shown in the header-line, which will be created in the -first line of the window showing the editing buffer. -When nil, the message will only be shown intermittently in the echo area. +(defcustom org-edit-src-messages '(message header) + Which messages to show when editing src examples. +If 'header is a member of this list, then a message is shown in +the header-line, which will be created in the first line of the +window showing the editing buffer. If 'message is in the list, +then a message will be displayed in the echo area. :group 'org-edit-structure - :type 'boolean) + :type '(set :greedy t + (const message) + (const header))) (defcustom org-src-window-setup 'reorganize-frame How the source code edit buffer should be displayed. @@ -320,9 +323,10 @@ buffer. (org-set-local 'org-edit-src-block-indentation block-nindent) (org-src-mode) (set-buffer-modified-p nil) - (and org-edit-src-persistent-message + (and (memq 'header org-edit-src-messages) (org-set-local 'header-line-format msg))) - (unless quietp (message %s msg)) + (unless (or quietp (not (memq 'message org-edit-src-messages))) + (message %s msg)) t))) (defun org-edit-src-continue (e) #+end_src I'm going to submit a patch to control that in a subsequent email. Oh no. You got me editing elisp with paredit mode turned on. Maybe it will last more than 5 minutes this time :) Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Overlays and elisp code
Carsten Dominik carsten.domi...@gmail.com writes: Hi Dan, maybe just header in the default value to keep the echo area open for error messages? Absolutely. But if you prefer, we could just do away with the echo-area message entirely. That would have the advantage of leaving the user interface unchanged. With the default as '(header), my UI change only makes sense if we believe that an appreciable number of users will disable the header message and activate the echo-area message in its place. Dan Cheers - Carsten On Feb 1, 2011, at 12:01 PM, Dan Davison wrote: On Mon, Jan 31, 2011 at 5:04 AM, Andrea Crotti andrea.crott...@gmail.com wrote: I found a strange behaviour which might be a bug, but maybe of my configuration. [...] - go over an elisp code block - C-c ' to edit in the overlay - C-c ' to go back when done And it works perfectly, BUT if for example I remove a parenthesis before pressing C-c ', I can't go back. C-c ' becomes undefined and I have to kill both the overlay and the original buffer. [...] So it looks like paredit-mode refuses to start up (throws an error) if the parentheses are unbalanced. So how about we use #+begin_src emacs-lisp (add-hook 'emacs-lisp-mode-hook (lambda () (condition-case nil (paredit-mode) (error (message Failed to activate paredit mode) #+end_src At the moment this message gets stamped on by a message which org-edit-src always issues in the echo-area. When using C-c ', currently we can turn off the persistent message at the top of the screen by setting `org-edit-src-persistent-message' to nil, but we can't prevent the echo-area message without more code. The echo area message may be useful for new users, but for experienced users it is unnecessary and risks obscuring more useful messages. This patch provides control over both messages. The relevant customizable variable has a different name: `org-edit-src-messages'. Dan Change user option for controlling edit buffer messages * lisp/org-src.el (org-edit-src-messages): Change UI for controlling educational messages when src-code generating edit buffer. (org-edit-src-code): Implement control over persistent header message and echo-area message. #+begin_src diff diff --git a/lisp/org-src.el b/lisp/org-src.el index f55e292..ea9be6c 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -113,13 +113,16 @@ editing it with \\[org-edit-src-code]. Has no effect if If non-nil, blank lines are removed when exiting the code edit buffer.) -(defcustom org-edit-src-persistent-message t - Non-nil means show persistent exit help message while editing src examples. -The message is shown in the header-line, which will be created in the -first line of the window showing the editing buffer. -When nil, the message will only be shown intermittently in the echo area. +(defcustom org-edit-src-messages '(message header) + Which messages to show when editing src examples. +If 'header is a member of this list, then a message is shown in +the header-line, which will be created in the first line of the +window showing the editing buffer. If 'message is in the list, +then a message will be displayed in the echo area. :group 'org-edit-structure - :type 'boolean) + :type '(set :greedy t + (const message) + (const header))) (defcustom org-src-window-setup 'reorganize-frame How the source code edit buffer should be displayed. @@ -320,9 +323,10 @@ buffer. (org-set-local 'org-edit-src-block-indentation block-nindent) (org-src-mode) (set-buffer-modified-p nil) -(and org-edit-src-persistent-message +(and (memq 'header org-edit-src-messages) (org-set-local 'header-line-format msg))) - (unless quietp (message %s msg)) + (unless (or quietp (not (memq 'message org-edit-src-messages))) +(message %s msg)) t))) (defun org-edit-src-continue (e) #+end_src I'm going to submit a patch to control that in a subsequent email. Oh no. You got me editing elisp with paredit mode turned on. Maybe it will last more than 5 minutes this time :) Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies
[Orgmode] Re: Overlays and elisp code
Carsten Dominik carsten.domi...@gmail.com writes: On Feb 1, 2011, at 12:22 PM, Dan Davison wrote: Carsten Dominik carsten.domi...@gmail.com writes: Hi Dan, maybe just header in the default value to keep the echo area open for error messages? Absolutely. But if you prefer, we could just do away with the echo- area message entirely. That would have the advantage of leaving the user interface unchanged. With the default as '(header), my UI change only makes sense if we believe that an appreciable number of users will disable the header message and activate the echo-area message in its place. There are people who hate the header line IIRC. But I guess you are right - once people are ready to remove the header line for this application, they will probably have memorized it. I remember that I started with the echo area and introduced the header line because people were asking how to get out of there, so I needed something more persistent. So I guess if the header line is the default, I'd be fine with removing the echo area message altogether. I have done that, and removed my other patch from patchwork. Dan - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Problems with buffer-local variables
Carsten Dominik carsten.domi...@gmail.com writes: On Dec 22, 2010, at 3:51 PM, Dan Davison wrote: There's recently been some advocacy of using buffer-local variables for Org-mode configuration. It seems like a good idea to me. However, I think that it raises a problem: there are at least two situations in which Org internally spawns a buffer that is supposed to be a sort of copy of another Org buffer: these situations are export and org-src edit buffer. The problem is that the copy buffer doesn't inherit local variables from the parent buffer. It seems that either we should propagate all local variables in these cases (but I suspect that is inappropriate for some variables), or we have to have a rule for identifying the subset of local variables which need to be propagated. Below is one example which I think demonstrates a problem. If you evaluate the elisp block and then export to HTML, the noweb does not get expanded, because the configuration variable is buffer-local (behind the scenes, Org creates a buffer copy just before exporting a buffer). --8---cut here---start-8--- #+title: Local variables issues? Evaluate this block, then do C-c C-e h #+begin_src emacs-lisp :results silent :exports none (set-default 'org-babel-default-header-args:sh nil) (set (make-local-variable 'org-babel-default-header-args:sh) '((:noweb . yes))) #+end_src #+begin_src sh :exports both foo #+end_src #+source: foo #+begin_src sh :exports none echo hello #+end_src --8---cut here---end---8--- It's also a problem when spawning the org-src edit buffer. There is a patch in the pipeline that tries to identify all the necessary local variables and transmit them to the edit buffer: http://patchwork.newartisans.com/patch/438/ That's a bit messy, but in the export case it seems even harder to identify all variables that might need to be transmitted. What is a good solution? Hi Dan, I see only two possibilities. Either use a list of variables that should be transported, or copy all local variables, or all local variables that match a pattern. An example for doing something like this can be found in org-get-local-variables which is, for example, used by `org-run-like-in-org-mode'. Here's a patch. It clones into the pre-export buffer all buffer-local variables that match a regexp (currently ^\\(org-\\|orgtbl-\\)). We might want to watch out for unanticipated side effects. This should mean that we can use buffer-local variables to set export related variables on a per-buffer basis[1]. On reflection I think that the src edit buffer case should be dealt with as it is currently (by ad-hoc transporting of variables in the org-src code). I still stand by my pending patch 438, which tidies up the local-variables stuff in org-edit-src-code. http://patchwork.newartisans.com/patch/438/ Dan Footnotes: [1] Also, we can use the 'local argument to add-hook to set the various export hooks. Ensure that buffer-local variables have their effects during export. * lisp/org.el (org-clone-local-variables): New function to copy local variables from another buffer. * lisp/org-exp.el (org-export-preprocess-string): Clone local variables from source org buffer into temporary export preprocessing buffer. #+begin_src diff diff --git a/lisp/org-exp.el b/lisp/org-exp.el index 97f17e5..6b333a7 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -1028,6 +1028,7 @@ on this string to produce the exported version. (inhibit-read-only t) (drawers org-drawers) (outline-regexp \\*+ ) +(source-buffer (current-buffer)) target-alist rtn) (setq org-export-target-aliases nil @@ -1051,6 +1052,7 @@ on this string to produce the exported version. (let ((org-inhibit-startup t)) (org-mode)) (setq case-fold-search t) + (org-clone-local-variables source-buffer ^\\(org-\\|orgtbl-\\)) (org-install-letbind) ;; Call the hook diff --git a/lisp/org.el b/lisp/org.el index 808c9ed..dda97d9 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -8127,6 +8127,18 @@ Possible values in the list of contexts are `table', `headline', and `item'. x nil)) varlist +(defun org-clone-local-variables (from-buffer optional regexp) + Clone local variables from FROM-BUFFER. +Optional argument REGEXP selects variables to clone. + (mapc + (lambda (pair) + (and (symbolp (car pair)) + (or (null regexp) + (string-match regexp (symbol-name (car pair + (set (make-local-variable (car pair)) + (cdr pair + (buffer-local-variables from-buffer))) + ;;;###autoload (defun org-run-like-in-org-mode (cmd) Run a command, pretending that the current buffer is in Org-mode. #+end_src - Carsten ___ Emacs-orgmode
[Orgmode] PATCH: org-open-at-point curation
While fiddling with the way babel uses org-open-at-point, I noticed a coupe of things: 1. There's a bug when using the prefix arg with a text search link. E.g. try C-u C-c C-o on [[foo]] 2. The prefix arg is used in three different ways (two of them undocumented), not all of which correspond to the variable name used for the prefix arg. I'm leaving the extra uses undocumented, but have renamed the prefix arg with a more generic name. Dan ~ Some curation of `org-open-at-point' * lisp/org.el (org-open-at-point): Fix bug when using prefix arg to construct `org-link-search' call. Rename prefix arg with a more generic name, to reflect its diverse uses in this function. #+begin_src diff diff --git a/lisp/org.el b/lisp/org.el index a49d3e2..186af9d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -9084,12 +9084,12 @@ Functions in this hook must return t if they identify and follow a link at point. If they don't find anything interesting at point, they must return nil.) -(defun org-open-at-point (optional in-emacs reference-buffer) +(defun org-open-at-point (optional arg reference-buffer) Open link at or after point. If there is no link at point, this function will search forward up to the end of the current line. Normally, files will be opened by an appropriate application. If the -optional argument IN-EMACS is non-nil, Emacs will visit the file. +optional prefix argument ARG is non-nil, Emacs will visit the file. With a double prefix argument, try to open outside of Emacs, in the application the system uses for this file type. (interactive P) @@ -9107,7 +9107,7 @@ application the system uses for this file type. org-angle-link-re \\| [ \t]:[^ \t\n]+:[ \t]*$))) (not (get-text-property (point) 'org-linked-text))) -(or (org-offer-links-in-entry in-emacs) +(or (org-offer-links-in-entry arg) (progn (require 'org-attach) (org-attach-reveal 'if-exists ((run-hook-with-args-until-success 'org-open-at-point-functions)) ((org-at-timestamp-p t) (org-follow-timestamp-link)) @@ -9212,7 +9212,7 @@ application the system uses for this file type. (browse-url (concat type : path))) ((string= type tags) - (org-tags-view in-emacs path)) + (org-tags-view arg path)) ((string= type tree-match) (org-occur (concat \\[ (regexp-quote path) \\]))) @@ -9226,7 +9226,7 @@ application the system uses for this file type. path (substring path 0 (match-beginning 0) (if (string-match [*?{] (file-name-nondirectory path)) (dired path) - (org-open-file path in-emacs line search))) + (org-open-file path arg line search))) ((string= type shell) (let ((cmd path)) @@ -9258,14 +9258,14 @@ application the system uses for this file type. 'org-open-link-functions path))) ((string= type thisfile) - (if in-emacs + (if arg (switch-to-buffer-other-window (org-get-buffer-for-internal-link (current-buffer))) (org-mark-ring-push)) (let ((cmd `(org-link-search ,path - ,(cond ((equal in-emacs '(4)) 'occur) - ((equal in-emacs '(16)) 'org-occur) + ,(cond ((equal arg '(4)) ''occur) + ((equal arg '(16)) ''org-occur) (t nil)) ,pos))) (condition-case nil (eval cmd) #+end_src ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Tangle subtree only?
Rainer M Krug r.m.k...@gmail.com writes: Hi my org document is structured in such a way, that each subtree is to be tangled into a separate file, specified in a :PROPERTIES: :tangle: filename :END: drawer. If I change something in one subtree, I do tangle the whole file, just because of a small change in one of the many subtrees. Is there a way to tangle only the subtree in which the cursor is positioned (like the 1 in the export)? Hi Rainer, C-x n s (org-narrow-to-subtree) then tangle as normal. (We do have org-babel-execute-subtree; I'm not necessarily saying that the tangle analog shouldn't exist) Dan Thanks, Rainer ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [babel] Painless integration of source blocks with language
Eric S Fraga e.fr...@ucl.ac.uk writes: Eric Schulte schulte.e...@gmail.com writes: Eric S Fraga e.fr...@ucl.ac.uk writes: [...] management issue: I find it difficult (a) to remember what all my source code snippets are called and (b) to navigate to any given snippet. I would love to see a babel table of contents popup (a la the table of contents popup with reftex implements for latex files). Is something like this already available? If not, how difficult would it be to implement (I'm happy to try given a pointer in the right direction(s)...). There was some talk of merging imenu with Babel which would provide the functionality you describe, I don't believe this ever resulting in working code however. There are a couple of options... If you know the name of the code block you want to find you can use `org-babel-goto-named-src-block' (bound to C-c C-v g) to jump to a named code block (∃ a similar function for finding named results). Would anyone object if I change that function slightly so that it doesn't strip text properties, so that the search hits come up in the minibuffer with the in-context fontification? This function provides completion on the block names, the function `org-babel-src-block-names' returns a list of all named blocks in the current buffer, so it could be used to built up such a table. In fact the following code block will insert a table of such names in the current buffer. Note: you will need to pull the latest as I had to fix a small bug in `org-babel-src-block-names'. #+begin_src emacs-lisp :results list (mapcar #'list (reverse (org-babel-src-block-names))) #+end_src As a different approach, `occur' is good for doing this (results listed in a separate buffer with jump-back links). The function below can be extended in the obvious way. #+begin_src emacs-lisp (defun dan/find-in-buffer () (interactive) (let ((targets `((named src blocks . ,org-babel-src-name-regexp) (src block results . ,org-babel-result-regexp (occur (cdr (assoc (ido-completing-read Find: (mapcar #'car targets)) targets))) (other-window 1))) #+end_src Dan This is brilliant. Thanks. Having the table of contents, together with being able to jump to any block, is half the battle won! Using it already. eric ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: return link to :file when using #+call
Myles English mylesengl...@gmail.com writes: Thanks for your answer Eric. Recent changes as per http://thread.gmane.org/gmane.emacs.orgmode/35396 means that this no longer works. Thanks for bringing this up Myles. To recap: what I would like to do is to #+call an R source block, passing a filename, and have it write a plot to that file and also insert a link to that file in the org file. Any ideas? Here is what I have tried: #+source: foo() #+begin_src R :file bar.png :results graphics plot(1,1) #+end_src #+call: foo[:file baz.png]() #+results: foo[:file baz.png]() : baz.png baz.png contains a plot, but no file link is inserted. Yes you need :results file, so the line should be #+call: foo[:file baz.png]() :results file Explanation: In simple single-block usage, :file automatically sets :results file. But here :file in square brackets is passed to block foo, so the #+call line needs its own :results file. (And in fact :file would be wrong; see below). #+call: foo() #+results: foo() : bar.png bar.png contains a plot, but no file link is inserted. Yep. Same as above, except here you haven't overridden the file name. #+call: foo[:file biff.png]() :file biff.png #+results: foo[:file biff.png]() [[file:biff.png]] a file link is inserted but file biff.png contains 'biff.png' Right, this one's kind of instructive for understanding this stuff. Here, foo returns its file name as a string, so biff.png. The #+call line has been told to send its results to file with the :file argument, and it takes that literally, writing the string biff.png to its output file. So if what we want is a file containing graphics, we are not going to want :file on the #+call line. What we want is to interpret the string as a file name, and that's what :results file does. #+call: foo[:file pow.png]() :file pow.png :results graphics #+results: foo[:file pow.png]() [[file:pow.png]] a file link is inserted but file pow.png contains 'pow.png' Same as above. #+call receives a string from foo; it can't turn that string into the desired graphics. In fact, :results graphics currently only has any effect on an R block (i.e. at an R block, or passed to an R block inside [ ... ]). Dan Thanks, Myles On Wed, 05 Jan 2011 23:28:00 -0700 Eric Schulte schulte.e...@gmail.com wrote: Hi Myles, Currently I believe the best option is the solution you posted below, the file name is repeated because both the code block and the call line need to know the file name to create the file and the link respectively. Cheers -- Eric Myles English mylesengl...@gmail.com writes: Myles English mylesenglish at gmail.com writes: #+source: foo() #+begin_src R :file bar.png plot(1,1) #+end_src This works but I have to repeat the filename: #+call: foo[:file baz.png]() :file baz.png #+results: foo[:file baz.png]() [[file:baz.png]] Myles ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Several graphs in R
Rainer M Krug r.m.k...@gmail.com writes: Hi I just solved a problem of mine, i.e. how to deal with multiple graphs generated in an R script. OK - all are saved into separate pdfs in separate paths. But I would like to see them after they are generated - and this is my solution: #+begin_src R :results output path - ./ for (i in 1:10) { fn - paste(path, /, graph-, i, .pdf, sep=) pdf(fn) try( plot(runif(100)) ) dev.off() cat([[, fn, ]]\n, sep=) #=== here it is! } #+end_src Then in the results bluck, there will be links to all pdfs. Thought this might help somebody. Hi Rainer, Cool. You might want to experiment with :results output raw :results output org also (I suspect that strictly speaking those links should not be functioning as links inside an example block). Feel free to add useful tricks like this to the babel R page: http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html Dan Cheers, Rainer ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] PATCH: Support `org-export-process-option-filters' in latex export
`org-export-process-option-filters' is supported for HTML export but not for latex export. The patch at the bottom fixes that. I note that there is one other location in the same function where it seems the same change could be made. I suspect this is not necessary, but if someone is familiar with the org-latex code they might like to have a look. (I didn't manage to understand the roles of the several variables with names like *-opt-plist *-options-plist in that function.) I'm protecting this patch from patchwork with ^$; it's the patch at the bottom that I propose. $ diff --git a/lisp/org-latex.el b/lisp/org-latex.el $ index 51ee6d2..53d6b40 100644 $ --- a/lisp/org-latex.el $ +++ b/lisp/org-latex.el $ @@ -700,7 +700,8 @@ when PUB-DIR is set, use this as the publishing directory. $'(:org-license-to-kill nil $(org-update-radio-target-regexp) $(org-export-latex-set-initial-vars ext-plist arg) $ - (setq org-export-opt-plist org-export-latex-options-plist) $ + (setq org-export-opt-plist $ + (org-export-process-option-filters org-export-latex-options-plist)) $(org-install-letbind) $(run-hooks 'org-export-latex-after-initial-vars-hook) $(let* ((wcf (current-window-configuration)) $ Support `org-export-process-option-filters' in latex export * lisp/org-latex.el (org-export-as-latex): Process export property list with `org-export-process-option-filters' early in latex export Modified lisp/org-latex.el diff --git a/lisp/org-latex.el b/lisp/org-latex.el index ecaf1c0..51ee6d2 100644 --- a/lisp/org-latex.el +++ b/lisp/org-latex.el @@ -704,7 +704,8 @@ when PUB-DIR is set, use this as the publishing directory. (org-install-letbind) (run-hooks 'org-export-latex-after-initial-vars-hook) (let* ((wcf (current-window-configuration)) -(opt-plist org-export-latex-options-plist) +(opt-plist + (org-export-process-option-filters org-export-latex-options-plist)) (region-p (org-region-active-p)) (rbeg (and region-p (region-beginning))) (rend (and region-p (region-end))) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Worg needs some reorganizing
Jason Dunsmore emacs-orgm...@dunsmor.com writes: Eric Schulte schulte.e...@gmail.com writes: Matt Lundin m...@imapmail.org writes: Bastien bastien.gue...@wikimedia.fr writes: Jeff Horn jrhorn...@gmail.com writes: Jason seems to be garnering a lot of votes, but Eric's zenburn emulation makes my eyes happy. If Jason wins out, I suppose I could always just read Worg in emacs... :D Or use Eric zenburn-like css by selecting it as an alternative stylesheet in Firefox : View - Page Style - [select stylesheet]. I don't know how to make this choice persistent from Firefox and I don't know if this feature is available for other browsers, but it is certainly worth having several stylesheet available. Could we perhaps go ahead and put the new stylesheets on Worg along with alternate stylesheet links in the publishing preamble? That way we could begin to tweak the stylesheets as a community and test them on the fly. (It would also save Jason the work of having to publish to tmp directories.) Others would then be free to add their own stylesheets---though I suppose that adding alternate stylesheet links will require access to the publishing options on the server. Once we've decided on a default, we could then adjust the preamble accordingly and clean up the alternates. This sounds like a great approach to me. I'm convinced that there are other Org-mode users with much more sophisticated knowledge of CSS who may improve our initial efforts in time. One other alternative that comes to mind--while we're making impositions on Jason's kindness :)--is that it would be nice to have an alternate version of Worg published side-by-side with the original, only instead of publishing each page using org-publish-as-html, it could publish each page using only htmlize. That way we could show off how nice Org-mode syntax can be when viewed from inside of Emacs, and users could see a side-by-side between the plain-text and html versions. I strongly second this. In fact I'll stick my neck out more: Worg is great, but for tutorials on org-mode, HTML export is often the wrong format for obvious reasons (i.e. unless you go to some trouble, it conceals a lot of the org syntax). I'm tempted to suggest that htmlized output should be the default format for many org tutorials on Worg. An example of this approach done successfully is Dan's Babel example at http://www.stats.ox.ac.uk/~davison/software/org-babel/drift.org.html That sounds like a good idea. Do you know exactly how to do this? I believe I used this. I'd been meaning to look into adding something like this more formally to Org, but haven't got round to it. Htmlize with images Based on https://stat.ethz.ch/pipermail/ess-help/2009-August/005478.html by Vitalie S. #+begin_src emacs-lisp (defun dan/htmlize-buffer-with-org-images () Convert buffer to html, including embedded images. (interactive) (save-excursion (switch-to-buffer (htmlize-buffer (current-buffer))) (goto-char (point-min)) (while (re-search-forward span class=\org-link\file:\\(.+\\)/span nil t) (replace-match (concat img src='\\1'/) #+end_src Dan I added the following to org-publish-project-alist: (worg-htmlize :base-directory ~/git/Worg/ :base-extension org :html-extension org.html :publishing-directory /var/www/orgmode.org/worg/ :recursive t :htmlized-source t :publishing-function htmlize) But when I run: (defun publish-worg-htmlize nil Publish Worg. (interactive) (add-hook 'org-publish-after-export-hook 'worg-fix-symbol-table) (let ((org-format-latex-signal-error nil) (org-startup-folded nil)) (org-publish-project worg-htmlize))) I get the error Symbol's function definition is void: publish-htmlize. I made sure to (require 'htmlize). ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Worg needs some reorganizing
On Thu, Jan 20, 2011 at 5:02 PM, Jeff Horn jrhorn...@gmail.com wrote: On Thu, Jan 20, 2011 at 6:22 AM, Dan Davison dandavis...@gmail.com wrote: I strongly second this. In fact I'll stick my neck out more: Worg is great, but for tutorials on org-mode, HTML export is often the wrong format for obvious reasons (i.e. unless you go to some trouble, it conceals a lot of the org syntax). I'm tempted to suggest that htmlized output should be the default format for many org tutorials on Worg. I respectfully disagree with your assertion. When someone writes a document properly, i.e. in a literate fashion, i.e. using org source blocks, the right syntax is shown at the right time. So I think we both have babel documents in mind -- i.e. ones with active code blocks. The trouble with using org source blocks to render the org syntax in HTML is that the content must be duplicated. I know from experience that it is easy to let the pedagogical org block get out of sync with its functional counterpart. I did try to choose my words carefully -- I said tutorials, by which I meant the sort of documents demonstrating Org syntax that can be played with in the org source version. Not talking about the whole of Worg. Please see the manual as an example. Hmm? The manual is written in texinfo. Now, I'm no fan of nerfing choices in order to force anyone to do things The Right Way (tm), but it bears mentioning. I see no harm in publishing using org-publish-org-to-org with htmlize. We could even add a link in the footer or header of each page that links to the htmlized source. I do *not* agree in making it the default format for any page. To see examples of a document that would work better in htmlized format, look no further than http://orgmode.org/worg/org-contrib/babel/intro.html Scroll down to the ditaa section and infelicities start to appear. Someone (Eric or Tom) has done a good job of trying to make sure that an org src counterpart exists for each source block, but that is (a) hard work, (b) error prone and (c) cumbersome (what's the point of the non org src version?). And in the places which they missed, the document doesn't work well. E.g. look at the Capturing the Results of Code Evaluation section. Those two blocks are formatted in HTML only and its all a bit baffling as they appear the same (can't see the header args, which are the whole point of the example). All of which could be solved with some effort. My point is: what does the HTML export of this document really offer over the verbatim htmlized one? Dan -- Jeffrey Horn http://www.failuretorefrain.com/jeff/ ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Worg needs some reorganizing
On Thu, Jan 20, 2011 at 5:41 PM, Dan Davison dandavis...@gmail.com wrote: On Thu, Jan 20, 2011 at 5:02 PM, Jeff Horn jrhorn...@gmail.com wrote: On Thu, Jan 20, 2011 at 6:22 AM, Dan Davison dandavis...@gmail.com wrote: I strongly second this. In fact I'll stick my neck out more: Worg is great, but for tutorials on org-mode, HTML export is often the wrong format for obvious reasons (i.e. unless you go to some trouble, it conceals a lot of the org syntax). I'm tempted to suggest that htmlized output should be the default format for many org tutorials on Worg. I respectfully disagree with your assertion. When someone writes a document properly, i.e. in a literate fashion, i.e. using org source blocks, the right syntax is shown at the right time. So I think we both have babel documents in mind -- i.e. ones with active code blocks. The trouble with using org source blocks to render the org syntax in HTML is that the content must be duplicated. I know from experience that it is easy to let the pedagogical org block get out of sync with its functional counterpart. Another possibility is that a new header arg (perhaps :exports org) could be added to babel, which would have the effect of wrapping the block in an org src block on export. I did try to choose my words carefully -- I said tutorials, by which I meant the sort of documents demonstrating Org syntax that can be played with in the org source version. Not talking about the whole of Worg. Please see the manual as an example. Hmm? The manual is written in texinfo. Now, I'm no fan of nerfing choices in order to force anyone to do things The Right Way (tm), but it bears mentioning. I see no harm in publishing using org-publish-org-to-org with htmlize. We could even add a link in the footer or header of each page that links to the htmlized source. I do *not* agree in making it the default format for any page. To see examples of a document that would work better in htmlized format, look no further than http://orgmode.org/worg/org-contrib/babel/intro.html Scroll down to the ditaa section and infelicities start to appear. Someone (Eric or Tom) has done a good job of trying to make sure that an org src counterpart exists for each source block, but that is (a) hard work, (b) error prone and (c) cumbersome (what's the point of the non org src version?). And in the places which they missed, the document doesn't work well. E.g. look at the Capturing the Results of Code Evaluation section. Those two blocks are formatted in HTML only and its all a bit baffling as they appear the same (can't see the header args, which are the whole point of the example). All of which could be solved with some effort. My point is: what does the HTML export of this document really offer over the verbatim htmlized one? Dan -- Jeffrey Horn http://www.failuretorefrain.com/jeff/ ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Embedded code
Eric Schulte schulte.e...@gmail.com writes: Rainer M Krug r.m.k...@gmail.com writes: On 01/18/2011 12:48 AM, Eric Schulte wrote: Hi, This is possible using Babel, the attached org-mode file will execute its code block every time it is opened. You can replace the contents of the code block with any arbitrary elisp you would like to have executed in the file. To see this work, save the attached org-mode file to your system, open the file, answer y to allow execution, and then check your messages buffer for the I have been run message to see that the code block has in fact been evaluated. This is indeed very useful (e.g. if I open an R script, to open an R session and source the file). But it seems that all code blocks are evaluated on loading. Is there a way of only executing a specific code block? Yes, replace the # -*- eval: (org-babel-execute-buffer) -*- with # -*- eval: (save-excursion (org-babel-goto-named-src-block NAME) (org-babel-execute-src-block)) -*- I think `sbe' can be used here for a nice short version. E.g. # -*- eval: (sbe NAME) -*- or this at the end # Local variables: # eval:(sbe NAME) # End: where NAME is a double-quoted string. Dan where NAME is replaced with the name of the code block to execute. Cheers -- Eric ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [OT] Have you also got hooked by Vim?
Matt Lundin m...@imapmail.org writes: Marcelo de Moraes Serpa celose...@gmail.com writes: However, I've got hooked. Vim (in my case, MacVim) has conquered my hands. I know I'm risking myself a lot by saying it on an emacs-related mailing list, but the Vim navigation and the vim model in general is much more efficient for editing text. Empirical evidence? ;) FWIW, Org-mode has its own modal editing feature: org speed keys. This enables one to edit and reorganize the structure of org files with single keystrokes. So, how many of you here also use Vim? :) For quick editing (e.g., config files), I use vi(m). For anything else, I use emacs. Both are fantastic tools. Doesn't emacsclient make emacs just as quick for editing of random files encountered at the command line? If emacsclient is aliased to, say, 'e', and if the WM automatically shifts focus to the running emacs, then that should be pretty quick. Dan Best, Matt ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org fontifies outside of src blocks
Jeff Horn jrhorn...@gmail.com writes: Beautiful. Thanks, Tom! Hi Jeff, so you had two problems: 1. Erroneous fontification outside of blocks 2. Slowness and too much output to *Messages* I was aware that Tom's fix fixes (2) on OS X, but I haven't heard of (1) before. Isn't it a bit weird that the same fix should fix (1)? Dan On Sun, Jan 9, 2011 at 10:16 PM, Thomas S. Dye t...@tsdye.com wrote: Aloha Jeff, I think I had this issue. IIRC, this is a Mac issue. I think you can fix it with this: (setq font-lock-verbose nil) If not, let me know and I'll look harder. Tom On Jan 9, 2011, at 4:54 PM, Jeff Horn wrote: Hey list, I have an annoying issue. When in *either* Aquamacs or terminal emacs, if I view my init file (it's in org rather than elisp) and I edit *anything* in the buffer, org attempts to fontify the text as emacs-lisp. It takes a few seconds for anything to show up in windowed emacsen. Terminal experiences no lag, so it's less of an issue. After typing a sentences, the message buffer has tens of instances of the following text: Fontifying org-src-fontification:emacs-lisp-mode... (regexps.) Is this the expected behavior? I like fontification. I just only expect it to happen within a block, not outside of it. And yes, all of the blocks are closed correctly (I've double checked, but I used yasnippet to fill the buffer in the first place). Where should I start looking? :) -- Jeffrey Horn http://www.failuretorefrain.com/jeff/ ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org fontifies outside of src blocks
Thomas S. Dye t...@tsdye.com writes: Hi Dan and Jeff, I remember slow response time and output to *Messages* when working outside code blocks, but no erroneous fontification of text outside code blocks. My hunch at the time The slowness and superfluous output to *Messages* during fontification is something which emacs does on OS X which is not related to code blocks or Org-mode. I think the default value of `font-lock-verbose' should be changed to nil in emacs24. I'll suggest it. Dan was that emacs was determining what text to display and how to fontify it, and that it would do this regardless of whether code blocks were actually displayed. It has been a while since someone on the list pointed out the fix to me, but I haven't run into any problems since then and my buffers are fontified correctly. All the best, Tom On Jan 10, 2011, at 3:06 AM, Dan Davison wrote: Jeff Horn jrhorn...@gmail.com writes: Beautiful. Thanks, Tom! Hi Jeff, so you had two problems: 1. Erroneous fontification outside of blocks 2. Slowness and too much output to *Messages* I was aware that Tom's fix fixes (2) on OS X, but I haven't heard of (1) before. Isn't it a bit weird that the same fix should fix (1)? Dan On Sun, Jan 9, 2011 at 10:16 PM, Thomas S. Dye t...@tsdye.com wrote: Aloha Jeff, I think I had this issue. IIRC, this is a Mac issue. I think you can fix it with this: (setq font-lock-verbose nil) If not, let me know and I'll look harder. Tom On Jan 9, 2011, at 4:54 PM, Jeff Horn wrote: Hey list, I have an annoying issue. When in *either* Aquamacs or terminal emacs, if I view my init file (it's in org rather than elisp) and I edit *anything* in the buffer, org attempts to fontify the text as emacs-lisp. It takes a few seconds for anything to show up in windowed emacsen. Terminal experiences no lag, so it's less of an issue. After typing a sentences, the message buffer has tens of instances of the following text: Fontifying org-src-fontification:emacs-lisp-mode... (regexps.) Is this the expected behavior? I like fontification. I just only expect it to happen within a block, not outside of it. And yes, all of the blocks are closed correctly (I've double checked, but I used yasnippet to fill the buffer in the first place). Where should I start looking? :) -- Jeffrey Horn http://www.failuretorefrain.com/jeff/ ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [babel] How to fontify blocks other than begin_src?
Eric Schulte schulte.e...@gmail.com writes: Hi Seth, The easiest way to fontify embedded html is most likely to wrap the html in #+begin_src html code blocks. As for defining your own clojure blocks that sounds like a risky proposition to me. All of the code block evaluation functions are built to use standard org-mode syntax for code blocks, e.g. #+begin_src lang. For those who are interested in changing the appearance of Org elements for aesthetic reasons, there is Nicolas Girard's org-icons project, https://github.com/ngirard/org-icons which needs further work (i.e. needs to be adopted by someone) if it is to become generally useful. It aims to provide facilities for altering the display of arbitrary org elements, including the option of displaying icons in place of the text. In the branch named 'dan' I started to add support for begin_src blocks. Dan That said you can easily use clj as an alias for clojure in your code blocks, use the following elisp code to add this alias to org-src-lang-modes #+begin_src emacs-lisp (add-to-list 'org-src-lang-modes '(clj . clojure)) #+end_src Once that is done you will notice clj blocks like the one below are fontified. Also, after pulling the latest version of Org-mode (I just made a small change to make this possible), it is also possible to evaluate #+begin_src clj blocks as though they were regular clojure blocks. #+begin_src clj (map (partial + 1) (range 20)) #+end_src Hope this helps -- Eric Seth Burleigh wbur...@gmail.com writes: I would like blocks like begin_html/end_html to be fontified just like begin_src blocks are. I would also like to define my own source blocks for clojure (basically a shorthand) and also have them highlighted. Heres what i have to turn on fontifying and define a block. (setq org-src-fontify-natively t) ;; define #+clj as start of clojure code block and #+end as end of block (add-to-list 'org-edit-src-region-extra '(^[ \t]*#\\+clj.*\n \n[ \t]*#\\+end clojure)) Ive also noticed that the code block (#+clj ... #+end) doesnt fold - however, if i define the block as begin_clj and end_clj it will fold, so im guessing org assumes a certain block format for folding code. Any way to do the above two things? ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Images from R in LaTeX and PDF
Ben Ward benjamin.w...@bathspa.org writes: #+begin_src R :exports both full - read.csv(file=~/Documents/BSc Biology/Third Year/BY6001-40 - Dissertation/Data and Analysis/Evolution Results.csv, head=T) library(lattice) ecoli = subset(full, Bacterium==E.coli) edett = subset(ecoli, Cleaner==Dettol) egarl = subset(ecoli, Cleaner==Garlic) MIC.mod = lm(MIC. ~ 1+Challenge*Cleaner*Replicate, data=ecoli) #+end_src Hi Ben, Use the :width and :height header args to alter the dimensions of the graphics. The arguments go straight through to the R device, so if you are plotting to pdf they will be interpreted as inches (whereas they will be pixels for png, jpeg etc). With current Org, you will also need :results graphics in order to tell R to send graphics to the designated file. In addition, with lattice graphics, unless you are using :session, I believe you will need :results output (so :results output graphics). Do get back to us with any problems. There are several people who routinely use R to include graphics in Org documents. Dan p.s. Request to everyone: can we try as much as possible to use reproducible examples on-list? I.e. toy examples that anyone can execute, instead of real examples that rely on datasets that not everyone has access to. #+begin_src R :file fig1.pdf xyplot( MIC.+fitted(MIC.mod) ~ Challenge, data=ecoli, xlab=Challenge, ylab=MIC %, auto.key=TRUE) #+end_src #+attr_latex: width=0.6\textwidth wrap placement={h}{0.4\textwidth} #+label: fig:one #+caption: Linar Plot of real data and fitted model values #+results: fig1 [[file:fig1.pdf]] In the case of this code, actually altering size works, but it keeps putting the image at the end of my document. Then other images, placed with pretty much the same code, give or take for filenames and such, won't increace in size, but will alter their movement. I'm wondering if using pure latex for my images would be an easier solution. Cheers, Ben. On 07/01/2011 18:30, Thomas S. Dye wrote: Aloha Ben, Can you share an example that doesn't work for you? All the best, Tom On Jan 7, 2011, at 7:23 AM, Ben Ward wrote: Hi All, I've been doing some work with babel and R to generate graphs that I've then been including useing attr latex. But when I include images the always appear very very small, even when I mess about with the width settings of the attr latex line and remove the options for wrap and such. Does anybody else use R with images and org, and could tell me how they handle including R graphics in their documents? Thanks, Ben. W ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [babel] R: New handling of file output
Thomas S. Dye t...@tsdye.com writes: Aloha all, Here is an example of the new handling of file output with an R source code block that doesn't use base graphics: #+srcname: r-edge-angle-histogram #+begin_src R :results output graphics :var x=whole-adzes :file r/ adze_edge_angle.png :width 400 :height 300 library(ggplot2) adze.edge.angle - ggplot(x, aes(edge_angle)) adze.edge.angle + geom_histogram(aes(y=..density..)) + geom_density(weight=2) + xlab(Measured cutting edge angle (degrees)) #+end_src I was initially a bit baffled by this example. If anyone else is curious as to why, when graphics are generated by ggplot2, :results output is required in addition to :results graphics, please see Erik Iverson's original post on producing grid-based (e.g. lattice, ggplot2) R graphics with org-babel (bearing in mind of course that the header arg syntax has changed as per this thread). http://article.gmane.org/gmane.emacs.orgmode/26082 Dan #+results: [[file:r/adze_edge_angle.png]] Previously, the source line was: #+begin_src R :results output :var x=whole-adzes :file r/ adze_edge_angle.png :width 400 :height 300 The only change was to append graphics to :results output. All the best, Tom On Dec 21, 2010, at 6:57 AM, Dan Davison wrote: Dan Davison dandavis...@gmail.com writes: Please note the following changes to the way that org-babel handles file output. These may break existing org-babel files which use the :file header argument. :file filename should be understood as saying write the result to filename and return a link to filename. This works for all languages. For graphics languages (e.g. ditaa, dot, gnuplot) there is no change in behavior: result in the above is the graphics, and a link to the image is placed in the org buffer. For general-purpose languages (e.g. emacs-lisp, python, R, ruby, shell), the result written to file is the normal org-babel result (string, number, table). This is a backwards-incompatible change for R, which was previously interpreting :file to mean send graphics to file. I will send a separate email concerning R. Previously R understood :file filename to mean save graphics to filename[1]; now R behaves like other languages and sends the normal org-babel result to file (string, number, table). To tell R to save graphics[1] to file, use :results graphics. Some examples: Wrong! #+begin_src R :file img.png hist(rnorm(100)) img.png is going to contain this string. #+end_src Use :results graphics save graphics: #+begin_src R :file img.png :results graphics hist(rnorm(100)) But now img.png is going to contain graphics. #+end_src You may want to use `org-babel-default-header-args:R' to make this more convenient: #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:results . graphics))) #+end_src Alternatively the :results graphics header can be set in a property drawer for the subtree, or a #+babel: line, as usual. Now this will do what was intended #+begin_src R :file img.png hist(rnorm(100)) #+end_src Here is an example of saving something other than base graphics to file, and returning a link to the file. Note that :file is not used, and the filename must be returned. This could be used to save images created by non-base graphics libraries: #+begin_src R :results file :var file=savefile write.something.to.file - function(f) cat(hello, file=f) write.something.to.file(f=file) file #+end_src Dan * Footnotes [1] This only works for base graphics. In order to return a file link from a src block without telling babel to save any results to that file, use :results filename and do not use :file. The code block can of course write arbitrary content to filename. Some examples: Save the output of ls -l as a .csv file (recall that :results value is the default): #+begin_src sh :file dirlisting.csv :sep , ls -l #+end_src Send the text output of ls -l directly to file: #+begin_src sh :results output :file dirlisting.txt ls -l #+end_src Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Handling of errors when using Ledger
Eric S Fraga ucec...@ucl.ac.uk writes: Dan Davison dandavis...@gmail.com writes: Eric S Fraga ucec...@ucl.ac.uk writes: Dan dandavis...@gmail.com writes: [...] This patch should make ob-ledger use the common org-babel error mechanism. It is in branch ledger of the main repo. However, I'm not yet a ledger user. Could someone test it? Unfortunately, it doesn't work at all [1] for a very simple reason: you have removed the -f option which specifies the file that ledger should read. Hi Eric, Yes, ob-eval passes the src block body to the interpreter on standard input. I assumed that ledger would be able to read its transaction data from standard input. Is that not the case? What about with --file - or -f -? [...] If ledger can't read the src blocks body from stdin (and if it can't, I expect there's a good reason why not), then maybe this is a motivation for changing ob-eval so that the block body is read from file. Indeed, ledger cannot read from standard input. Hi Eric, I've asked on the ledger list and the 3.0 (and perhaps some older) versions of ledger do support -f - to read from stdin. Could you try this version of the patch? Thanks, Dan diff --git a/lisp/ob-ledger.el b/lisp/ob-ledger.el index a02eb6f..ef0f52e 100644 --- a/lisp/ob-ledger.el +++ b/lisp/ob-ledger.el @@ -43,24 +43,15 @@ '((:results . output) (:cmdline . bal)) Default arguments to use when evaluating a ledger source block.) +(defvar org-babel-ledger-command ledger + Command to invoke ledger) + (defun org-babel-execute:ledger (body params) Execute a block of Ledger entries with org-babel. This function is called by `org-babel-execute-src-block'. - (message executing Ledger source code block) - (let ((result-params (split-string (or (cdr (assoc :results params)) ))) - (cmdline (cdr (assoc :cmdline params))) -(in-file (org-babel-temp-file ledger-)) - (out-file (org-babel-temp-file ledger-output-))) -(with-temp-file in-file (insert body)) -(message (concat ledger - -f (org-babel-process-file-name in-file) - cmdline)) -(with-output-to-string - (shell-command (concat ledger - -f (org-babel-process-file-name in-file) - cmdline - (org-babel-process-file-name out-file -(with-temp-buffer (insert-file-contents out-file) (buffer-string + (org-babel-eval + (concat org-babel-ledger-command -f - (cdr (assoc :cmdline params))) + body)) From the man page: , | All commands require a Ledger data file which can be specified with -f | filename or via the LEDGER_FILE environment variable. ` and later: , | -f, --file FILE | | Reads FILE as a Ledger file. This option may be specified multiple | times. FILE may also be a list of file names separated by colons. | Typically, the environment variable LEDGER_FILE is set rather than | using this command-line option. ` Using an environment variable is not a good or viable solution for babel, as far as I can figure, and there does not seem to be any concept of - for standard input in lieu of a file. I cannot see any reason for this and, to be honest, I find it annoying [1] as a long time Unix user wishing to join tools together with pipes etc. But maybe John Wiegley had his reasons for taking this decision. Maybe he can comment on this... I think he reads this list? Incidentally, I have for a long time wondered whether we should permit src blocks to read *input data* from standard input. This would require altering ob-eval such that the src block body is read from file. Then we could do things like #+source: output-some-text #+begin_src sh :results output # print stuff #+end_src #+begin_src perl :stdin output-some-text while ( ) { # process the text } #+end_src This could be a solution. In thinking about all of my babel uses, this would have no impact on me but others may have different opinions? It would seem to be a safer route in any case? Thanks, eric Footnotes: [1] but not annoying enough to stop using ledger, of course, as it's a brilliant tool otherwise! ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] Skip source block fontification when the language is not defined
Bernt Hansen be...@norang.ca writes: * lisp/org.el: Skip source block fontification during export when language is not defined --- This may not be the correct fix for this issue but it works for me. Hi Bernt, I've checked in a slightly different version[1] of this fix. Thanks for the report; it wasn't nice to have been throwing errors every time an unrecognised (e.g. partial) language string was entered, even if most of the time font-lock was subduing these errors. Dan Footnotes: [1] I've made the org-src fontification function test, early on, whether the language major-mode function exists. If it doesn't then it returns immediately. This patch is available at git://git.norang.ca/org-mode.git fix-export -Bernt lisp/org.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 3cecca7..006e7bf 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5142,7 +5142,7 @@ will be prompted for. (add-text-properties end1 (+ end 1) '(face org-meta-line)) ; for end_src (cond -((and lang org-src-fontify-natively) +((and lang (not (string-equal lang )) org-src-fontify-natively) (org-src-font-lock-fontify-block lang block-start block-end)) (quoting (add-text-properties beg1 (+ end1 1) '(face ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Fontification of blocks
Sébastien Vauban wxhgmqzgw...@spammotel.com writes: Hi David, David O'Toole wrote: 2010/12/10 Sébastien Vauban wxhgmqzgw...@spammotel.com: In order to make the blocks stand out more clearly in the mix of prose, code and table results of many Babel Org files, I've added 2 new faces: - org-block-begin-line - org-block-end-line These apply to the line just before and after the block's body: I give a definite Vote++ to this feature! Thanks for the incentive. And happy to know it will please others as well... Hi Seb, Am I right in thinking that your work in this thread superseded the discussion in http://thread.gmane.org/gmane.emacs.orgmode/32880/focus=33924 and that therefore we should terminate patch http://patchwork.newartisans.com/patch/399/ and wait for you to finish up here? I'll look forward to the finished product. Thanks, Dan Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Problems with buffer-local variables
There's recently been some advocacy of using buffer-local variables for Org-mode configuration. It seems like a good idea to me. However, I think that it raises a problem: there are at least two situations in which Org internally spawns a buffer that is supposed to be a sort of copy of another Org buffer: these situations are export and org-src edit buffer. The problem is that the copy buffer doesn't inherit local variables from the parent buffer. It seems that either we should propagate all local variables in these cases (but I suspect that is inappropriate for some variables), or we have to have a rule for identifying the subset of local variables which need to be propagated. Below is one example which I think demonstrates a problem. If you evaluate the elisp block and then export to HTML, the noweb does not get expanded, because the configuration variable is buffer-local (behind the scenes, Org creates a buffer copy just before exporting a buffer). --8---cut here---start-8--- #+title: Local variables issues? Evaluate this block, then do C-c C-e h #+begin_src emacs-lisp :results silent :exports none (set-default 'org-babel-default-header-args:sh nil) (set (make-local-variable 'org-babel-default-header-args:sh) '((:noweb . yes))) #+end_src #+begin_src sh :exports both foo #+end_src #+source: foo #+begin_src sh :exports none echo hello #+end_src --8---cut here---end---8--- It's also a problem when spawning the org-src edit buffer. There is a patch in the pipeline that tries to identify all the necessary local variables and transmit them to the edit buffer: http://patchwork.newartisans.com/patch/438/ That's a bit messy, but in the export case it seems even harder to identify all variables that might need to be transmitted. What is a good solution? Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] Skip source block fontification when the language is not defined
Bernt Hansen be...@norang.ca writes: Dan Davison dandavis...@gmail.com writes: Bernt Hansen be...@norang.ca writes: * lisp/org.el: Skip source block fontification during export when language is not defined --- This may not be the correct fix for this issue but it works for me. Hi Bernt, I've checked in a slightly different version[1] of this fix. Thanks for the report; it wasn't nice to have been throwing errors every time an unrecognised (e.g. partial) language string was entered, even if most of the time font-lock was subduing these errors. Dan Footnotes: [1] I've made the org-src fontification function test, early on, whether the language major-mode function exists. If it doesn't then it returns immediately. Thanks Dan, Your fix works for me :). I'm confused about _why_ I'm getting these errors though - I was expecting fontification only to apply to #+begin_src blocks and I'm only using a few languages in that document (sh, org, emacs-lisp, ditaa, and dot). Unless it's picking up on the begin_src in the following text Hi Bernt, I was wondering about the same thing. How about hacking the org-src-font-lock-fontify-block function so that it throws an error with a helpful message when the language string is unrecognised? I just tried this on your document with C-c C-e h and it didn't throw anything, but maybe in your setup it will? (Check the *Messages* buffer, it may be that font-lock handles the error). I've prepended the below with $ to stop patchwork from grabbing it. $ diff --git a/lisp/org-src.el b/lisp/org-src.el $ index f55e292..0d796b4 100644 $ --- a/lisp/org-src.el $ +++ b/lisp/org-src.el $ @@ -781,7 +781,9 @@ fontification of code blocks see `org-src-fontify-block' and $ (add-text-properties $ start end $ '(font-lock-fontified t fontified t font-lock-multiline t)) $ - (set-buffer-modified-p modified) $ + (set-buffer-modified-p modified)) $ + (error Unrecognised language: %s line: %d $ +lang (line-number-at-pos (point)) Dan , | I use this to create =#+begin_*= blocks like | - =#+begin_example= | - =#+begin_ditaa= | - =#+begin_dot= | - =#+begin_src= | - etc. ` I wasn't able to determine the source line of the problem from the stack dump information. Is there any way to determine what part of the document is causing this (other than manually bisecting and exporting with missing sections) ? Regards, Bernt ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Need help with org and SSH
Jeff Horn jrhorn...@gmail.com writes: Hey orgsters, For the holiday trip, I decided to see if I could go a week with only the Cr-48. I left my Macbook at home ready for SSH, just in case. It took approximately 30 minutes of using the computer before I started itching for org. I've been having a heck of a time using emacs in the terminal. After a few hours of cleaning up my init file and wrapping lots of commands in window-system conditionals, I thought I was ready to invoke agenda. Wrong! Invoking agenda gives me the same error I was having with emacs-desktop. Specifically, I keep getting the error (void function clear-image-cache). Any idea what switch to flip to get the agenda open? lgrep comes up with two occurrences of that function in org-mode/lisp for me: org.el:15935: (if (and overlays (fboundp 'clear-image-cache)) (clear-image-cache)) org.el:16200:(clear-image-cache)) The second one is lacking the fboundp protection. Does it help if you put the fboundp test in, as below? diff --git a/lisp/org.el b/lisp/org.el index 3cecca7..b27f376 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16197,7 +16197,7 @@ BEG and END default to the buffer boundaries. (interactive P) (unless refresh (org-remove-inline-images) -(clear-image-cache)) +(if (fboundp 'clear-image-cache) (clear-image-cache))) (save-excursion (save-restriction (widen) Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Need help with org and SSH
Jeff Horn jrhorn...@gmail.com writes: On Wed, Dec 22, 2010 at 12:49 PM, Dan Davison dandavis...@gmail.com wrote: The second one is lacking the fboundp protection. Does it help if you put the fboundp test in, as below? Dan, Thanks for the suggestion. I tried the patch and got a huge backtrace full of binary characters. So it sounds like the patch fixed the void-function error. Bernt's suggestion of (setq org-startup-with-inline-images nil) would have had a similar effect. I don't know under what circumstances / type of emacs clear-image-cache is undefined, but I suspect this patch should be applied. Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [babel] New handling of file output
Please note the following changes to the way that org-babel handles file output. These may break existing org-babel files which use the :file header argument. :file filename should be understood as saying write the result to filename and return a link to filename. This works for all languages. For graphics languages (e.g. ditaa, dot, gnuplot) there is no change in behavior: result in the above is the graphics, and a link to the image is placed in the org buffer. For general-purpose languages (e.g. emacs-lisp, python, R, ruby, shell), the result written to file is the normal org-babel result (string, number, table). This is a backwards-incompatible change for R, which was previously interpreting :file to mean send graphics to file. I will send a separate email concerning R. In order to return a file link from a src block without telling babel to save any results to that file, use :results filename and do not use :file. The code block can of course write arbitrary content to filename. Some examples: Save the output of ls -l as a .csv file (recall that :results value is the default): #+begin_src sh :file dirlisting.csv :sep , ls -l #+end_src Send the text output of ls -l directly to file: #+begin_src sh :results output :file dirlisting.txt ls -l #+end_src Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [babel] R: New handling of file output
Dan Davison dandavis...@gmail.com writes: Please note the following changes to the way that org-babel handles file output. These may break existing org-babel files which use the :file header argument. :file filename should be understood as saying write the result to filename and return a link to filename. This works for all languages. For graphics languages (e.g. ditaa, dot, gnuplot) there is no change in behavior: result in the above is the graphics, and a link to the image is placed in the org buffer. For general-purpose languages (e.g. emacs-lisp, python, R, ruby, shell), the result written to file is the normal org-babel result (string, number, table). This is a backwards-incompatible change for R, which was previously interpreting :file to mean send graphics to file. I will send a separate email concerning R. Previously R understood :file filename to mean save graphics to filename[1]; now R behaves like other languages and sends the normal org-babel result to file (string, number, table). To tell R to save graphics[1] to file, use :results graphics. Some examples: Wrong! #+begin_src R :file img.png hist(rnorm(100)) img.png is going to contain this string. #+end_src Use :results graphics save graphics: #+begin_src R :file img.png :results graphics hist(rnorm(100)) But now img.png is going to contain graphics. #+end_src You may want to use `org-babel-default-header-args:R' to make this more convenient: #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:results . graphics))) #+end_src Alternatively the :results graphics header can be set in a property drawer for the subtree, or a #+babel: line, as usual. Now this will do what was intended #+begin_src R :file img.png hist(rnorm(100)) #+end_src Here is an example of saving something other than base graphics to file, and returning a link to the file. Note that :file is not used, and the filename must be returned. This could be used to save images created by non-base graphics libraries: #+begin_src R :results file :var file=savefile write.something.to.file - function(f) cat(hello, file=f) write.something.to.file(f=file) file #+end_src Dan * Footnotes [1] This only works for base graphics. In order to return a file link from a src block without telling babel to save any results to that file, use :results filename and do not use :file. The code block can of course write arbitrary content to filename. Some examples: Save the output of ls -l as a .csv file (recall that :results value is the default): #+begin_src sh :file dirlisting.csv :sep , ls -l #+end_src Send the text output of ls -l directly to file: #+begin_src sh :results output :file dirlisting.txt ls -l #+end_src Dan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Can't close Emacs+org-mode if /tmp and /home on different partitions
Antti Kaihola akaih...@gmail.com writes: I have /tmp on my root partition and a separate partition for /home. When trying to close an Emacs session which is using org-mode, I get this error: move-file-to-trash: Non-regular file: Is a directory, /tmp/babel-XXX (where XXX are random characters). I tracked down the problem to org-babel-remove-temporary-directory which ob.el adds to kill-emacs-hook. It tries to remove the temporary directory using delete-directory, which in turn tries to move the directory (by renaming) into trash, which is in my home directory. I've just added some exception handling which should allows Emacs to close down (without removing the temporary directory) in this situation. Thanks for the clear report. Dan Here's the debugger traceback: Debugger entered--Lisp error: (file-error Non-regular file Is a directory /tmp/babel-4893rR1) rename-file(/tmp/babel-4893rR1 /home/akaihola/.local/share/Trash/files/babel-4893rR1_4893HqQ) move-file-to-trash(/tmp/babel-4893rR1) delete-directory(/tmp/babel-4893rR1) (progn (mapc (lambda ... ...) (directory-files org-babel-temporary-directory ... ^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*)) (delete-directory org-babel-temporary-directory)) (if (and (boundp ...) (file-exists-p org-babel-temporary-directory)) (progn (mapc ... ...) (delete-directory org-babel-temporary-directory))) (when (and (boundp ...) (file-exists-p org-babel-temporary-directory)) (mapc (lambda ... ...) (directory-files org-babel-temporary-directory ... ^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*)) (delete-directory org-babel-temporary-directory)) org-babel-remove-temporary-directory() eval((org-babel-remove-temporary-directory)) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp nil nil) I added this to my ~/.emacs.d/init.el: (custom-set-variables '(temporary-file-directory /home/akaihola/tmp/)) and closing Emacs works correctly again. However, since my init.el is part of emacs-starter-kit which I update frequently, I'd prefer not to modify that file. Unfortunately the customization hook emacs-starter-kit provides (~/.emacs.d/custom.el) is loaded too late to affect the temporary directory. I'm running emacs-snapshot 1:20090909-1 in Ubuntu 10.10. Looks like this is really an Emacs bug and is already fixed: http://groups.google.com/group/gnu.emacs.bug/browse_thread/thread/0446b8684a8ef504 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Babel, Python and UTF-8
Eric Schulte schulte.e...@gmail.com writes: Vincent Beffara vbeff...@ens-lyon.fr writes: Hi, (and it would be excellent to allow for a code block as a preamble, instead of a string in the header or as an alternative, because preambles once they are allowed tend to grow uncontrollably ;-) This is currently possible using the `sbe' function. Arbitrary emacs lisp can be placed inside of header arguments, and the `sbe' take the name of a code block and returns its result. This makes me think of another good use of the sbe (src block eval) function. I'm often seeing Org documents with a src block like this, #+source: essential-document-config #+begin_src emacs-lisp ;; some essential document-specific configuration #+end_src and some instructions saying something like To use this document, first evaluate this code block. This can be automated by using sbe in a local variables line at the end of the Org file: # Local variables: # eval:(sbe essential-document-config) # End: When the file is first opened, Emacs will evaluate the set-up blocks (after asking for confirmation). This isn't restricted to configuration of Emacs variables with emacs-lisp blocks; eval lines could reference blocks in any language, for example to start an ESS session and run some preparatory code, etc, e.g. #+source: document-config #+begin_src emacs-lisp (set (make-local-variable 'org-edit-src-content-indentation) 0) #+end_src #+source: start-ess #+begin_src R :session *R session* a - 1 #+end_src # Local variables: # eval:(sbe document-config) # eval:(sbe start-ess) # End: Dan Very cool ! That does all I want, thanks for the info. For multi-line it is a bit heavy to write, with lots of \n and preamble .= lskjd, but I can live with that. Unless there is a way already to write something like this ? #+source: my-preamble #+begin_src python :return preamble # -*- coding: utf-8 -*- import os,sys,whatever #+end_src #+begin_src python :preamble (org-babel-get-and-expand-source-code-body my-preamble) :return s s = é #+end_src There is org-babel-get-src-block-info but it looks at the block around (point), not by name ... so I guess it would not be too hard to write the extraction method, but it might be somewhere in the code already. Yes, the following uses an internal Babel function, but is probably much simpler #+results: my-preamble : # -*- coding: utf-8 -*- : import os,sys,whatever #+begin_src python :preamble (org-babel-ref-resolve my-preamble) :return s s = #+end_src Note that as written this will return the following python error Traceback (most recent call last): File stdin, line 2, in module ImportError: No module named whatever One naive question : why is the code path different for tangling and evaluation ? One would think that a natural way for evaluation would be to tangle the current block (plus included noweb stuff etc) into a temporary file and eval that file ... and that would enable shebang for evaluation as well. There must be something I am missing here. Tangling works for *any* programming language, even those which have yet to be created and have no explicit Emacs or Org-mode support, this is because on tangling the code block is simply treated as text. As far as I understood from testing, tangling does adapt to the language (at least to implement :var in a suitable way), so I was under the impression that evaluating could be implemented as some kind of wrapping around the tangled output - and obviously the wrapping would have to be language-specific even if for the most part the tanglong is not. Yes, some language specific features (e.g. variable expansion) can be used by the tangling mechanisms if such features are defined for the language in question, however tangling can be done in the absence of any language specific features and thus works for any arbitrary language. That shebang and preamble should remain separate for the other reasons mentioned in my previous email. I am just discovering all of this, sorry if I have horrible misconceptions about the thing ... No problem, it is a fairly (but I don't think overly) complex system. Regards, /v ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Babel, Python and UTF-8
Thomas S. Dye t...@tsdye.com writes: Hi Dan, Emacs configuration is one of the highest barriers to entry for potential adopters of Org-mode, IMO. The idea of context-sensitive configuration is potentially terrific. It gets the user to work more quickly than would otherwise be the case. The problem I've run into is that exiting a buffer doesn't change the configuration back to some initial, or base, state. I'm on to the next task but still configured to do the last thing. Hi Tom, I think someone else suggested using buffer-local variables to address this problem, and I think that's the correct suggestion. One of the examples below shows how to set a buffer-local value: [...] #+source: document-config #+begin_src emacs-lisp (set (make-local-variable 'org-edit-src-content-indentation) 0) #+end_src As it happens, for that particular setting to be useful requires a patch that is pending review, but, in general, I think this is the way to do what you're describing. Dan #+source: start-ess #+begin_src R :session *R session* a - 1 #+end_src # Local variables: # eval:(sbe document-config) # eval:(sbe start-ess) # End: Dan Very cool ! That does all I want, thanks for the info. For multi- line it is a bit heavy to write, with lots of \n and preamble .= lskjd, but I can live with that. Unless there is a way already to write something like this ? #+source: my-preamble #+begin_src python :return preamble # -*- coding: utf-8 -*- import os,sys,whatever #+end_src #+begin_src python :preamble (org-babel-get-and-expand-source-code- body my-preamble) :return s s = é #+end_src There is org-babel-get-src-block-info but it looks at the block around (point), not by name ... so I guess it would not be too hard to write the extraction method, but it might be somewhere in the code already. Yes, the following uses an internal Babel function, but is probably much simpler #+results: my-preamble : # -*- coding: utf-8 -*- : import os,sys,whatever #+begin_src python :preamble (org-babel-ref-resolve my- preamble) :return s s = #+end_src Note that as written this will return the following python error Traceback (most recent call last): File stdin, line 2, in module ImportError: No module named whatever One naive question : why is the code path different for tangling and evaluation ? One would think that a natural way for evaluation would be to tangle the current block (plus included noweb stuff etc) into a temporary file and eval that file ... and that would enable shebang for evaluation as well. There must be something I am missing here. Tangling works for *any* programming language, even those which have yet to be created and have no explicit Emacs or Org-mode support, this is because on tangling the code block is simply treated as text. As far as I understood from testing, tangling does adapt to the language (at least to implement :var in a suitable way), so I was under the impression that evaluating could be implemented as some kind of wrapping around the tangled output - and obviously the wrapping would have to be language-specific even if for the most part the tanglong is not. Yes, some language specific features (e.g. variable expansion) can be used by the tangling mechanisms if such features are defined for the language in question, however tangling can be done in the absence of any language specific features and thus works for any arbitrary language. That shebang and preamble should remain separate for the other reasons mentioned in my previous email. I am just discovering all of this, sorry if I have horrible misconceptions about the thing ... No problem, it is a fairly (but I don't think overly) complex system. Regards, /v ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Orgmode and Unicode characters
Eric Schulte schulte.e...@gmail.com writes: My only worry on this front is that I know how to type | and - for tables, and how to type * for headings, but I don't have an easy way to type utf8 characters. If Org-mode starts using exotic utf8 characters which can not easily be typed from outside of Org-mode then it loses some of the it's all plain text appeal. I agree with Darlan that something using Emacs display functionality (like used by org-pretty-entities) could be preferable because it would Hi Eric, I've never quite understood how the pretty entities stuff works. Is it related to text (display) properties or overlays? Would you mind giving a quick explanation? Dan preserve the underlying text. Best -- Eric Darlan Cavalcante Moreira darc...@gmail.com writes: If changing the actual character in the file is be the best option (maybe it could cause problems for the exporters), then an approach similar to org-pretty-entities could be used for this. -- Darlan At Mon, 6 Dec 2010 11:19:55 +0200, Dov Grobgeld dov.grobg...@gmail.com wrote: Even though this announcement looks very cool, this again reminded me of something I've been thinking off when using orgmode. And that is the use of unicode characters. With the latest versions of emacs that support unicode and with rich fonts such as DejaVu Monospace, it is as easy to use unicode characters as ascii. What I was thinking of is that the current ascii graphics of e.g. tables could automatically be switched to box drawing characters (http://en.wikipedia.org/wiki/Box-drawing_characters) when pressing C-c or Tab. Other characters that could be used are automatic replacement of leading asterisks to various bullets. Each indentation level could be given a different bullets. E.g. *==▸, **==●, etc. I'm sure that arrows and various brackets may also be useful for various contexts. Of course the use of these characters would be configurable and would be turned off automatically for buffers that are not UTF-8 encoded. Perhaps I'll one day learn the inner workings of org-mode sufficiently to do this myself, but if there is someone who meanwhile wants to pick up the idea, you're welcome! Regards, Dov On Mon, Dec 6, 2010 at 09:05, Nathan Neff nathan.n...@gmail.com wrote: Much easier to read, and I love the nesting/indenting of sub-headings. http://nateneff.com/ - Need to understand org-mode-clockreport-rules.htmlhttp://nateneff.com/org-mode-clockreport-rules.html --Nate ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] org-edit-src-code
Sometimes one wants to set `org-edit-src-content-indentation' for a single buffer, without running the risk of altering the indentation in other files. At the moment it's not possible to use a buffer-local value for that variable, because the buffer-local value is not inherited correctly by the org-src edit buffer. This patch fixes that. It also substantially tidies up the code in org-edit-src-code. It changes quite a few lines in the function, so if any src block users could stick the patch in their set ups and watch for problems that would be good. Dan commit 85597d28b25f4e64d535f61d2115ed2069a28be8 Author: Dan Davison dandavis...@gmail.com Date: Fri Dec 3 18:24:38 2010 + Reorganize org-edit-src-code; allow buffer-local `org-edit-src-content-indentation' * lisp/org-src.el (org-edit-src-code): When generating the code edit buffer, it is necessary for several variables to inherit their values from the parent org buffer. These changes collect all such variables together into a single association list of (variable-name value) pairs. In addition, a new variable is added to the list: `org-edit-src-content-indentation'. This has the effect that a buffer local value can be used for that variable. diff --git a/lisp/org-src.el b/lisp/org-src.el index fd827f9..06d0297 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -215,14 +215,12 @@ buffer. (let ((mark (and (org-region-active-p) (mark))) (case-fold-search t) (info (org-edit-src-find-region-and-lang)) - (babel-info (org-babel-get-src-block-info 'light)) - (org-mode-p (eq major-mode 'org-mode)) + (org-mode-p (org-mode-p)) (beg (make-marker)) (end (make-marker)) - (preserve-indentation org-src-preserve-indentation) (allow-write-back-p (null code)) block-nindent total-nindent ovl lang lang-f single lfmt buffer msg - begline markline markcol line col) + begline markline markcol line col transmitted-variables) (if (not info) nil (setq beg (move-marker beg (nth 0 info)) @@ -236,10 +234,22 @@ buffer. (nth 2 info)) lang (if (symbolp lang) (symbol-name lang) lang) single (nth 3 info) - lfmt (nth 4 info) block-nindent (nth 5 info) lang-f (intern (concat lang -mode)) - begline (save-excursion (goto-char beg) (org-current-line))) + begline (save-excursion (goto-char beg) (org-current-line)) + transmitted-variables + `((org-edit-src-content-indentation + ,org-edit-src-content-indentation) + (org-edit-src-force-single-line ,single) + (org-edit-src-from-org-mode ,org-mode-p) + (org-edit-src-allow-write-back-p ,allow-write-back-p) + (org-src-preserve-indentation ,org-src-preserve-indentation) + (org-src-babel-info ,(org-babel-get-src-block-info 'light)) + (org-coderef-label-format + ,(or (nth 4 info) org-coderef-label-format)) + (org-edit-src-beg-marker ,beg) + (org-edit-src-end-marker ,end) + (org-edit-src-block-indentation ,block-nindent))) (if (and mark (= mark beg) (= mark (1+ end))) (save-excursion (goto-char (min mark end)) (setq markline (org-current-line) @@ -279,27 +289,23 @@ buffer. (define-key map [mouse-1] 'org-edit-src-continue) map)) (overlay-put ovl :read-only Leave me alone) + (setq transmitted-variables + (append transmitted-variables `((org-edit-src-overlay ,ovl (org-src-switch-to-buffer buffer 'edit) (if (eq single 'macro-definition) (setq code (replace-regexp-in-string n \n code t t))) (insert code) (remove-text-properties (point-min) (point-max) '(display nil invisible nil intangible nil)) - (unless preserve-indentation + (unless (cadr (assq 'org-src-preserve-indentation transmitted-variables)) (setq total-nindent (or (org-do-remove-indentation) 0))) (let ((org-inhibit-startup t)) (condition-case e (funcall lang-f) (error (error Language mode `%s' fails with: %S lang-f (nth 1 e) - (set (make-local-variable 'org-edit-src-force-single-line) single) - (set (make-local-variable 'org-edit-src-from-org-mode) org-mode-p) - (set (make-local-variable 'org-edit-src-allow-write-back-p) allow-write-back-p) - (set (make-local-variable 'org-src-preserve-indentation) preserve-indentation) - (when babel-info - (set (make-local-variable 'org-src-babel-info) babel-info)) - (when lfmt - (set (make-local-variable 'org-coderef-label-format) lfmt)) + (dolist (pair transmitted-variables) + (org-set-local (car pair) (cadr pair
[Orgmode] Re: [Babel] No output returned if just one command is failing
Hi Seb, I definitely have some sympathy with your request. On two occasions I've had to manually make this change just to carry on working. The change I made is straightforward if you need it as a temporary hack: --8---cut here---start-8--- diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el index 8832d91..1cce003 100644 --- a/lisp/ob-eval.el +++ b/lisp/ob-eval.el @@ -57,7 +57,7 @@ STDERR with `org-babel-eval-error-notify'. (progn (with-current-buffer err-buff (org-babel-eval-error-notify exit-code (buffer-string))) - nil) + (buffer-string)) (buffer-string) (defun org-babel-eval-read-file (file) --8---cut here---end---8--- But do we actually change babel in this direction? It's important to distinguish between :results output and :results value here. The change that seems superficially attractive is to allow :results output to output the contents of standard output, even if there has been an error. After all, stdout might contain some useful data, and currently babel refuses point blank to give it to you if there's been an error. And as you say, this is the behavior we are used to in the shell. This hypothetical change would leave the default :results value alone (so the above patch would need modification). The thing is that babel currently has a clear, simple, rule which says: if there's an error, the result is the elisp value nil. Eric and I have discussed in the past whether there should be any change in this direction. The idea of a :debug header arg has been floated, that would allow this behavior. Or tacking stdout on to the error output. I tend to think that the behavior you request does need to be made available, somehow, whether by default or not. Dan Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hi Eric, Eric Schulte wrote: I don't forsee adding partial results insertion both because - it would add a good deal of complexity to the code to insert results part-way through a run I can't comment on this, of course. - the current behavior of only inserting results on a fully successful run is reasonable and is probably more obvious (at least to me) than inserting partial results Being fond of Babel, I'm using it always, everywhere. I prefer: 1. typing my shell commands in an Org buffer, 2. evaluate the block, 3. get the results automagically inserted in the buffer, 4. (eventually, version the whole file for later comparisons when updating the code), 5. export the whole to HTML and/or PDF. The current behavior, even if totally respectable and defendable, inhibits such a way of working: if you write (or update) a shell code, and don't see (more or less) the same things as the ones you would see in a shell buffer, then you can't use such an Org buffer -- as long as one command fails. I don't especially want you to change your position, but I'm explaining the negative consequences for me. Thanks! Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Babel, Python and UTF-8
Eric Schulte schulte.e...@gmail.com writes: Hi, I've just pushed up a new prefix header argument. preamble might be a better name? or header? prefix makes me think of adding a string onto the front of a string[1]; preamble and header are used by e.g. latex to refer to prelimary lines at the top of a file. For obscure options like this it might be OK to use a longer name (e.g. :header-line), especially now we have multiline header args with #+header. This header argument only has meaning for python code blocks but might in the future be used by others? Dan [1]: accurate i know, but many people won't think of a block as a character string. (since it is tied into evaluation each language would have to handle it separately). This is only used during external evaluation (i.e. not when :session is specified) and the value of the :prefix argument is prepended to the temporary file evaluated by python. The following demonstrate its usage: ** Python requires a utf-8 coding prefix #+begin_src python :prefix # -*- coding: utf-8 -*- :return s s = é #+end_src #+results: : é #+begin_src python :prefix # -*- coding: utf-8 -*- :results output s = é print(s) #+end_src #+results: : é Best -- Eric Vincent Beffara vbeff...@ens-lyon.fr writes: Hi, I would suggest just trying it out first and seeing if you get an error without such a line. Well, I do, that's why I'm asking ;-) Also, you could try adding the line to the beginning of your code block. I tried like this : #+begin_src python # -*- coding: utf-8 -*- s = é #+end_src The error message tells me that the error happens on line 4, hence the coding line ends up on line 3, and python only takes it into account if it is one of the first two ... so it almost works, but it doesn't. If there is definitely a problem please reply to this thread and we could easily add a header argument for this case, possibly named :prefix which could be used to specify such a code-block-prefix for code evaluation. This header argument could then be set globally or on the file, heading, or code block level. That would be fantastic ! (And possibly useful in other cases as well ...) Thanks, /vincent ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] No output returned if just one command is failing
Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hi Eric and Dan, Dan Davison wrote: Sébastien Vauban wrote: Eric Schulte wrote: I don't forsee adding partial results insertion both because - it would add a good deal of complexity to the code to insert results part-way through a run I can't comment on this, of course. - the current behavior of only inserting results on a fully successful run is reasonable and is probably more obvious (at least to me) than inserting partial results Being fond of Babel, I'm using it always, everywhere. I prefer: 1. typing my shell commands in an Org buffer, 2. evaluate the block, 3. get the results automagically inserted in the buffer, 4. (eventually, version the whole file for later comparisons when updating the code), 5. export the whole to HTML and/or PDF. The current behavior, even if totally respectable and defendable, inhibits such a way of working: if you write (or update) a shell code, and don't see (more or less) the same things as the ones you would see in a shell buffer, then you can't use such an Org buffer -- as long as one command fails. I don't especially want you to change your position, but I'm explaining the negative consequences for me. I definitely have some sympathy with your request. On two occasions I've had to manually make this change just to carry on working. But do we actually change babel in this direction? [...] The thing is that babel currently has a clear, simple, rule which says: if there's an error, the result is the elisp value nil. Eric and I have discussed in the past whether there should be any change in this direction. The idea of a :debug header arg has been floated, that would allow this behavior. Or tacking stdout on to the error output. I tend to think that the behavior you request does need to be made available, somehow, whether by default or not. If find this conclusion a bit contradictory with the fact that you even needed it yourself. Hey Seb -- you mis-read me there. I was agreeing with you that the behavior should be made available. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Reporting 2 problems of code execution
Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hi Charles, Thanks a lot for taking a look at this, too... Charles C. Berry wrote: On Sun, 28 Nov 2010, Sébastien Vauban wrote: Hi Eric and Dan, * Abstract Reporting two problems: Did you mean to include :results output in the headers? You're right that could be it. I often forget about adding that setting, even though it's more or less mandatory for the sh blocks -- at least, in many sh blocks I write... When I do that in eaco of the src blocks I get what I think you were expecting. I still don't. See below. 1. parsing problem of unescaped text from a shell block 2. end marker repeated upon execution of elisp block Note that I added the RESULT thing in my default headers. * Data Let's say I want to grep trough arbitrary text, such as: #+results:a-couple-of-lines : He said I'll do it : but that cannot be echo'ed! ... or to let it scanned by AWK for post-processing (like generating some DOT representation). But, first, as errors are popping up, let's say I can just output it as is. * Shell code #+begin_src sh :var data=a-couple-of-lines :exports both echo $data #+end_src #+results: #+BEGIN_RESULT #+END_RESULT #+begin_src sh :results output :var data=a-couple-of-lines :exports both echo $data #+end_src #+results: : He said I'll do it : but that cannot be echo'ed! It does not work for me. With the above, I (still) get: #+results: #+BEGIN_RESULT #+END_RESULT for results, and, in the *Org-Babel Error Output*: sh: line 3: unexpected EOF while looking for matching `'' sh: line 7: syntax error: unexpected end of file Hi Seb, Just to say that these blocks with embedded quotes are outputting OK for me on linux, but I do see the second bug you mention (repeatedly adding new lines on each execution). I'm guessing that the first one is a difference in shell quoting behaviour between out operating systems. Dan The data is impossible (*for me*, as is) to print out from a shell code. Though, it is in Emacs-Lisp... without any change. Note that it's the second *single quote* only that's causing a problem, not the first one... * Emacs-Lisp code Executing this: #+begin_src emacs-lisp :var data=a-couple-of-lines :exports both (prin1-to-string data) #+end_src #+results: #+BEGIN_RESULT #+begin_example He said \I'll do it\ but that cannot be echoed! #+END_RESULT#+end_example #+end_example #+end_example #+end_example #+end_example #+end_example #+end_example #+end_example #+end_example works, but the *end marker is repeated* as long as we re-execute the block. #+begin_src emacs-lisp results output :var data=a-couple-of-lines :exports both (prin1-to-string data) #+end_src #+results: : He said \I'll do it\ : but that cannot be echo'ed! With or without the :results output (BTW, notice you've forgotten the colon in front of results), the result is the same. But, if you evaluate the block multiple times, in my case, the end marker (end_example) is still repeated... Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Generated images in buffer
Eric Schulte schulte.e...@gmail.com writes: You can place the ditaa code into a code block and then evaluate the code block with C-c C-c. This will insert a link to the generated image into your Org-mode file. If you then turn on inline images with M-x org-toggle-inline-images you can preview the generated image from within your Org-mode buffer. Hi Dov, Following on from the above, you can make the images in the emacs buffer automatically refresh[1] after execution with (add-hook 'org-babel-after-execute-hook 'org-display-inline-images) Dan Footnotes: [1] On reading the docstring, one might think that this would be the right code, but it doesn't seem to refresh the image: (add-hook 'org-babel-after-execute-hook (lambda () (org-display-inline-images nil t))) For more information on code blocks see http://orgmode.org/manual/Working-With-Source-Code.html#Working-With-Source-Code Best -- Eric Dov Grobgeld dov.grobg...@gmail.com writes: Thanks! So it possible for LaTeX, but not for other image generators. That's a bit unfair. How difficult would it be to generalize this so that it would support any image generator? Regards, Dov On Sun, Nov 28, 2010 at 09:34, Jeff Horn jrhorn...@gmail.com wrote: On Sun, Nov 28, 2010 at 2:04 AM, Dov Grobgeld dov.grobg...@gmail.com wrote: The same idea could be used for any system generating images, e.g. LaTeX formulas, asymptote, a python script using cairo, etc. I think evaluating Babel code blocks can insert output into your org-file. Also, I regularly use =C-c C-x C-l= to display rendered LaTeX equations in-buffer. That keystroke only displays the current subtree's equations. With a prefix, it will generate previews for the entire document. Best, Jeff -- Jeffrey Horn Graduate Lecturer and PhD Student in Economics George Mason University (704) 271-4797 jh...@gmu.edu jrhorn...@gmail.com http://www.failuretorefrain.com/jeff/ ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Generated images in buffer
Dov Grobgeld dov.grobg...@gmail.com writes: Thanks! This is exactly what I was looking for. And indeed it is as easy to output a graph from python (or any other language) as it is from ditaa: * A ditaa image #+begin_src ditaa :file example.png [...] * A Python image #+begin_src python :file circle.png [...] I'm wondering over one thing though. When exporting to HTML, the ditaa source code is omitted, but the python source code is included. Is there any way of controlling this in begin_src? Hi Dov, Yes, see the documentation of the :exports header argument. http://orgmode.org/manual/Exporting-code-blocks.html#Exporting-code-blocks Header arguments such as :exports can be set in various different ways. http://orgmode.org/manual/Using-header-arguments.html#Using-header-arguments The difference in behavior you see stems from the value of the variable org-babel-default-header-args, and the language-specific versions of that variable. Note below that although :exports in general defaults to code, for ditaa this default is overridden to results. The reason for which was that ditaa code is typically going to be there to generate graphics, whereas that is only occasionally true for python. #+begin_src emacs-lisp :results pp org-babel-default-header-args #+end_src #+results: : ((:session . none) : (:results . replace) : (:exports . code) : (:cache . no) : (:noweb . no) : (:hlines . no) : (:tangle . no)) #+begin_src emacs-lisp :results pp org-babel-default-header-args:ditaa #+end_src #+results: : ((:results . file) : (:exports . results)) #+begin_src emacs-lisp :results pp org-babel-default-header-args:python #+end_src #+results: : nil Dan Thanks! Dov On Sun, Nov 28, 2010 at 19:27, Dan Davison dandavis...@gmail.com wrote: (add-hook 'org-babel-after-execute-hook (lambda () (org-display-inline-images nil t))) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Handling of errors when using Ledger
Eric S Fraga ucec...@ucl.ac.uk writes: Dan dandavis...@gmail.com writes: [...] This patch should make ob-ledger use the common org-babel error mechanism. It is in branch ledger of the main repo. However, I'm not yet a ledger user. Could someone test it? Unfortunately, it doesn't work at all [1] for a very simple reason: you have removed the -f option which specifies the file that ledger should read. Hi Eric, Yes, ob-eval passes the src block body to the interpreter on standard input. I assumed that ledger would be able to read its transaction data from standard input. Is that not the case? What about with --file - or -f -? Incidentally, I have for a long time wondered whether we should permit src blocks to read *input data* from standard input. This would require altering ob-eval such that the src block body is read from file. Then we could do things like #+source: output-some-text #+begin_src sh :results output # print stuff #+end_src #+begin_src perl :stdin output-some-text while ( ) { # process the text } #+end_src If ledger can't read the src blocks body from stdin (and if it can't, I expect there's a good reason why not), then maybe this is a motivation for changing ob-eval so that the block body is read from file. Dan Ledger does not interpret a file argument directly but needs the -f option, as in: ledger -f file.ledger rest of command line Note the second line in the concatenated list of strings below: [...] -(with-output-to-string - (shell-command (concat ledger - -f (org-babel-process-file-name in-file) - cmdline - (org-babel-process-file-name out-file I am not sure how you pass this option with the much shorter code you have written: + (org-babel-eval + (concat org-babel-ledger-command (cdr (assoc :cmdline params))) + body)) I hope this makes sense? Footnotes: [1] actually, what does work very nicely indeed is that error messages are reported perfectly!! So thank you very much for this. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-babel problem
Erik Butz erik.b...@googlemail.com writes: Hi, people with more git experience should comment here, but it seems with: ~/elisp/org-mode $ git status you will get a list of currently untracked files in the local working directory. These are of course both files or directories deleted from the repository (as /lisp/babel) but also files that you included locally to extend your local installation. In my case the above yielded: # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # Makefile.old # contrib/docbook2twiki.xsl # contrib/lisp/org-taskjuggler.el # lisp/babel/ # lisp/org-R.el # lisp/org-twiki.el nothing added to commit but untracked files present (use git add to track) so the lisp/babel directory shows up there. In principle there is git clean, but looking at what it would do: git clean -n Would remove Makefile.old Would remove contrib/docbook2twiki.xsl Would remove contrib/lisp/org-taskjuggler.el Would not remove lisp/babel/ Would remove lisp/org-R.el Would remove lisp/org-twiki.el it explicitly states that it would NOT remove the lisp/babel directory. Hi Eric, See the -d option to git clean , | -d Remove untracked directories in addition to untracked files. If an |untracked directory is managed by a different git repository, |it is not removed by default. Use -f option twice if you |really want to remove such a directory. ` I believe that this is a correct solution, seeing as git status is showing you that the directory is not currently being tracked. As to how it managed to persist on your file system despite it being deleted in the org repo, not sure. Dan But at least both these things can tell you what is maybe still there but not actually in the repository anymore (+your personal files). If anyone has a good way to keep the installation clean w/o having to make a new clone each time, any hints would be appreciated ;) Thanks, Erik On Fri, Nov 26, 2010 at 11:45 AM, Sebastian Hofer sebho...@gmail.com wrote: For the record, I was having the exact same problem, just didn't have the time to post it. So it's not just you! I just deleted the babel directory now everything is fine again. git didn't even notice it was gone. Thanks for finding the culprit! Sebastian At Thu, 25 Nov 2010 22:04:22 +0100, Erik Butz wrote: Hi, thanks for the replies. It obviously was something stupid. I did not execute babel code for quite some time, and for some reason I still had a (setq load-path (cons /home/erik/elisp/org-mode/lisp/babel load-path)) in my .emacs and apparently I did not clean up enough and so the ob.elc file in that directory then shadowed the one in the /lisp directory. I tried a clean 'git clone' and there it worked and indeed that directory is not even there. How would I remove that old /lisp/babel directory using git? Typically I just do a 'git pull' and then 'make clean' 'make' to update, but that obviously can lead to problems. Thanks again, Erik 2010/11/25 Sébastien Vauban wxhgmqzgw...@spammotel.com: Hi Erik, Erik Butz wrote: I am trying to run some org-babel code, but while this used to work in the past, I am now getting an error which says Symbol's function definition is void: org-babel-get-header The function is defined in my installation. Git version of yesterday. Somehow I am puzzled, since this function is defined in lisp/ob.el and since this file provides 'ob and I have (require 'ob) in my .emacs I don't see why this should happen. Are you sure it really *is* loaded? What happens if you C-x C-e after the require line? Is there any check I should perform to see where and why this is failing? I am using GNU Emacs 23.1. with Org-mode version 7.3 (release_7.3.130.g9cc1) even though I somehow suspect that it's not either of the software versions that is responsible for this. Any hints appreciated. Maybe you code post your block, or a stripped down version of it, if you want me to try and use it? In any case, AFAIK, it /should/ not fail here with the above message... Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list
[Orgmode] Re: org-babel problem
Erik Butz erik.b...@googlemail.com writes: Hi all, I am trying to run some org-babel code, but while this used to work in the past, I am now getting an error which says Symbol's function definition is void: org-babel-get-header Somehow I am puzzled, since this function is defined in lisp/ob.el and since this file provides 'ob and I have (require 'ob) in my .emacs I don't see why this should happen. Is there any check I should perform to see where and why this is failing? Hi Erik, Apologies if this is obvious, but are you sure you don't have out of date *.elc files in org-mode/lisp? Try manually deleting the *.elc, or running 'make clean', to get rid of them and then restart org (C-c C-x !). If that works then optionally run make again to recompile them. Dan I am using GNU Emacs 23.1. with Org-mode version 7.3 (release_7.3.130.g9cc1) even though I somehow suspect that it's not either of the software versions that is responsible for this. Any hints appreciated. Thanks, Erik ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [OT] retrieving old messages [WAS] Re: [Babel] Handling of errors when using Ledger
Bernt Hansen be...@norang.ca writes: Dan dandavis...@gmail.com writes: Incidentally, can any gnus users tell me -- is there a non-painful way of retrieving an old message from nntp in order to create a reply in the correct thread? Or do you hack the headers to make it appear in the right thread? I'm using the gmane web interface to send this. I read the list through gnus and gmane. When I'm in the summary buffer for the org-mode list I can retrieve old messages with / O 500 RET to get the last 500 messages from the list. Thanks Bernt and Seb, but that was the route I was referring to when I said painful :) The list volume is quite high, and retrieving thousands of messages takes a while. And of course you go for 1500 and it turns out to be message 1728... It seems a rather primitive practice, can we really not do better? Is it not possible to use a unique identifier to pull down a specific message? (I was not reading usenet or whatever it was called in the 1980s; I don't really know anything about these technologies.) Dan Then you can limit the displayed messages by some filter (say subject) with / / filter text RET On a message ^ will retrieve the previous message in the thread and you can do that repeatedly to get the entire thread displayed. Then I just reply normally to a specific message with S W and It Just Works(tm) HTH, Bernt ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Accepted] Re: In-buffer completion
Hi Carsten, Here's another completion bug: #+sou plot-fitted-mode If I put point after the u of #+sou and hit M-TAB, I get concat: Wrong type argument: char-or-string-p, nil in `org-command-at-point'. The reason is that `thing' in that function gets set equal to (file-option) and so (downcase (cdr thing)) fails on the nil cdr. I'm not sure what's supposed to happen here really, so over to you. Dan Carsten Dominik cdomi...@newartisans.com writes: Patch 396 (http://patchwork.newartisans.com/patch/396/) is now Accepted. Maintainer comment: No comment This relates to the following submission: http://mid.gmane.org/%3C874obblwa8.fsf%40gmail.com%3E Here is the original message containing the patch: Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Orgmode] Re: In-buffer completion Date: Sat, 20 Nov 2010 22:50:07 - From: Dan Davison dandavis...@gmail.com X-Patchwork-Id: 396 Message-Id: 874obblwa8@gmail.com To: Carsten Dominik carsten.domi...@gmail.com Cc: John Wiegley jwieg...@gmail.com, Org Mode emacs-orgmode@gnu.org Carsten Dominik carsten.domi...@gmail.com writes: Dear all, yesterday I replaced the previous implementation of in-buffer completion (M-TAB of Esc TAB) with a new function making use of John Wiegleys pcomplete.el. In fact, John did most of the Org-related implementation already months ago - I only tied up some loose ends. So if you are noticing something unexpected in in-buffer completion, this is the cause. There may be bugs, if you find any, let me know. Most importantly, however, in-buffer completion is now implement so much cleaner, and we can extend it if we want. So if you have good ideas where in-buffer completion would be useful and does not work already, lets hear it! Hi Carsten, That looks nice. Here's a few #+ keywords I notice are missing. (Shouldn't more of these entries have a terminal colon?) Dan Thanks to John for yet another great addition to Org mode. - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode diff --git a/lisp/org.el b/lisp/org.el index c634a6c..917a368 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10547,9 +10547,14 @@ This function can be used in a hook. BEGIN_VERSE END_VERSE BEGIN_CENTER END_CENTER BEGIN_SRC END_SRC +SOURCE: SRCNAME: FUNCTION: +RESULTS: +HEADER: HEADERS: +BABEL: CATEGORY COLUMNS PROPERTY CAPTION LABEL SETUPFILE +INCLUDE: BIND MACRO)) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Error output buffer
Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hi, A quick wished feature, if you agree on its usefulness. Currently, all error messages are concatenated to the same buffer, execution after execution, which makes it *difficult to distinguish between the new errors*, and the ones already seen previously. Hi Seb, I agree, that had been bothering me too. I had fixed it a week or so ago in my local set up, and I've just pushed that to master. It wipes the error buffer clean at the start of execution (on C-c C-c, and during export). Dan Different propositions: - delete the contents of the buffer before every code execution - add something visible after every execution, like a separator line or a ^L character (new page, than can easily be displayed as a rule) - always show the last lines in a different color - in the same spirit, use two alternate colors for the messages (like in some HTML tables, for odd/even rows) - add a timestamp with the date, before every code execution. This is not exhaustive, just some (funny for some of them) ideas I have in mind in order to make the messages more visible than they currently are. Thanks. Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Error output buffer
Hi Eric, Seb, I'd actually just pushed my local fix that I had made to this so far. Our emails crossed because mine is being held up by gmane as I forgot to switch the obfuscated gmane reply address for the normal list address, but here's what will come through eventually: , | Hi Seb, | | I agree, that had been bothering me too. I had fixed it a week or so ago | in my local set up, and I've just pushed that to master. It wipes the | error buffer clean at the start of execution (on C-c C-c, and during | export). | | Dan ` Hopfully this is a step in the right direction, although it doesn't resolve all the problems you outline. Dan Eric Schulte schulte.e...@gmail.com writes: This is something that Dan and I have discussed as well. On the one hand it would be nice to wipe the buffer between block executions, but on the other hand when you are say exporting a file and running many code blocks at once it would be preferable to retain error messages from all of the code blocks. I've been thinking that either a we could delete the buffer form all manual entry points into code block execution so that it is refreshed between manual code block execs but not between automated (e.g. on export) code block execs. Another option would be to separate the error messages with timestamps as you've proposed, and maybe with some mark that can be jumped to with a keystroke. I'm not sure which approach would be best. -- Eric Sébastien Vauban wxhgmqzgw...@spammotel.com writes: Hi, A quick wished feature, if you agree on its usefulness. Currently, all error messages are concatenated to the same buffer, execution after execution, which makes it *difficult to distinguish between the new errors*, and the ones already seen previously. Different propositions: - delete the contents of the buffer before every code execution - add something visible after every execution, like a separator line or a ^L character (new page, than can easily be displayed as a rule) - always show the last lines in a different color - in the same spirit, use two alternate colors for the messages (like in some HTML tables, for odd/even rows) - add a timestamp with the date, before every code execution. This is not exhaustive, just some (funny for some of them) ideas I have in mind in order to make the messages more visible than they currently are. Thanks. Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] Two minor issues
Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hi Dan, (resending this, as it seems to never have reached the ML) Could you tell me what I should do with the random characters in the addresses that appear in your emails? I've deleted the addresses and just sending to emacs-orgmode@gnu.org, is that OK? Dan Davison wrote: Sébastien Vauban writes: Dan Davison wrote: ... Honestly, the way I update that code has been mainly done by sequences of trials and errors. The above code is, for me, still quite complex to understand with vars such as beg, beg1, end, end1 for which I hadn't completely understood the meaning. This seems to work -- could you try it out? --8---cut here---start-8--- diff --git a/lisp/org.el b/lisp/org.el index e2de48e..0b082da 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5102,9 +5102,6 @@ will be prompted for. (add-text-properties beg end '(font-lock-fontified t font-lock-multiline t)) - (add-text-properties beg beg1 '(face org-meta-line)) - (add-text-properties end1 (+ end 1) '(face org-meta-line)) - ; for end_src (cond ((and lang org-src-fontify-natively) (org-src-font-lock-fontify-block lang block-start block-end)) @@ -5117,6 +5114,8 @@ will be prompted for. (add-text-properties beg1 end1 '(face org-quote))) ((string= block-type verse) (add-text-properties beg1 end1 '(face org-verse + (add-text-properties beg beg1 '(face org-meta-line)) + (add-text-properties (1+ end) (1+ end1) '(face org-meta-line)) t)) ((member dc1 '(title: author: email: date:)) (add-text-properties --8---cut here---end---8--- Dan Otherwise, I would even have proposed a renaming of some of them. But, I think that whatever we do, such a code will stay complex to understand and change. Find here a picture of what we see (since my patch) without native fontification. http://www.mygooglest.com/sva/No-Native-Fontification.png Also, a picture with the new setting of native fontification. http://www.mygooglest.com/sva/Native-Fontification-Minibug.png Hope this helps. If you need help, I'm willing to take a look back a it (still trying and testing the effect of changes), but it won't be before a couple of days. Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode