Re: [O] [babel] Producing figures from octave

2011-08-31 Thread Dan Davison
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

2011-08-18 Thread Dan Davison
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

2011-06-11 Thread Dan Davison
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

2011-05-20 Thread Dan Davison
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

2011-03-04 Thread Dan Davison
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

2011-03-01 Thread Dan Davison
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

2011-02-28 Thread Dan Davison
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

2011-02-27 Thread Dan Davison
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

2011-02-26 Thread Dan Davison
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

2011-02-22 Thread Dan Davison
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

2011-02-21 Thread Dan Davison
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)

2011-02-16 Thread Dan Davison
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

2011-02-16 Thread Dan Davison
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

2011-02-16 Thread Dan Davison
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

2011-02-16 Thread Dan Davison
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

2011-02-15 Thread Dan Davison
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?

2011-02-14 Thread Dan Davison
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?

2011-02-14 Thread Dan Davison
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

2011-02-14 Thread Dan Davison
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?

2011-02-13 Thread Dan Davison
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

2011-02-13 Thread Dan Davison
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

2011-02-13 Thread Dan Davison
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?

2011-02-12 Thread Dan Davison
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?

2011-02-12 Thread Dan Davison
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

2011-02-12 Thread Dan Davison
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

2011-02-12 Thread Dan Davison
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

2011-02-12 Thread Dan Davison
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

2011-02-11 Thread Dan Davison
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

2011-02-11 Thread Dan Davison
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

2011-02-11 Thread Dan Davison
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

2011-02-11 Thread Dan Davison
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

2011-02-11 Thread Dan Davison
[...]
 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

2011-02-11 Thread Dan Davison
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

2011-02-10 Thread Dan Davison
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

2011-02-10 Thread Dan Davison
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

2011-02-10 Thread Dan Davison
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?

2011-02-10 Thread Dan Davison
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

2011-02-09 Thread Dan Davison
 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

2011-02-09 Thread Dan Davison
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

2011-02-09 Thread Dan Davison
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

2011-02-09 Thread Dan Davison
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

2011-02-09 Thread Dan Davison
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

2011-02-09 Thread Dan Davison
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

2011-02-08 Thread Dan Davison
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

2011-02-04 Thread Dan Davison
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

2011-02-04 Thread Dan Davison
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

2011-02-04 Thread Dan Davison
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?

2011-02-04 Thread Dan Davison
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?

2011-02-03 Thread Dan Davison
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

2011-02-02 Thread Dan Davison
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

2011-02-02 Thread Dan Davison
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

2011-02-01 Thread Dan Davison
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

2011-02-01 Thread Dan Davison
 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

2011-02-01 Thread Dan Davison
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

2011-02-01 Thread Dan Davison
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

2011-01-31 Thread Dan Davison
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

2011-01-30 Thread Dan Davison
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?

2011-01-27 Thread Dan Davison
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

2011-01-24 Thread Dan Davison
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

2011-01-23 Thread Dan Davison
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

2011-01-21 Thread Dan Davison
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

2011-01-21 Thread Dan Davison
`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

2011-01-20 Thread Dan Davison
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

2011-01-20 Thread Dan Davison
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

2011-01-20 Thread Dan Davison
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

2011-01-19 Thread Dan Davison
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?

2011-01-19 Thread Dan Davison
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

2011-01-10 Thread Dan Davison
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

2011-01-10 Thread Dan Davison
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?

2011-01-08 Thread Dan Davison
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

2011-01-08 Thread Dan Davison
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

2011-01-06 Thread Dan Davison
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

2010-12-23 Thread Dan Davison
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

2010-12-22 Thread Dan Davison
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

2010-12-22 Thread Dan Davison
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

2010-12-22 Thread Dan Davison
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

2010-12-22 Thread Dan Davison
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

2010-12-22 Thread Dan Davison
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

2010-12-22 Thread Dan Davison
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

2010-12-21 Thread Dan Davison
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

2010-12-21 Thread Dan Davison
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

2010-12-08 Thread Dan Davison
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

2010-12-06 Thread Dan Davison
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

2010-12-06 Thread Dan Davison
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

2010-12-06 Thread Dan Davison
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

2010-12-03 Thread Dan Davison
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

2010-12-02 Thread Dan Davison
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

2010-12-02 Thread Dan Davison
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

2010-12-02 Thread Dan Davison


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

2010-11-29 Thread Dan Davison


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

2010-11-28 Thread Dan Davison
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

2010-11-28 Thread Dan Davison
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

2010-11-26 Thread Dan Davison
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

2010-11-26 Thread Dan Davison
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

2010-11-25 Thread Dan Davison
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

2010-11-25 Thread Dan Davison
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

2010-11-25 Thread Dan Davison
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

2010-11-24 Thread Dan Davison


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

2010-11-23 Thread Dan Davison
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

2010-11-22 Thread Dan Davison
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


  1   2   3   4   5   6   >