[Orgmode] Re: Bug: export aborts if ':eval query/never' in source code blocks

[Paul Sexton]

Eric Schulte  gmail.com> writes:

> 
> I've just pushed up a fix for this issue. For more information see
> http://eschulte.github.com/babel-dev/DONE-eval-and-noeval.html

Wow, that was fast!
Thanks very much.

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

Re: [Orgmode] Re: a bit offtopic, fonts in exported PDF documents

[Nick Dokos]

Nick Dokos  wrote:

> the original Knuth fonts were Type3,
> 

That, of course, is nonsense: the original Knuth fonts were born
before Adobe existed. They were in a format that Knuth invented
(PK?). They could just naturally be mapped into Adobe Type3
fonts by dvips, so they could be printed on the original Apple
Laser Printer, when that came out.

Nick

___
Emacs-orgmode 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: problem with babel and R

[Eric Schulte]

Oh no!

It appears this solution may have been too clever for it's own good.

Thanks for suggesting ":results silent" as an additional default header
argument, that appears to fixed this weird behavior.

I've just pushed up that fix.

Cheers -- Eric

David Hajage  writes:

> One comment:
>
> When I execute all the buffer (org-babel-execute-buffer), the result is:
>
> #+begin_src R :results output org :exports both
> library(ascii)
> options(asciiType = "org")
> ascii(head(esoph, 3))
> #+end_src
>
> #+results:
> #+BEGIN_SRC org
> |   | agegp | alcgp | tobgp| ncases | ncontrols |
> |---+---+---+--++---|
> | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
> | 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
> | 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
> #+END_SRC
>
> #+results:
> |   | agegp | alcgp |tobgp | ncases | ncontrols |
> |---+---+---+--++---|
> | 1 | 25-34 | 0-39g/day | 0-9g/day |   0.00 | 40.00 |
> | 2 | 25-34 | 0-39g/day |10-19 |   0.00 | 10.00 |
> | 3 | 25-34 | 0-39g/day |20-29 |   0.00 |  6.00 |
>
> Then, the results is repeated twice in the buffer. I understand why, but
> perhaps the "silent" option should be turned on by default for org code
> blocks?
>
> David
>
>
> On Thu, Aug 26, 2010 at 23:51, David Hajage  wrote:
>
>> Oups, I forgot ob-org in my .emacs... OK, now, really sorry for this.
>> David
>>
>>
>>
>> On Thu, Aug 26, 2010 at 22:20, David Hajage  wrote:
>>
>>> I am so sorry to bother you again, but I must miss something.
>>>
>>> When I write:
>>>
>>> #+begin_src R :results output org :exports both
>>> library(ascii)
>>> options(asciiType = "org")
>>> ascii(head(esoph))
>>> #+end_src
>>>
>>> The results is:
>>>
>>> #+results:
>>> #+BEGIN_SRC org
>>> |   | agegp | alcgp | tobgp| ncases | ncontrols |
>>> |---+---+---+--++---|
>>> | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
>>> | 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
>>> | 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
>>> | 4 | 25-34 | 0-39g/day | 30+  | 0.00   | 5.00  |
>>> | 5 | 25-34 | 40-79 | 0-9g/day | 0.00   | 27.00 |
>>> | 6 | 25-34 | 40-79 | 10-19| 0.00   | 7.00  |
>>> #+END_SRC
>>>
>>> OK, the result is surrounded by BEGIN_SRC org/END_SRC. But when I export
>>> this, the results is exported as fontified org code. What should I do to
>>> have this result interpreted as org markup?
>>> David
>>>
>>>
>>>
>>> On Thu, Aug 26, 2010 at 18:10, Eric Schulte wrote:
>>>
 Hi,

 A fix to this issue has been pushed up to the repository.  As can now be
 read in the documentation of the `org-babel-insert-result' function [1],
 there is now a subtle distinction between ":results org" and ":results
 raw", where ":results org" will wrap code block results in a "begin_src
 org" block.  The block wrapper makes it possible for the entirety of the
 results to be located and removed by Babel upon code block
 re-evaluation.

 In addition a new ob-org.el file has been added providing support for
 evaluation of Org-mode blocks.  With this new language support loaded
 the above technique becomes a working replacement for ":results raw"
 allowing the body of the org code block to be interpreted as inline
 org-mode text on export.  This is done through some non-standard default
 header arguments described in the recent commit message (see [2])

 Best -- Eric

 "Eric Schulte"  writes:

 > Hi David,
 >
 > "#+end_results: foo" (or some derivative syntax) sounds like a good
 > idea, I'll add it to the Babel task list.
 >
 > Thanks -- Eric
 >
 > David Hajage  writes:
 >
 >> OK, I understand that using ":results org", the results is not
 altered,
 >> there is no post processing. But I don't want a post processing, I
 would
 >> like a way to tell babel where is the begining *and the end* of the
 output
 >> produces by a particular R source block. I think an "#+end_results:
 foo" at
 >> the end of the output could do the job. Then, the option "replace"
 could
 >> work in all situation, even if a blank line is inserted somewhere in
 the org
 >> output. No?
 >> David
 >>
 >>
 >> On Tue, Aug 17, 2010 at 17:15, Eric Schulte 
 wrote:
 >>
 >>> Hi David,
 >>>
 >>> David Hajage  writes:
 >>>
 >>> > Thank you very much for your answer.
 >>> >
 >>>
 >>> My pleasure
 >>>
 >>> >
 >>> > But when I run the following code directly into R, no extra lines
 is
 >>> >added
 >>> > by the ascii function:
 >>> >> library(ascii)
 >>> > Le chargement a nécessité le package : proto
 >>> >> options(asciiType = "org")
 >>> >> ascii(head(esoph)) # no extra line
 >>> > |   | agegp

Re: [Orgmode] Bug: export aborts if ':eval query/never' in source code blocks

[Eric Schulte]

Hi Erik,

Erik Iverson  writes:

> Eric,
>
> As a follow-up on a related issue:
>
> What if I want to eval a code block for some side-effect, but
> *not* include code or results in export. This assumes I'm using
> :session.
>
> Is there a way to currently do that?
>

this should be possible using the :results silent header argument, for
example the following should give the desired behavior

--8<---cut here---start->8---
** eval for side effect on export
- one plus one
  #+source: one-plus-one
  #+begin_src emacs-lisp :exports none :results silent
(+ 1 1)
  #+end_src
- plus one is
  #+begin_src emacs-lisp :var two=one-plus-one :exports both
(+ 1 two)
  #+end_src
--8<---cut here---end--->8---

Cheers -- Eric

>
> Setting :exports none seems to block evaluating of the code,
> can the :eval argument 'override' that so the block is
> eval'd, but no export is produced.
>
> In R, I currently can just put the last line of the block
> I want this behavior for as
>
> NULL
>
> with :exports results
>
> and it seems to do what I want.  Just wondering if there was
> a more 'official' way?
>
> Here's a sample file that seems to do as I want, with the
> NULL trick.  Just wonder if :eval can help at all.
>
> * I want only the 2nd block exported
>
> #+begin_src R :exports results :session
>
> x <- 2 + 3
> NULL
>
> #+end_src
>
> #+begin_src R :session :exports results
>
> x
>
> #+end_src
>
>
> Eric Schulte wrote:
>> Hi Paul,
>>
>> This is on the top of the stack for Babel bug fixes (see [1]), and I
>> hope to have a solution pushed up to the git repository soon.  I'll
>> reply to this email when this issue is resolved.
>>
>> Thanks -- Eric
>>
>> Paul Sexton  writes:
>>
>>> #+BEGIN_SRC R :eval query
>>> ...
>>> #+END_SRC
>>>
>>> If the above is in an org file, the user runs an export (C-c C-e), and the 
>>> user
>>> types 'no' when asked whether to evaluate the code block, then the whole 
>>> export
>>> process is aborted (no further blocks are processed and no export output is
>>> produced).
>>>
>>> The same thing happens with ':eval never'.
>>>
>>> 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
>>
>> Footnotes: [1]
>> http://eschulte.github.com/babel-dev/STARTED-How-to-quietly-exclude-block-from-evaluation-.html
>>
>>
>> ___
>> Emacs-orgmode 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] Bug: export aborts if ':eval query/never' in source code blocks

[Eric Schulte]

I've just pushed up a fix for this issue. For more information see
http://eschulte.github.com/babel-dev/DONE-eval-and-noeval.html

Cheers -- Eric

"Eric Schulte"  writes:

> Hi Paul,
>
> This is on the top of the stack for Babel bug fixes (see [1]), and I
> hope to have a solution pushed up to the git repository soon.  I'll
> reply to this email when this issue is resolved.
>
> Thanks -- Eric
>
> Paul Sexton  writes:
>
>> #+BEGIN_SRC R :eval query
>> ...
>> #+END_SRC
>>
>> If the above is in an org file, the user runs an export (C-c C-e), and the 
>> user
>> types 'no' when asked whether to evaluate the code block, then the whole 
>> export
>> process is aborted (no further blocks are processed and no export output is
>> produced).
>>
>> The same thing happens with ':eval never'.
>>
>> 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
>
> Footnotes: 
> [1]  
> http://eschulte.github.com/babel-dev/STARTED-How-to-quietly-exclude-block-from-evaluation-.html

___
Emacs-orgmode 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: a bit offtopic, fonts in exported PDF documents

[Nick Dokos]

Erik Iverson  wrote:


> Is the following correct?
> 
> Some Type 1 fonts *support* the T1 encoding.  Computer Modern is
> not one of those, so you need some that do.  CM-super or Latin
> Modern are two Type 1 font packages that do support the T1 encoding.
> 

No, "supporting" an encoding makes no sense. The encoding is a map from
(a range of) integers to glyphs. Computer modern is available in both
OT1 and T1 encodings. It is also available as Type1 and Type3 and also
as TrueType (which is not an Adobe format at all): the original Knuth
fonts were Type3, but Y&Y/Blue Sky produced, and eventually donated to
the AMS, Type1 versions. I'm not sure who did the TrueType version.

You can reencode a font (assign each glyph to a number different from
the original - basically apply a permutation to the original table): you
get a different encoding of the same font. That is true whether the font
is Type1 or Type3 or TrueType or 

Nick



___
Emacs-orgmode 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] ledger tutorial on Worg

[Eric S Fraga]

Hello,

I have just placed on Worg [1] a short tutorial/example for using
ledger with babel.  Please have a look and comment etc!

Thanks,
eric


[1] Hopefully at
http://orgmode.org/worg/org-contrib/babel/examples/ledger.php
when the php file is eventually created by the automated system.
-- 
Eric S Fraga
GnuPG: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D
___
Emacs-orgmode 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 bit offtopic, fonts in exported PDF documents

[Markus Heller]

Erik Iverson  writes:

> Markus Heller wrote:
>> Erik Iverson  writes:
>>
>>> John,
>>>
>>> Thank you for your reply.
>>>
>>> For those that don't want to read all that follows, please note my
>>> conclusion, given here:
>>>
>>> Since orgmode is automatically telling latex to use T1 encoding,
>>> perhaps we should somewhere document to the user that Type 1
>>> fonts should be available to get the best looking PDF possible.
>>> Otherwise, type 3 fonts will be substituted. I got suitable
>>> Type-1 fonts by installing the texlive-fonts-extra package
>>> under Ubuntu.
>>
>> Note that T1 *font encoding* has nothing to do with Type 1 fonts!
>
> Yes, thank you.  I gathered that eventually, but it did take some
> time to appreciate they are completely different concepts.  Is
> the following correct?
>
> Some Type 1 fonts *support* the T1 encoding.  Computer Modern is
> not one of those, so you need some that do.  CM-super or Latin
> Modern are two Type 1 font packages that do support the T1 encoding.

To my knowledge, the above is correct.  I make no guarantees, though ...

Cheers
Markus


___
Emacs-orgmode 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] a bit offtopic, fonts in exported PDF documents

[Nick Dokos]

Erik Iverson  wrote:

> For those that don't want to read all that follows, please note my
> conclusion, given here:
> 
> Since orgmode is automatically telling latex to use T1 encoding,
> perhaps we should somewhere document to the user that Type 1
> fonts should be available to get the best looking PDF possible.
> Otherwise, type 3 fonts will be substituted. I got suitable
> Type-1 fonts by installing the texlive-fonts-extra package
> under Ubuntu.
> 

[With apologies for the length (and the further off-topic direction) of
this post, I hope the following is of interest to a few people. Those
of you who have no interest in the finer points of TeX fontological history
can safely hit "Delete" now.]

I think the conclusion is substantively correct, but there are a couple
of minor nits: I would leave out the first line of the second paragraph
above ("Since orgmode...T1 encoding,"). I would also note that the problem
is a viewer problem, not a Type3 problem (see below). Here's why:

* Type1 fonts (e.g. the Adobe Postscript standard fonts) are implemented
  as scalable outlines, basically programs that describe what the glyph
  will look like. It's easy to tell the program: draw this glyph at
  1.41421 the size (or whatever other scaling factor you want), hence
  "scalable".

* Type3 fonts are usually bitmaps (that's actually an oversimplification, but 
it's
  true in the vast majority of cases), so you need a multiplicity of
  them at different sizes to cover the needs of a document.

Both of these (and presumably the missing Type2 as well, although I have
never seen one of those) were defined by Adobe.

T1-encoding has nothing to do with Type1 fonts except for the
unfortunate similarity of the names: an encoding is just the table that
translates from numbers to glyphs in a font. Knuth used a very peculiar
encoding originally (now called OT1) and in 1990, the TeX people got
together at Cork, Ireland, and hashed out this new encoding (it was
called Cork encoding for a long time, but at some point it became
"T1"). The T1-encoding *is* pretty much the encoding that Adobe used for
*its* fonts (whether Type1 or Type3). In particular, there were
T1-encoded Type3 fonts (the so called EC fonts, in their original
incarnation, before they were auto-traced and made into Type1 fonts) and
there are non-T1 encoded Type1 fonts (in particular, T1-encoding deals
with text, mostly European languages that use the Latin alphabet or
slight variations thereof, so Cyrillic, Greek, non-European alphabets
and symbols of various kinds have their own encodings: whether a font
for any of these would be Type1 or Type3 is a matter of implementation.)

Here are some links of interest from the TeX FAQ:

"What are encodings?"   http://www.tex.ac.uk/cgi-bin/texfaq2html?label=whatenc

"What are the EC fonts?" http://www.tex.ac.uk/cgi-bin/texfaq2html?label=ECfonts

"Adobe font formats" http://www.tex.ac.uk/cgi-bin/texfaq2html?label=adobetypen

This last one (and a link therein to PDF quality) is of particular
interest, because it describes the situation when Acrobar Reader
(version < 6) exhibited exactly the problem that you encountered with
Evince. Acrobat Reader has been fixed since then so it deals with Type3
fonts reasonably, but I guess Evince still mistreats Type3 fonts (they
may believe in the motto that "All the fonts (that matter) are Type1".)

Cheers,
Nick


___
Emacs-orgmode 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] Latest git pull has bug in (org-babel-remove-temporary-directory)

[Seweryn]

> 
> Hi Noorul,
> 
> Thanks for pointing out the above, I guess files.el can't be assumed to
> be loaded.  I've pushed up a fix.
 
I have also: 
---
delete-directory is an interactive compiled Lisp function in
`files.el'.

(delete-directory DIRECTORY &optional RECURSIVE)

Delete the directory named DIRECTORY.  Does not follow symlinks.
If RECURSIVE is non-nil, all files in DIRECTORY are deleted as well.
-

It should be related with these posts on emacs.devel:

http://thread.gmane.org/gmane.emacs.tramp/6964/focus=115812
http://article.gmane.org/gmane.emacs.devel/115812
http://article.gmane.org/gmane.emacs.tramp/6974

I don't have files.el loaded explicitely in my .emacs file, and I don't know 
where it is loaded?


___
Emacs-orgmode 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] a bit offtopic, fonts in exported PDF documents

[John Hendy]

On Thu, Aug 26, 2010 at 4:14 PM, Erik Iverson  wrote:

> John,
>
> Thank you for your reply.
>
>
No problem -- nice report and I'm glad you got things fixed!!

John


> For those that don't want to read all that follows, please note my
> conclusion, given here:
>
> Since orgmode is automatically telling latex to use T1 encoding,
> perhaps we should somewhere document to the user that Type 1
> fonts should be available to get the best looking PDF possible.
> Otherwise, type 3 fonts will be substituted. I got suitable
> Type-1 fonts by installing the texlive-fonts-extra package
> under Ubuntu.
>
> (Of course, that could already be documented somewhere :) )
>
> All of this explained very succinctly right here:
> http://www.latex-community.org/forum/viewtopic.php?f=5&t=571
>
>
> > Here, for example, are the
>
>> various texlive packages I can pick from:
>> http://wiki.archlinux.org/index.php/TeX_Live#Group_texlive-most
>>
>> Not saying one of those would fix the problem, but I wonder if you could
>> verify you have the fontsextra package? Just an idea?
>>
>
> It was a great idea.  It was what was wrong.  :)
>
> Under Ubuntu, I simply install texlive-fonts-extra, and it works.
>
> Of course, I was a bit more curious as to exactly *what* and *why*
> things were behaving as they were, so here is a summary for those who
> may see the same issue.
>
> Caveat: I don't know much about font issues, so the following is a bit
> imprecise and possibly even plain wrong :).
>
> By including [T1]{fontenc}, we are telling LaTeX to use so called T1
> font encoding.  Simple enough.  However, the original Computer Modern
> fonts were not designed with this encoding in mind.  There have been
> Type 1 replacements made and can be found in the Cm-super package.
> This is part of what texlive-fonts-extra installs, but was not
> available on either of the systems I tested on, one Ubuntu, one
> Fedora.
>
> Not having these font packages, I set out to determine which
> fonts were being used in the PDF depending on what encodings we
> use.
>
> The best way I have of checking what's going on is making a PDF,
> and then opening it up in Evince or acroread, and looking at 'fonts'
> tab under the document properties.
>
> As things were, i.e.: before installing texlive-fonts-extra, and
> while including T1 font encoding, things looked
> quite bad under Evince.  Looking at the fonts included in the PDF
> showed why.  Instead of the list of computer modern fonts I get when
> I don't include the T1 encoding, I got a list of "Type 3" fonts with
> "No Name" in evince and names like "F16, F20, ..." in acrobat.
>
> Why these looked "ok" under acrobat is not understood by me, but
> they certainly looked poor under evince.
>
> I could 'fix' this many ways, including removing the lines referencing
> T1 encoding from the .tex file, or changing fontenc to OT1 instead of
> T1, essentially the same fix.  This allowed the good old computer
> modern fonts to be included in the PDF, and all was well. But I wanted
> to know why T1 encoding wasn't working.
>
> After installing texlive-fonts-extra, I now have the
> "cm-super" package.  These fonts now are used when I specify the T1
> encoding. (I think!)  Now, my list of fonts under evince looks like
> "sfrm1200" for example.  No more Type 3 fonts, they are all Type 1.
> This all seems to be explained in Chapter 7 of The LaTeX Companion,
> section 7.5.
>
> I would be interested in what the names of the fonts embedded in
> PDF documents from other users are?  Are you all using these
> "cm-super" fonts?
>
> Alternatively, I was also able to get nice fonts by using the
> Modern Latin package, \usepackage{lmodern} with T1 encoding
> specified.
>
> The upshot is: If you're using an OS with a package manager,
> it might pay to do a "texlive-full" type install, instead of just
> doing the bits and pieces of latex packages as I've been doing!
> Unfortunately, I think with at least Ubuntu, that's not the
> default, so many users may be having the same issue as I am,
> without even realizing it.
>
>
> Hope this helps,
>
> --Erik
>
>
>
>> On Thu, Aug 26, 2010 at 12:34 PM, Erik Iverson > er...@ccbr.umn.edu>> wrote:
>>
>>Hello,
>>
>>I'm wondering if anyone can
>>
>>1) reproduce what I'm seeing
>>2) help in understanding what's going on.
>>
>>If I export an Org file to LaTeX, the resulting
>>.tex file contains the following in its header:
>>
>>\usepackage[T1]{fontenc}
>>\usepackage{t1enc}
>>
>>Long story short:
>>
>>The resulting .PDF file from pdflatex looks quite
>>bad in evince, and quite good in Acroread. By "quite bad",
>>I mean the fonts are practically illegible, very thin
>>and wiry.
>>
>>If I comment out *both* of those package requirements,
>>recompile the PDF, the resulting PDF looks great in all
>>viewers I can find.
>>
>>The Fonts specified in the Properties of the document
>>change when I use those packages versus not use them.
>>
>>How

Re: [Orgmode] Re: a bit offtopic, fonts in exported PDF documents

[Erik Iverson]

Markus Heller wrote:

Erik Iverson  writes:


John,

Thank you for your reply.

For those that don't want to read all that follows, please note my
conclusion, given here:

Since orgmode is automatically telling latex to use T1 encoding,
perhaps we should somewhere document to the user that Type 1
fonts should be available to get the best looking PDF possible.
Otherwise, type 3 fonts will be substituted. I got suitable
Type-1 fonts by installing the texlive-fonts-extra package
under Ubuntu.


Note that T1 *font encoding* has nothing to do with Type 1 fonts!


Yes, thank you.  I gathered that eventually, but it did take some
time to appreciate they are completely different concepts.  Is
the following correct?

Some Type 1 fonts *support* the T1 encoding.  Computer Modern is
not one of those, so you need some that do.  CM-super or Latin
Modern are two Type 1 font packages that do support the T1 encoding.



As far as I understand, you need Type 1 fonts for good looking pdfs
(Type 3 are bitmap fonts and thus not scalable), but the actual font
encoding shouldn't matter.


Yes! But as I think(?) I discovered, when T1 encoding is specified,
the Type 1 Computer Modern fonts don't support it, and therefore
are not included in the PDF. In my case, a Type 3 font was substituted
that looked nasty.  I needed to install proper Type 1 fonts that support
the T1 encoding, like Cm-super or Latin Modern.

Since orgmode is telling latex to use T1 encoding by default, I was
bitten by the fact that I had no Type 1 fonts that supported this
encoding, with my bare-bones latex install from a relatively common
Linux distro.

My message is just serving as information about how to get those fonts.

Thanks!

___
Emacs-orgmode 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: problem with babel and R

[David Hajage]

One comment:

When I execute all the buffer (org-babel-execute-buffer), the result is:

#+begin_src R :results output org :exports both
library(ascii)
options(asciiType = "org")
ascii(head(esoph, 3))
#+end_src

#+results:
#+BEGIN_SRC org
|   | agegp | alcgp | tobgp| ncases | ncontrols |
|---+---+---+--++---|
| 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
| 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
| 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
#+END_SRC

#+results:
|   | agegp | alcgp |tobgp | ncases | ncontrols |
|---+---+---+--++---|
| 1 | 25-34 | 0-39g/day | 0-9g/day |   0.00 | 40.00 |
| 2 | 25-34 | 0-39g/day |10-19 |   0.00 | 10.00 |
| 3 | 25-34 | 0-39g/day |20-29 |   0.00 |  6.00 |

Then, the results is repeated twice in the buffer. I understand why, but
perhaps the "silent" option should be turned on by default for org code
blocks?

David


On Thu, Aug 26, 2010 at 23:51, David Hajage  wrote:

> Oups, I forgot ob-org in my .emacs... OK, now, really sorry for this.
> David
>
>
>
> On Thu, Aug 26, 2010 at 22:20, David Hajage  wrote:
>
>> I am so sorry to bother you again, but I must miss something.
>>
>> When I write:
>>
>> #+begin_src R :results output org :exports both
>> library(ascii)
>> options(asciiType = "org")
>> ascii(head(esoph))
>> #+end_src
>>
>> The results is:
>>
>> #+results:
>> #+BEGIN_SRC org
>> |   | agegp | alcgp | tobgp| ncases | ncontrols |
>> |---+---+---+--++---|
>> | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
>> | 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
>> | 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
>> | 4 | 25-34 | 0-39g/day | 30+  | 0.00   | 5.00  |
>> | 5 | 25-34 | 40-79 | 0-9g/day | 0.00   | 27.00 |
>> | 6 | 25-34 | 40-79 | 10-19| 0.00   | 7.00  |
>> #+END_SRC
>>
>> OK, the result is surrounded by BEGIN_SRC org/END_SRC. But when I export
>> this, the results is exported as fontified org code. What should I do to
>> have this result interpreted as org markup?
>> David
>>
>>
>>
>> On Thu, Aug 26, 2010 at 18:10, Eric Schulte wrote:
>>
>>> Hi,
>>>
>>> A fix to this issue has been pushed up to the repository.  As can now be
>>> read in the documentation of the `org-babel-insert-result' function [1],
>>> there is now a subtle distinction between ":results org" and ":results
>>> raw", where ":results org" will wrap code block results in a "begin_src
>>> org" block.  The block wrapper makes it possible for the entirety of the
>>> results to be located and removed by Babel upon code block
>>> re-evaluation.
>>>
>>> In addition a new ob-org.el file has been added providing support for
>>> evaluation of Org-mode blocks.  With this new language support loaded
>>> the above technique becomes a working replacement for ":results raw"
>>> allowing the body of the org code block to be interpreted as inline
>>> org-mode text on export.  This is done through some non-standard default
>>> header arguments described in the recent commit message (see [2])
>>>
>>> Best -- Eric
>>>
>>> "Eric Schulte"  writes:
>>>
>>> > Hi David,
>>> >
>>> > "#+end_results: foo" (or some derivative syntax) sounds like a good
>>> > idea, I'll add it to the Babel task list.
>>> >
>>> > Thanks -- Eric
>>> >
>>> > David Hajage  writes:
>>> >
>>> >> OK, I understand that using ":results org", the results is not
>>> altered,
>>> >> there is no post processing. But I don't want a post processing, I
>>> would
>>> >> like a way to tell babel where is the begining *and the end* of the
>>> output
>>> >> produces by a particular R source block. I think an "#+end_results:
>>> foo" at
>>> >> the end of the output could do the job. Then, the option "replace"
>>> could
>>> >> work in all situation, even if a blank line is inserted somewhere in
>>> the org
>>> >> output. No?
>>> >> David
>>> >>
>>> >>
>>> >> On Tue, Aug 17, 2010 at 17:15, Eric Schulte 
>>> wrote:
>>> >>
>>> >>> Hi David,
>>> >>>
>>> >>> David Hajage  writes:
>>> >>>
>>> >>> > Thank you very much for your answer.
>>> >>> >
>>> >>>
>>> >>> My pleasure
>>> >>>
>>> >>> >
>>> >>> > But when I run the following code directly into R, no extra lines
>>> is
>>> >>> >added
>>> >>> > by the ascii function:
>>> >>> >> library(ascii)
>>> >>> > Le chargement a nécessité le package : proto
>>> >>> >> options(asciiType = "org")
>>> >>> >> ascii(head(esoph)) # no extra line
>>> >>> > |   | agegp | alcgp | tobgp| ncases | ncontrols |
>>> >>> > |---+---+---+--++---|
>>> >>> > | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
>>> >>> > | 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
>>> >>> > | 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
>>> >>> > | 4 | 25-34 | 0-39g/day | 30+  | 0.00   | 5.00  |
>>> >>> > | 5 | 25-34 | 40-79 | 0-9g/day | 0.00   | 

Re: [Orgmode] Bug: export aborts if ':eval query/never' in source code blocks

[Erik Iverson]

Eric,

As a follow-up on a related issue:

What if I want to eval a code block for some side-effect, but
*not* include code or results in export. This assumes I'm using
:session.

Is there a way to currently do that?

Setting :exports none seems to block evaluating of the code,
can the :eval argument 'override' that so the block is
eval'd, but no export is produced.

In R, I currently can just put the last line of the block
I want this behavior for as

NULL

with :exports results

and it seems to do what I want.  Just wondering if there was
a more 'official' way?

Here's a sample file that seems to do as I want, with the
NULL trick.  Just wonder if :eval can help at all.

* I want only the 2nd block exported

#+begin_src R :exports results :session

x <- 2 + 3
NULL

#+end_src

#+begin_src R :session :exports results

x

#+end_src


Eric Schulte wrote:

Hi Paul,

This is on the top of the stack for Babel bug fixes (see [1]), and I
hope to have a solution pushed up to the git repository soon.  I'll
reply to this email when this issue is resolved.

Thanks -- Eric

Paul Sexton  writes:


#+BEGIN_SRC R :eval query
...
#+END_SRC

If the above is in an org file, the user runs an export (C-c C-e), and the user
types 'no' when asked whether to evaluate the code block, then the whole export
process is aborted (no further blocks are processed and no export output is
produced).

The same thing happens with ':eval never'.

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


Footnotes: 
[1]  http://eschulte.github.com/babel-dev/STARTED-How-to-quietly-exclude-block-from-evaluation-.html



___
Emacs-orgmode 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] Examples in numbered lists

[Nicolas Goaziou]

Hello,
> Andrei Jirnyi writes:

> Is there any way to make a numbered list preserve its' numbering
> when there are intervening code or example blocks? For example, if I
> have smth like this: * testing auto numbering 1. First do
> something #+begin_example here is an example how to do
> something #+end_example 2. Then do something else

> and try to export, it will give me number (1.) for both items. Also
> if I press M-RET on the last line, it will be re-numbered as 1.

> Is there any way to avoid this?


Indent your list like this:

* testing auto numbering
1. First do something
   #+begin_example
   here is an example how to do something
   #+end_example
2. Then do something else


Regards,

-- Nicolas

___
Emacs-orgmode 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: problem with babel and R

[David Hajage]

Oups, I forgot ob-org in my .emacs... OK, now, really sorry for this.
David


On Thu, Aug 26, 2010 at 22:20, David Hajage  wrote:

> I am so sorry to bother you again, but I must miss something.
>
> When I write:
>
> #+begin_src R :results output org :exports both
> library(ascii)
> options(asciiType = "org")
> ascii(head(esoph))
> #+end_src
>
> The results is:
>
> #+results:
> #+BEGIN_SRC org
> |   | agegp | alcgp | tobgp| ncases | ncontrols |
> |---+---+---+--++---|
> | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
> | 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
> | 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
> | 4 | 25-34 | 0-39g/day | 30+  | 0.00   | 5.00  |
> | 5 | 25-34 | 40-79 | 0-9g/day | 0.00   | 27.00 |
> | 6 | 25-34 | 40-79 | 10-19| 0.00   | 7.00  |
> #+END_SRC
>
> OK, the result is surrounded by BEGIN_SRC org/END_SRC. But when I export
> this, the results is exported as fontified org code. What should I do to
> have this result interpreted as org markup?
> David
>
>
>
> On Thu, Aug 26, 2010 at 18:10, Eric Schulte wrote:
>
>> Hi,
>>
>> A fix to this issue has been pushed up to the repository.  As can now be
>> read in the documentation of the `org-babel-insert-result' function [1],
>> there is now a subtle distinction between ":results org" and ":results
>> raw", where ":results org" will wrap code block results in a "begin_src
>> org" block.  The block wrapper makes it possible for the entirety of the
>> results to be located and removed by Babel upon code block
>> re-evaluation.
>>
>> In addition a new ob-org.el file has been added providing support for
>> evaluation of Org-mode blocks.  With this new language support loaded
>> the above technique becomes a working replacement for ":results raw"
>> allowing the body of the org code block to be interpreted as inline
>> org-mode text on export.  This is done through some non-standard default
>> header arguments described in the recent commit message (see [2])
>>
>> Best -- Eric
>>
>> "Eric Schulte"  writes:
>>
>> > Hi David,
>> >
>> > "#+end_results: foo" (or some derivative syntax) sounds like a good
>> > idea, I'll add it to the Babel task list.
>> >
>> > Thanks -- Eric
>> >
>> > David Hajage  writes:
>> >
>> >> OK, I understand that using ":results org", the results is not altered,
>> >> there is no post processing. But I don't want a post processing, I
>> would
>> >> like a way to tell babel where is the begining *and the end* of the
>> output
>> >> produces by a particular R source block. I think an "#+end_results:
>> foo" at
>> >> the end of the output could do the job. Then, the option "replace"
>> could
>> >> work in all situation, even if a blank line is inserted somewhere in
>> the org
>> >> output. No?
>> >> David
>> >>
>> >>
>> >> On Tue, Aug 17, 2010 at 17:15, Eric Schulte 
>> wrote:
>> >>
>> >>> Hi David,
>> >>>
>> >>> David Hajage  writes:
>> >>>
>> >>> > Thank you very much for your answer.
>> >>> >
>> >>>
>> >>> My pleasure
>> >>>
>> >>> >
>> >>> > But when I run the following code directly into R, no extra lines is
>> >>> >added
>> >>> > by the ascii function:
>> >>> >> library(ascii)
>> >>> > Le chargement a nécessité le package : proto
>> >>> >> options(asciiType = "org")
>> >>> >> ascii(head(esoph)) # no extra line
>> >>> > |   | agegp | alcgp | tobgp| ncases | ncontrols |
>> >>> > |---+---+---+--++---|
>> >>> > | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
>> >>> > | 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
>> >>> > | 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
>> >>> > | 4 | 25-34 | 0-39g/day | 30+  | 0.00   | 5.00  |
>> >>> > | 5 | 25-34 | 40-79 | 0-9g/day | 0.00   | 27.00 |
>> >>> > | 6 | 25-34 | 40-79 | 10-19| 0.00   | 7.00  |
>> >>> >
>> >>>
>> >>> ah, my fault, this isn't an ascii issue.
>> >>>
>> >>> >
>> >>> > In fact, the solution was to run 'library(ascii)' in another source
>> >>> block.
>> >>> > When I run only this:
>> >>> >
>> >>>
>> >>> Thanks for pointing this out, I see what's happening now.
>> >>>
>> >>> The :results output header argument (see [1] for information on header
>> >>> arguments) informs Org-mode to collect all of the output of the source
>> >>> code block.  This means that when library(ascii) is run, an empty line
>> >>> is collected and appended to the output.  Removing the "output" header
>> >>> argument should fix this issue.
>> >>>
>> >>> My I ask why you are using the ascii package for simple table output?
>> >>> It seems to me that this would be much simpler using the pure Org-mode
>> >>> solution I suggested in my previous email.
>> >>>
>> >>> >
>> >>> > #+begin_src R :session *R* :results output org replace
>> >>> >   ascii(head(esoph))
>> >>> > #+end_src
>> >>> >
>> >>> > #+results: foo
>> >>> > |   | agegp | alcgp |tobgp | ncases | ncontrols |
>> >>> > |---+-

[Orgmode] Re: a bit offtopic, fonts in exported PDF documents

[Markus Heller]

Erik Iverson  writes:

> John,
>
> Thank you for your reply.
>
> For those that don't want to read all that follows, please note my
> conclusion, given here:
>
> Since orgmode is automatically telling latex to use T1 encoding,
> perhaps we should somewhere document to the user that Type 1
> fonts should be available to get the best looking PDF possible.
> Otherwise, type 3 fonts will be substituted. I got suitable
> Type-1 fonts by installing the texlive-fonts-extra package
> under Ubuntu.

Note that T1 *font encoding* has nothing to do with Type 1 fonts!

As far as I understand, you need Type 1 fonts for good looking pdfs
(Type 3 are bitmap fonts and thus not scalable), but the actual font
encoding shouldn't matter.

Just my 2 cents
Markus


___
Emacs-orgmode 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] a bit offtopic, fonts in exported PDF documents - oops

[Erik Iverson]

Alan L Tyree wrote:

On Thu, 26 Aug 2010 12:34:08 -0500
Erik Iverson  wrote:


Hello,

I'm wondering if anyone can

1) reproduce what I'm seeing
2) help in understanding what's going on.

If I export an Org file to LaTeX, the resulting
.tex file contains the following in its header:


Erik,
I just realised that I had added \usepackage{lmodern} to get the result
that I mentioned in my last post.

Without the lmodern package, the output still looks OK, but the fonts
are "No Name" Type 3 Embedded.


Great, that makes sense to me.  I noticed a significant loss of quality
with my type 3 fonts at 100% zoom.  They could have been different type
3 fonts, or different screen resolutions, document zoom, ... etc.

___
Emacs-orgmode 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] a bit offtopic, fonts in exported PDF documents

[Erik Iverson]

Alan,


Hi Erik,
I'm on Debian Squeeze, and I don't seem to have this problem. The fonts
reported in the Properties are LMRoman and they look ok in Evince.

I have all the latex extras installed.


If you've seen my recent follow-up, that makes sense to me.

So you are somehow getting LMRoman as your font *without*
including \usepackage{lmodern} ?  Can you verify that your
exported .tex files don't include that line?

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

Re: [Orgmode] Bug: export aborts if ':eval query/never' in source code blocks

[Eric Schulte]

Hi Paul,

This is on the top of the stack for Babel bug fixes (see [1]), and I
hope to have a solution pushed up to the git repository soon.  I'll
reply to this email when this issue is resolved.

Thanks -- Eric

Paul Sexton  writes:

> #+BEGIN_SRC R :eval query
> ...
> #+END_SRC
>
> If the above is in an org file, the user runs an export (C-c C-e), and the 
> user
> types 'no' when asked whether to evaluate the code block, then the whole 
> export
> process is aborted (no further blocks are processed and no export output is
> produced).
>
> The same thing happens with ':eval never'.
>
> 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

Footnotes: 
[1]  
http://eschulte.github.com/babel-dev/STARTED-How-to-quietly-exclude-block-from-evaluation-.html


___
Emacs-orgmode 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] a bit offtopic, fonts in exported PDF documents

[Erik Iverson]

John,

Thank you for your reply.

For those that don't want to read all that follows, please note my
conclusion, given here:

Since orgmode is automatically telling latex to use T1 encoding,
perhaps we should somewhere document to the user that Type 1
fonts should be available to get the best looking PDF possible.
Otherwise, type 3 fonts will be substituted. I got suitable
Type-1 fonts by installing the texlive-fonts-extra package
under Ubuntu.

(Of course, that could already be documented somewhere :) )

All of this explained very succinctly right here:
http://www.latex-community.org/forum/viewtopic.php?f=5&t=571

> Here, for example, are the
various texlive packages I can pick 
from: http://wiki.archlinux.org/index.php/TeX_Live#Group_texlive-most


Not saying one of those would fix the problem, but I wonder if you could 
verify you have the fontsextra package? Just an idea?


It was a great idea.  It was what was wrong.  :)

Under Ubuntu, I simply install texlive-fonts-extra, and it works.

Of course, I was a bit more curious as to exactly *what* and *why*
things were behaving as they were, so here is a summary for those who
may see the same issue.

Caveat: I don't know much about font issues, so the following is a bit
imprecise and possibly even plain wrong :).

By including [T1]{fontenc}, we are telling LaTeX to use so called T1
font encoding.  Simple enough.  However, the original Computer Modern
fonts were not designed with this encoding in mind.  There have been
Type 1 replacements made and can be found in the Cm-super package.
This is part of what texlive-fonts-extra installs, but was not
available on either of the systems I tested on, one Ubuntu, one
Fedora.

Not having these font packages, I set out to determine which
fonts were being used in the PDF depending on what encodings we
use.

The best way I have of checking what's going on is making a PDF,
and then opening it up in Evince or acroread, and looking at 'fonts'
tab under the document properties.

As things were, i.e.: before installing texlive-fonts-extra, and
while including T1 font encoding, things looked
quite bad under Evince.  Looking at the fonts included in the PDF
showed why.  Instead of the list of computer modern fonts I get when
I don't include the T1 encoding, I got a list of "Type 3" fonts with
"No Name" in evince and names like "F16, F20, ..." in acrobat.

Why these looked "ok" under acrobat is not understood by me, but
they certainly looked poor under evince.

I could 'fix' this many ways, including removing the lines referencing
T1 encoding from the .tex file, or changing fontenc to OT1 instead of
T1, essentially the same fix.  This allowed the good old computer
modern fonts to be included in the PDF, and all was well. But I wanted
to know why T1 encoding wasn't working.

After installing texlive-fonts-extra, I now have the
"cm-super" package.  These fonts now are used when I specify the T1
encoding. (I think!)  Now, my list of fonts under evince looks like
"sfrm1200" for example.  No more Type 3 fonts, they are all Type 1.
This all seems to be explained in Chapter 7 of The LaTeX Companion,
section 7.5.

I would be interested in what the names of the fonts embedded in
PDF documents from other users are?  Are you all using these
"cm-super" fonts?

Alternatively, I was also able to get nice fonts by using the
Modern Latin package, \usepackage{lmodern} with T1 encoding
specified.

The upshot is: If you're using an OS with a package manager,
it might pay to do a "texlive-full" type install, instead of just
doing the bits and pieces of latex packages as I've been doing!
Unfortunately, I think with at least Ubuntu, that's not the
default, so many users may be having the same issue as I am,
without even realizing it.


Hope this helps,

--Erik




On Thu, Aug 26, 2010 at 12:34 PM, Erik Iverson > wrote:


Hello,

I'm wondering if anyone can

1) reproduce what I'm seeing
2) help in understanding what's going on.

If I export an Org file to LaTeX, the resulting
.tex file contains the following in its header:

\usepackage[T1]{fontenc}
\usepackage{t1enc}

Long story short:

The resulting .PDF file from pdflatex looks quite
bad in evince, and quite good in Acroread. By "quite bad",
I mean the fonts are practically illegible, very thin
and wiry.

If I comment out *both* of those package requirements,
recompile the PDF, the resulting PDF looks great in all
viewers I can find.

The Fonts specified in the Properties of the document
change when I use those packages versus not use them.

However, the packages are the default for good reason I'm sure,
but C-c C-e d fires up Evince on my system, so the default
is not very pleasant.

I realize this isn't org-mode question per se, but can
anyone else replicate this, and do you know what's happening?
It seems like a potential problem with Evince specifically, since
Acrore

Re: [Orgmode] Re: problem with babel and R

[David Hajage]

I am so sorry to bother you again, but I must miss something.

When I write:

#+begin_src R :results output org :exports both
library(ascii)
options(asciiType = "org")
ascii(head(esoph))
#+end_src

The results is:

#+results:
#+BEGIN_SRC org
|   | agegp | alcgp | tobgp| ncases | ncontrols |
|---+---+---+--++---|
| 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
| 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
| 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
| 4 | 25-34 | 0-39g/day | 30+  | 0.00   | 5.00  |
| 5 | 25-34 | 40-79 | 0-9g/day | 0.00   | 27.00 |
| 6 | 25-34 | 40-79 | 10-19| 0.00   | 7.00  |
#+END_SRC

OK, the result is surrounded by BEGIN_SRC org/END_SRC. But when I export
this, the results is exported as fontified org code. What should I do to
have this result interpreted as org markup?
David


On Thu, Aug 26, 2010 at 18:10, Eric Schulte  wrote:

> Hi,
>
> A fix to this issue has been pushed up to the repository.  As can now be
> read in the documentation of the `org-babel-insert-result' function [1],
> there is now a subtle distinction between ":results org" and ":results
> raw", where ":results org" will wrap code block results in a "begin_src
> org" block.  The block wrapper makes it possible for the entirety of the
> results to be located and removed by Babel upon code block
> re-evaluation.
>
> In addition a new ob-org.el file has been added providing support for
> evaluation of Org-mode blocks.  With this new language support loaded
> the above technique becomes a working replacement for ":results raw"
> allowing the body of the org code block to be interpreted as inline
> org-mode text on export.  This is done through some non-standard default
> header arguments described in the recent commit message (see [2])
>
> Best -- Eric
>
> "Eric Schulte"  writes:
>
> > Hi David,
> >
> > "#+end_results: foo" (or some derivative syntax) sounds like a good
> > idea, I'll add it to the Babel task list.
> >
> > Thanks -- Eric
> >
> > David Hajage  writes:
> >
> >> OK, I understand that using ":results org", the results is not altered,
> >> there is no post processing. But I don't want a post processing, I would
> >> like a way to tell babel where is the begining *and the end* of the
> output
> >> produces by a particular R source block. I think an "#+end_results: foo"
> at
> >> the end of the output could do the job. Then, the option "replace" could
> >> work in all situation, even if a blank line is inserted somewhere in the
> org
> >> output. No?
> >> David
> >>
> >>
> >> On Tue, Aug 17, 2010 at 17:15, Eric Schulte 
> wrote:
> >>
> >>> Hi David,
> >>>
> >>> David Hajage  writes:
> >>>
> >>> > Thank you very much for your answer.
> >>> >
> >>>
> >>> My pleasure
> >>>
> >>> >
> >>> > But when I run the following code directly into R, no extra lines is
> >>> >added
> >>> > by the ascii function:
> >>> >> library(ascii)
> >>> > Le chargement a nécessité le package : proto
> >>> >> options(asciiType = "org")
> >>> >> ascii(head(esoph)) # no extra line
> >>> > |   | agegp | alcgp | tobgp| ncases | ncontrols |
> >>> > |---+---+---+--++---|
> >>> > | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
> >>> > | 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
> >>> > | 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
> >>> > | 4 | 25-34 | 0-39g/day | 30+  | 0.00   | 5.00  |
> >>> > | 5 | 25-34 | 40-79 | 0-9g/day | 0.00   | 27.00 |
> >>> > | 6 | 25-34 | 40-79 | 10-19| 0.00   | 7.00  |
> >>> >
> >>>
> >>> ah, my fault, this isn't an ascii issue.
> >>>
> >>> >
> >>> > In fact, the solution was to run 'library(ascii)' in another source
> >>> block.
> >>> > When I run only this:
> >>> >
> >>>
> >>> Thanks for pointing this out, I see what's happening now.
> >>>
> >>> The :results output header argument (see [1] for information on header
> >>> arguments) informs Org-mode to collect all of the output of the source
> >>> code block.  This means that when library(ascii) is run, an empty line
> >>> is collected and appended to the output.  Removing the "output" header
> >>> argument should fix this issue.
> >>>
> >>> My I ask why you are using the ascii package for simple table output?
> >>> It seems to me that this would be much simpler using the pure Org-mode
> >>> solution I suggested in my previous email.
> >>>
> >>> >
> >>> > #+begin_src R :session *R* :results output org replace
> >>> >   ascii(head(esoph))
> >>> > #+end_src
> >>> >
> >>> > #+results: foo
> >>> > |   | agegp | alcgp |tobgp | ncases | ncontrols |
> >>> > |---+---+---+--++---|
> >>> > | 1 | 25-34 | 0-39g/day | 0-9g/day |   0.00 | 40.00 |
> >>> > | 2 | 25-34 | 0-39g/day |10-19 |   0.00 | 10.00 |
> >>> > | 3 | 25-34 | 0-39g/day |20-29 |   0.00 |  6.00 |
> >>> > | 4 | 25-34 | 0-39g/day |  30+ |   0.

Re: [Orgmode] Bug: export aborts if ':eval query/never' in source code blocks

[Erik Iverson]

Which version of org-mode? I can't replicate on git version from
minutes ago..

Paul Sexton wrote:

#+BEGIN_SRC R :eval query
...
#+END_SRC

If the above is in an org file, the user runs an export (C-c C-e), and the user
types 'no' when asked whether to evaluate the code block, then the whole export
process is aborted (no further blocks are processed and no export output is
produced).

The same thing happens with ':eval never'.

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] Bug: export aborts if ':eval query/never' in source code blocks

[Paul Sexton]

#+BEGIN_SRC R :eval query
...
#+END_SRC

If the above is in an org file, the user runs an export (C-c C-e), and the user
types 'no' when asked whether to evaluate the code block, then the whole export
process is aborted (no further blocks are processed and no export output is
produced).

The same thing happens with ':eval never'.

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

[Orgmode] Re: [Windows] Quick guide on installing Emacs + OrgMode?

[Gilles Ganault]

On Thu, 26 Aug 2010 18:09:07 +0200, Richard Riley 
wrote:
>I dont use it myself but I have heard good things about Lennarts version.
>
>http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl

Thanks guys for the tips.


___
Emacs-orgmode 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] [BUG] export to latex breaks

[Puneeth]

Hi All,

I'm on Org-mode version 7.01trans (release_7.01h.205.ge3d2)
The LaTeX export of document test.org breaks. The headings Day 1 and
Day 2 and content under them is not visible.
[I have org-odd-levels-only set]

Git bisect says -

bb0a1f190be361ce1d717d79d411b88406d74c33 is the first bad commit
commit bb0a1f190be361ce1d717d79d411b88406d74c33
Author: Stephen Eglen 
Date:   Tue Jul 27 20:04:42 2010 +

The patch below fixes the problem partially. Export of test.org
works. But, export of test2.org breaks. The subheading Day 2 does not
show up. [test2.org produces the same output without applying the
patch, too. I'm do not think that is an acceptable output.]

HTH,
Puneeth

-
PARTIAL FIX
-
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 4f27f42..6bc6f71 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -966,10 +966,10 @@ If ODD Is non-nil, assume subcontent only
contains odd sections."
   (number-to-string (+ (if odd 4 2) level))
   ",\\}\\) \\(.*\\)$")
   nil t)
-  (setq nstars (1- (- (match-end 1) (match-beginning 1
+  (setq nstars (- (match-end 1) (match-beginning 1)))
   (setq new-level (if odd
- (/ (+ 3 nstars) 2);; not entirely sure why +3!
-   nstars)))
+ (- nstars 2)
+   (1- nstars
 (if nstars
(org-export-latex-parse-global new-level odd)
   nil) ; subcontent is nil
-


test.org
Description: Binary data


test2.org
Description: Binary data
___
Emacs-orgmode 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] a bit offtopic, fonts in exported PDF documents

[John Hendy]

I know this is old, but check here?
http://ubuntuforums.org/archive/index.php/t-557746.html

They don't really
"solve" the problem except by doing what you did -- remove the encoding
lines. Perhaps you should try verifying your LaTeX fonts packages or check
with your distro repository to see what exists? I'm on Arch and they some
fantastic documentation. Here, for example, are the various texlive packages
I can pick from:
http://wiki.archlinux.org/index.php/TeX_Live#Group_texlive-most

Not saying one of those would fix the problem, but I wonder if you could
verify you have the fontsextra package? Just an idea?

Or run 'pdflatex file.tex' from the command line to see if any errors come
up when using pdflatex directly vs. through org? You might be able to see
more of the inner details that way and if it's complaining?


John

On Thu, Aug 26, 2010 at 12:34 PM, Erik Iverson  wrote:

> Hello,
>
> I'm wondering if anyone can
>
> 1) reproduce what I'm seeing
> 2) help in understanding what's going on.
>
> If I export an Org file to LaTeX, the resulting
> .tex file contains the following in its header:
>
> \usepackage[T1]{fontenc}
> \usepackage{t1enc}
>
> Long story short:
>
> The resulting .PDF file from pdflatex looks quite
> bad in evince, and quite good in Acroread. By "quite bad",
> I mean the fonts are practically illegible, very thin
> and wiry.
>
> If I comment out *both* of those package requirements,
> recompile the PDF, the resulting PDF looks great in all
> viewers I can find.
>
> The Fonts specified in the Properties of the document
> change when I use those packages versus not use them.
>
> However, the packages are the default for good reason I'm sure,
> but C-c C-e d fires up Evince on my system, so the default
> is not very pleasant.
>
> I realize this isn't org-mode question per se, but can
> anyone else replicate this, and do you know what's happening?
> It seems like a potential problem with Evince specifically, since
> Acroread seems to handle the resulting PDF just fine.
>
> Finally, does anyone know why the t1enc package is required, the
> only thing I read about it was the following:
>
> http://www.tex.ac.uk/cgi-bin/texfaq2html?label=t1enc
>
> 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] a bit offtopic, fonts in exported PDF documents

[Erik Iverson]

Hello,

I'm wondering if anyone can

1) reproduce what I'm seeing
2) help in understanding what's going on.

If I export an Org file to LaTeX, the resulting
.tex file contains the following in its header:

\usepackage[T1]{fontenc}
\usepackage{t1enc}

Long story short:

The resulting .PDF file from pdflatex looks quite
bad in evince, and quite good in Acroread. By "quite bad",
I mean the fonts are practically illegible, very thin
and wiry.

If I comment out *both* of those package requirements,
recompile the PDF, the resulting PDF looks great in all
viewers I can find.

The Fonts specified in the Properties of the document
change when I use those packages versus not use them.

However, the packages are the default for good reason I'm sure,
but C-c C-e d fires up Evince on my system, so the default
is not very pleasant.

I realize this isn't org-mode question per se, but can
anyone else replicate this, and do you know what's happening?
It seems like a potential problem with Evince specifically, since
Acroread seems to handle the resulting PDF just fine.

Finally, does anyone know why the t1enc package is required, the
only thing I read about it was the following:

http://www.tex.ac.uk/cgi-bin/texfaq2html?label=t1enc

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

Re: [Orgmode] Re: [babel] support plantuml

[Eric Schulte]

Rainer M Krug  writes:

> plantuml looks great - and it could save me quite a bit of work!
>
> Could you announce on the list as soon as it is uploaded to git so that
> I could try it?
>

This is now in the Org repository.  For setup and usage information see
http://eschulte.github.com/babel-dev/DONE-integrate-plantuml-support.html

Best -- Eric

>
> Cheers,
>
> Rainer
>
>
> On 26/08/10 16:26, zwz wrote:
>> 
>> "Eric Schulte"  writes:
>> 
>>> Hi,
>>>
>>> I agree plantuml certainly makes sense as a new code block type.  I'd
>>> like to include your ob-plantuml.el file into Org-mode/Babel, would you
>>> be willing to complete the FSF assignment process for contributing to
>>> Org-mode as described at http://orgmode.org/worg/org-contribute.php?
>>>
>>> Thanks! -- Eric
>>>
>> Yes, I am glad to.
>> And I just fill the form and send 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

___
Emacs-orgmode 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] Examples in numbered lists

[Neil Hepburn]

you could revert to raw latex code in your document and use 
\begin{enumerate}..\end{enumerate} with something like this:
* testing auto numbering
\begin{enumerate}
\item First do something
#+begin_example
here is an example how to do something
#+end_example
\item Then do something else
\end{enumerate}

It's not as elegant as the org-mode approach but it works.

-Neil
On 2010-08-26, at 10:18 AM, Andrei Jirnyi wrote:

> Hi --
> 
> Is there any way to make a numbered list preserve its' numbering when 
> there are intervening code or example blocks? For example, if I have smth 
> like this:
> * testing auto numbering
> 1. First do something
> #+begin_example
> here is an example how to do something
> #+end_example
> 2. Then do something else
> 
> and try to export, it will give me number (1.) for both items. Also if I 
> press M-RET on the last line, it will be re-numbered as 1.
> 
> Is there any way to avoid this?
> 
> --aj
> 
> 
> ___
> Emacs-orgmode 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] Examples in numbered lists

[Andrei Jirnyi]

Hi --

Is there any way to make a numbered list preserve its' numbering when 
there are intervening code or example blocks? For example, if I have smth 
like this:
* testing auto numbering
1. First do something
#+begin_example
here is an example how to do something
#+end_example
2. Then do something else

and try to export, it will give me number (1.) for both items. Also if I 
press M-RET on the last line, it will be re-numbered as 1.

Is there any way to avoid this?

--aj


___
Emacs-orgmode 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: [Windows] Quick guide on installing Emacs + OrgMode?

[Richard Riley]

Gilles Ganault  writes:

> Hello
>
> I'd like to take a quick look at Emacs in order to use its OrgMode
> add-on to get an outliner.
>
> Is there a HOWTO somewhere that would get me up and running quickly on
> Windows?
>
> Thank you.
>
> ___
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

Hi Gilles,

I dont use it myself but I have heard good things about Lennarts version.

http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl



___
Emacs-orgmode 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: problem with babel and R

[Eric Schulte]

Hi,

A fix to this issue has been pushed up to the repository.  As can now be
read in the documentation of the `org-babel-insert-result' function [1],
there is now a subtle distinction between ":results org" and ":results
raw", where ":results org" will wrap code block results in a "begin_src
org" block.  The block wrapper makes it possible for the entirety of the
results to be located and removed by Babel upon code block
re-evaluation.

In addition a new ob-org.el file has been added providing support for
evaluation of Org-mode blocks.  With this new language support loaded
the above technique becomes a working replacement for ":results raw"
allowing the body of the org code block to be interpreted as inline
org-mode text on export.  This is done through some non-standard default
header arguments described in the recent commit message (see [2])

Best -- Eric

"Eric Schulte"  writes:

> Hi David,
>
> "#+end_results: foo" (or some derivative syntax) sounds like a good
> idea, I'll add it to the Babel task list.
>
> Thanks -- Eric
>
> David Hajage  writes:
>
>> OK, I understand that using ":results org", the results is not altered,
>> there is no post processing. But I don't want a post processing, I would
>> like a way to tell babel where is the begining *and the end* of the output
>> produces by a particular R source block. I think an "#+end_results: foo" at
>> the end of the output could do the job. Then, the option "replace" could
>> work in all situation, even if a blank line is inserted somewhere in the org
>> output. No?
>> David
>>
>>
>> On Tue, Aug 17, 2010 at 17:15, Eric Schulte  wrote:
>>
>>> Hi David,
>>>
>>> David Hajage  writes:
>>>
>>> > Thank you very much for your answer.
>>> >
>>>
>>> My pleasure
>>>
>>> >
>>> > But when I run the following code directly into R, no extra lines is
>>> >added
>>> > by the ascii function:
>>> >> library(ascii)
>>> > Le chargement a nécessité le package : proto
>>> >> options(asciiType = "org")
>>> >> ascii(head(esoph)) # no extra line
>>> > |   | agegp | alcgp | tobgp| ncases | ncontrols |
>>> > |---+---+---+--++---|
>>> > | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00 |
>>> > | 2 | 25-34 | 0-39g/day | 10-19| 0.00   | 10.00 |
>>> > | 3 | 25-34 | 0-39g/day | 20-29| 0.00   | 6.00  |
>>> > | 4 | 25-34 | 0-39g/day | 30+  | 0.00   | 5.00  |
>>> > | 5 | 25-34 | 40-79 | 0-9g/day | 0.00   | 27.00 |
>>> > | 6 | 25-34 | 40-79 | 10-19| 0.00   | 7.00  |
>>> >
>>>
>>> ah, my fault, this isn't an ascii issue.
>>>
>>> >
>>> > In fact, the solution was to run 'library(ascii)' in another source
>>> block.
>>> > When I run only this:
>>> >
>>>
>>> Thanks for pointing this out, I see what's happening now.
>>>
>>> The :results output header argument (see [1] for information on header
>>> arguments) informs Org-mode to collect all of the output of the source
>>> code block.  This means that when library(ascii) is run, an empty line
>>> is collected and appended to the output.  Removing the "output" header
>>> argument should fix this issue.
>>>
>>> My I ask why you are using the ascii package for simple table output?
>>> It seems to me that this would be much simpler using the pure Org-mode
>>> solution I suggested in my previous email.
>>>
>>> >
>>> > #+begin_src R :session *R* :results output org replace
>>> >   ascii(head(esoph))
>>> > #+end_src
>>> >
>>> > #+results: foo
>>> > |   | agegp | alcgp |tobgp | ncases | ncontrols |
>>> > |---+---+---+--++---|
>>> > | 1 | 25-34 | 0-39g/day | 0-9g/day |   0.00 | 40.00 |
>>> > | 2 | 25-34 | 0-39g/day |10-19 |   0.00 | 10.00 |
>>> > | 3 | 25-34 | 0-39g/day |20-29 |   0.00 |  6.00 |
>>> > | 4 | 25-34 | 0-39g/day |  30+ |   0.00 |  5.00 |
>>> > | 5 | 25-34 | 40-79 | 0-9g/day |   0.00 | 27.00 |
>>> > | 6 | 25-34 | 40-79 |10-19 |   0.00 |  7.00 |
>>> >
>>> > Everything is then OK.
>>> > I have no idea why "library(ascii)..." generates an extra empty line in
>>> the
>>> > results.
>>> >
>>> > If I understand, the results is all the text directly under "#+results:",
>>> > until the first empty line. But what happens if the result contains empty
>>> > lines? Here an example with ascii and Hmisc package:
>>> >
>>>
>>> This is not quite right, see [2] for a discussion of results handling.
>>> The "org" option to results is a special case in which no
>>> post-processing of the results takes place, and the raw output is
>>> inserted into the org-mode buffer.
>>>
>>> Under normal usage w/o this header argument, results are either tabular
>>> or are textual.  If tabular a single table can easily be recognized and
>>> handled, if textual they are normally enclosed in a block (example,
>>> html, latex, etc...), the block then allows for empty lines while still
>>> making it clear where the results end.
>>>
>>
>>
>>>
>>> >
>>> >> library(ascii)
>>> >> library(Hmisc)

Re: [Orgmode] Re: [babel] support plantuml

[Eric Schulte]

zwz  writes:

> "Eric Schulte"  writes:
>
>> Hi,
>>
>> I agree plantuml certainly makes sense as a new code block type.  I'd
>> like to include your ob-plantuml.el file into Org-mode/Babel, would you
>> be willing to complete the FSF assignment process for contributing to
>> Org-mode as described at http://orgmode.org/worg/org-contribute.php?
>>
>> Thanks! -- Eric
>>
> Yes, I am glad to.
> And I just fill the form and send it.
>

Great!

Please do send in the form and then keep me and Carsten posted of the
progress of your FSF assignment so that we can add you to the Org-mode
contributors list when it's complete.

I've just added ob-plantuml.el to Org-mode and pushed it up to the git
repository.  It's now part of `org-babel-load-languages' so it can be
activated just like any other language, the only other configuration
required is to set the value of `org-plantuml-jar-path' to point to the
plantuml.jar file.

I just tried this out myself and it works wonderfully.

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

Re: [Orgmode] [Windows] Quick guide on installing Emacs + OrgMode?

[Sebastian Rose]

Gilles Ganault  writes:
> Hello
>
> I'd like to take a quick look at Emacs in order to use its OrgMode
> add-on to get an outliner.
>
> Is there a HOWTO somewhere that would get me up and running quickly on
> Windows?
>
> Thank you.


Welcome Gilles,


I'm not a windows user, but

Get the current stable version here:
http://ftp.gnu.org/pub/gnu/emacs/windows/emacs-23.2-bin-i386.zip

It's just as easy to install, as any other software.

Well, it's easier to remove though, since nothing will remain on your
computer (no registry entries...).  This makes emacs my editor of choice
if I have to work on a window system (i.e. some one elses host).


Org-mode comes with this version of emacs.


After a while, you might want to upgrade Org mode to the current
development version.  But for a start the bundled Org mode version is
just fine.



  Sebastian

___
Emacs-orgmode 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] [PATCH] Latest git pull has bug in (org-babel-remove-temporary-directory)

[Eric Schulte]

Noorul Islam  writes:

> On Thu, Aug 26, 2010 at 5:44 PM, Eric Schulte  wrote:
>>
>> Hi Noorul,
>>
>> Can I ask what error the directory deletion is causing for you?
>>
>> I have the following delete-directory in my Emacs (latest from Git)
>>
>> ,[delete-directory]
>> | delete-directory is an interactive compiled Lisp function in
>> | `files.el'.
>> |
>> | (delete-directory DIRECTORY &optional RECURSIVE TRASH)
>> |
>> | Delete the directory named DIRECTORY.  Does not follow symlinks.
>> | If RECURSIVE is non-nil, all files in DIRECTORY are deleted as well.
>> | TRASH non-nil means to trash the directory instead, provided
>> | `delete-by-moving-to-trash' is non-nil.
>> |
>> | When called interactively, TRASH is t if no prefix argument is
>> | given.  With a prefix argument, TRASH is nil.
>> |
>> | [back]
>> `
>>
>> The second argument to `delete-directory' ensures that subdirectories
>> are recursively deleted.  Are you using a different version of Emacs
>> (maybe XEmacs?) in which `delete-directory' accepts a different number
>> of arguments?
>>
>
>
> "GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
>  of 2010-01-30 on noorul"
>
> C-h f delete-directory gives me this
>
> -
> delete-directory is an interactive built-in function in `C source
> code'.
>
> (delete-directory DIRECTORY)
>
> Delete the directory named DIRECTORY.  Does not follow symlinks.
> --
>
> Thanks and Regards
> Noorul
>

Hi Noorul,

Thanks for pointing out the above, I guess files.el can't be assumed to
be loaded.  I've pushed up a fix.

Thanks -- Eric

>
>>
>> Thanks -- Eric
>>
>> Noorul Islam  writes:
>>
>> > Latest pull is throwing error while quitting emacs.
>> >
>> > Here is the patch to fix this.
>> >
>> > ob.el:  Fix minor bug
>> >
>> > * lisp/ob.el (org-babel-remove-temporary-directory) : Pass correct number 
>> > of
>> > arguments to (delete-directory)
>> >
>> > Thanks and Regards
>> > Noorul
>> >
>> > diff --git a/lisp/ob.el b/lisp/ob.el
>> > index 33dbfef..32e2a54 100644
>> > --- a/lisp/ob.el
>> > +++ b/lisp/ob.el
>> > @@ -1679,7 +1679,7 @@ of `org-babel-temporary-directory'."
>> >  (defun org-babel-remove-temporary-directory ()
>> >    "Remove `org-babel-temporary-directory' on Emacs shutdown."
>> >    (when (boundp 'org-babel-temporary-directory)
>> > -    (delete-directory org-babel-temporary-directory t)))
>> > +    (delete-directory org-babel-temporary-directory)))
>> >
>> >  (add-hook 'kill-emacs-hook 'org-babel-remove-temporary-directory)
>> >
>> > ___
>> > Emacs-orgmode 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] Table of Contents in html export

[Sebastian Rose]

Andrei Jirnyi  writes:
> Hi all,
>
> Are there any options to modify the table of contents in the exported html
> files (other than whether to show it and to what level)? Or, if there are
> no such options, perhaps I could modify some elisp functions?
>
> Specifically, what I wanted to do was to:
>
> - change its name to just "Contents"
> - put a separator between the TOC and the first section?
>
> If I add smth like
> #+html: 
> at the beginning, it gets inserted between the title and the TOC :(
>
> Thanks!!


M-x customize-variable RET org-export-language-setup RET


...and use CSS to add border and spacing at the bottom:

div#table-of-contents
{
  padding-bottom:30px;
  border-bottom:1px solid #00;
}


HTH

  Sebastian

___
Emacs-orgmode 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: [babel] support plantuml

[Rainer M Krug]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

plantuml looks great - and it could save me quite a bit of work!

Could you announce on the list as soon as it is uploaded to git so that
I could try it?

Cheers,

Rainer


On 26/08/10 16:26, zwz wrote:
> 
> "Eric Schulte"  writes:
> 
>> Hi,
>>
>> I agree plantuml certainly makes sense as a new code block type.  I'd
>> like to include your ob-plantuml.el file into Org-mode/Babel, would you
>> be willing to complete the FSF assignment process for contributing to
>> Org-mode as described at http://orgmode.org/worg/org-contribute.php?
>>
>> Thanks! -- Eric
>>
> Yes, I am glad to.
> And I just fill the form and send 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


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

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Tel:+33 - (0)9 53 10 27 44
Cell:   +27 - (0)8 39 47 90 42
Fax (SA):   +27 - (0)8 65 16 27 82
Fax (D) :   +49 - (0)3 21 21 25 22 44
Fax (FR):   +33 - (0)9 58 10 27 44
email:  rai...@krugs.de

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

iEYEARECAAYFAkx2gZIACgkQoYgNqgF2egpMlACfT/Fyjdp96sAZQm/2Dpy3UWuD
kWMAni75HMFarehwpyQ1YOEjrbK2oso5
=5sCz
-END PGP SIGNATURE-

___
Emacs-orgmode 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] support plantuml

[zwz]

"Eric Schulte"  writes:

> Hi,
>
> I agree plantuml certainly makes sense as a new code block type.  I'd
> like to include your ob-plantuml.el file into Org-mode/Babel, would you
> be willing to complete the FSF assignment process for contributing to
> Org-mode as described at http://orgmode.org/worg/org-contribute.php?
>
> Thanks! -- Eric
>
Yes, I am glad to.
And I just fill the form and send 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: [babel] support plantuml

[zwz]

Mike Gauland  writes:

> Mike Gauland  gmail.com> writes:
>
>> I can get an image if I evaluate the block manually (e.g., via 'C-c
> C-c' with
>> the cursor on the BEGIN block), but when I export the file the image
> is
>> invalid.
>
> I figured it out. I was getting extra carriage returns in the file. I've
> fixed
> them by setting "coding-system-for-write" to 'no-conversion within the
> (let).
>
> --Mike
>
I also encountered the same problem. But it seems not work perfectly by
letting "coding-system-for-write" be 'no-conversion. For example:
In my "test.org"

* test

#+BEGIN_SRC plantuml :file test.png
Alice -> Bob: Authentication Request
Bob --> Alice: Authentication Response
#+END_SRC


#+BEGIN_SRC plantuml :file test2.png
Alice2 -> Bob: Authentication Request
Bob --> Alice: Authentication Response
#+END_SRC

C-c C-c on the second src block does not create a right image.

So here is a new version of "ob-plantuml.el", which utilizes the io
redirection in shell directly.

Hope that it addresses the problem.



ob-plantuml.el
Description: application/emacs-lisp
___
Emacs-orgmode 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] [babel] babel creating corrupt pdf and png

[Graham Smith]

Eriic,

Thanks,
> I'd suggest looking at the R session ("bats" in your case) to see what
> errors if any are being thrown by R during execution of the boxplot
> command.

Will do, but sidetracked somewhere else now.

Its strange because some are now being produced fine, and other not.
They are all working fine if I copy the code into R.

Not the code I posted, I hasten to add, as it was jibberish, I now
realise, but that isn't the problem

Graahm

___
Emacs-orgmode 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] Latest git pull has bug in (org-babel-remove-temporary-directory)

[Detlef Steuer]

Hi Eric,

I have to confirm that bug.
Org-mode as of today, emacs 23.1.1.

Here is, what my *MESSAGES* buffer tells:
CONTENTS...done
(No files need saving)
org-babel-remove-temporary-directory: Wrong number of arguments: 
delete-directory, 2
When done with a buffer, type C-x #
Auto-saving...done


Ciao
Detlef

On Thu, 26 Aug 2010 06:14:26 -0600
"Eric Schulte"  wrote:

> Hi Noorul,
> 
> Can I ask what error the directory deletion is causing for you?
> 
> I have the following delete-directory in my Emacs (latest from Git)
> 
> ,[delete-directory]
> | delete-directory is an interactive compiled Lisp function in
> | `files.el'.
> | 
> | (delete-directory DIRECTORY &optional RECURSIVE TRASH)
> | 
> | Delete the directory named DIRECTORY.  Does not follow symlinks.
> | If RECURSIVE is non-nil, all files in DIRECTORY are deleted as well.
> | TRASH non-nil means to trash the directory instead, provided
> | `delete-by-moving-to-trash' is non-nil.
> | 
> | When called interactively, TRASH is t if no prefix argument is
> | given.  With a prefix argument, TRASH is nil.
> | 
> | [back]
> `
> 
> The second argument to `delete-directory' ensures that subdirectories
> are recursively deleted.  Are you using a different version of Emacs
> (maybe XEmacs?) in which `delete-directory' accepts a different number
> of arguments?
> 
> Thanks -- Eric
> 
> Noorul Islam  writes:
> 
> > Latest pull is throwing error while quitting emacs.
> >
> > Here is the patch to fix this.
> >
> > ob.el:  Fix minor bug
> >
> > * lisp/ob.el (org-babel-remove-temporary-directory) : Pass correct number of
> > arguments to (delete-directory)
> >
> > Thanks and Regards
> > Noorul
> >
> > diff --git a/lisp/ob.el b/lisp/ob.el
> > index 33dbfef..32e2a54 100644
> > --- a/lisp/ob.el
> > +++ b/lisp/ob.el
> > @@ -1679,7 +1679,7 @@ of `org-babel-temporary-directory'."
> >  (defun org-babel-remove-temporary-directory ()
> >"Remove `org-babel-temporary-directory' on Emacs shutdown."
> >(when (boundp 'org-babel-temporary-directory)
> > -(delete-directory org-babel-temporary-directory t)))
> > +(delete-directory org-babel-temporary-directory)))
> >  
> >  (add-hook 'kill-emacs-hook 'org-babel-remove-temporary-directory)
> >  
> > ___
> > Emacs-orgmode 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: Trouble syncing files to mobile-org.

[Jason Schadel]

With help from Richard Moreland, I found my MobileOrg settings were wrong.
 I had 'Index File' set to Mobileorg/index.org when it should have been just
index.org.  Thanks for the help.

On Wed, Aug 25, 2010 at 11:29 AM, Jason Schadel wrote:

> I set it up using the Dropbox option.  When I try to sync, it only syncs
> index.org, mobileorg.org and agendas.org.  I looked in the checksums.dat
> file and noticed that those files are the only files that use 'md5' to
> generate the checksum.  The other files use 'shasum'.
>
> I've tried removing all the files and pushing them again but every time
> mobile-org just syncs index.org and mobileorg.org.
>
> After syncing, emacs shows the new items but after a push from emacs and
> resync on the iphone, the items disappear on the iphone.
>
> I'm using version 1.3 of mobileorg and org-mode version 7.01trans.
>
> Any ideas?
>
___
Emacs-orgmode 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] [PATCH] Latest git pull has bug in (org-babel-remove-temporary-directory)

[Noorul Islam]

On Thu, Aug 26, 2010 at 5:44 PM, Eric Schulte  wrote:
>
> Hi Noorul,
>
> Can I ask what error the directory deletion is causing for you?
>
> I have the following delete-directory in my Emacs (latest from Git)
>
> ,[delete-directory]
> | delete-directory is an interactive compiled Lisp function in
> | `files.el'.
> |
> | (delete-directory DIRECTORY &optional RECURSIVE TRASH)
> |
> | Delete the directory named DIRECTORY.  Does not follow symlinks.
> | If RECURSIVE is non-nil, all files in DIRECTORY are deleted as well.
> | TRASH non-nil means to trash the directory instead, provided
> | `delete-by-moving-to-trash' is non-nil.
> |
> | When called interactively, TRASH is t if no prefix argument is
> | given.  With a prefix argument, TRASH is nil.
> |
> | [back]
> `
>
> The second argument to `delete-directory' ensures that subdirectories
> are recursively deleted.  Are you using a different version of Emacs
> (maybe XEmacs?) in which `delete-directory' accepts a different number
> of arguments?
>


"GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
 of 2010-01-30 on noorul"

C-h f delete-directory gives me this

-
delete-directory is an interactive built-in function in `C source
code'.

(delete-directory DIRECTORY)

Delete the directory named DIRECTORY.  Does not follow symlinks.
--

Thanks and Regards
Noorul

>
> Thanks -- Eric
>
> Noorul Islam  writes:
>
> > Latest pull is throwing error while quitting emacs.
> >
> > Here is the patch to fix this.
> >
> > ob.el:  Fix minor bug
> >
> > * lisp/ob.el (org-babel-remove-temporary-directory) : Pass correct number of
> > arguments to (delete-directory)
> >
> > Thanks and Regards
> > Noorul
> >
> > diff --git a/lisp/ob.el b/lisp/ob.el
> > index 33dbfef..32e2a54 100644
> > --- a/lisp/ob.el
> > +++ b/lisp/ob.el
> > @@ -1679,7 +1679,7 @@ of `org-babel-temporary-directory'."
> >  (defun org-babel-remove-temporary-directory ()
> >    "Remove `org-babel-temporary-directory' on Emacs shutdown."
> >    (when (boundp 'org-babel-temporary-directory)
> > -    (delete-directory org-babel-temporary-directory t)))
> > +    (delete-directory org-babel-temporary-directory)))
> >
> >  (add-hook 'kill-emacs-hook 'org-babel-remove-temporary-directory)
> >
> > ___
> > Emacs-orgmode 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] [babel] babel creating corrupt pdf and png

[Eric Schulte]

Hi Graham,

These pdf and png images are being created by R, Babel is simply passing
commands to the R process setting the output device according to the
:file argument, so for example ":file fig1.pdf" would result in wrapping
your code in

pdf(file="fig1.pdf")
<>
dev.off

I'd suggest looking at the R session ("bats" in your case) to see what
errors if any are being thrown by R during execution of the boxplot
command.

Best -- Eric

Graham Smith  writes:

> PDFs created by Babel are giving a file corrupt message when trying to
> open them and a format not recognised message if I try pngs,
>
> Same files created directly from R are fine.
>
> This is with Ubuntu 10.04 and Org-mode version 6.36trans 
> (release_7.01h.94.g25ac
>
> Example of code I am using is below.
>
> Can anyone suggest what I am doing wrong?
>
> Many thanks,
>
> Graham
>
> #+srcname:boxpip45byyear
> #+begin_src R :session bats :file boxpip45byyear.pdf :exports code
> boxplot(boxplot(allbats$count[allbats$species=="p45"]~allbats$year[allbats$species=="p45"])
> #+end_src
>
> #+results: boxpip45byyear
> [[file:boxpip45byyear.pdf]]
>
> ___
> Emacs-orgmode 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] [Windows] Quick guide on installing Emacs + OrgMode?

[Gilles Ganault]

Hello

I'd like to take a quick look at Emacs in order to use its OrgMode
add-on to get an outliner.

Is there a HOWTO somewhere that would get me up and running quickly on
Windows?

Thank you.


___
Emacs-orgmode 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] [PATCH] Latest git pull has bug in (org-babel-remove-temporary-directory)

[Eric Schulte]

Hi Noorul,

Can I ask what error the directory deletion is causing for you?

I have the following delete-directory in my Emacs (latest from Git)

,[delete-directory]
| delete-directory is an interactive compiled Lisp function in
| `files.el'.
| 
| (delete-directory DIRECTORY &optional RECURSIVE TRASH)
| 
| Delete the directory named DIRECTORY.  Does not follow symlinks.
| If RECURSIVE is non-nil, all files in DIRECTORY are deleted as well.
| TRASH non-nil means to trash the directory instead, provided
| `delete-by-moving-to-trash' is non-nil.
| 
| When called interactively, TRASH is t if no prefix argument is
| given.  With a prefix argument, TRASH is nil.
| 
| [back]
`

The second argument to `delete-directory' ensures that subdirectories
are recursively deleted.  Are you using a different version of Emacs
(maybe XEmacs?) in which `delete-directory' accepts a different number
of arguments?

Thanks -- Eric

Noorul Islam  writes:

> Latest pull is throwing error while quitting emacs.
>
> Here is the patch to fix this.
>
> ob.el:  Fix minor bug
>
> * lisp/ob.el (org-babel-remove-temporary-directory) : Pass correct number of
> arguments to (delete-directory)
>
> Thanks and Regards
> Noorul
>
> diff --git a/lisp/ob.el b/lisp/ob.el
> index 33dbfef..32e2a54 100644
> --- a/lisp/ob.el
> +++ b/lisp/ob.el
> @@ -1679,7 +1679,7 @@ of `org-babel-temporary-directory'."
>  (defun org-babel-remove-temporary-directory ()
>"Remove `org-babel-temporary-directory' on Emacs shutdown."
>(when (boundp 'org-babel-temporary-directory)
> -(delete-directory org-babel-temporary-directory t)))
> +(delete-directory org-babel-temporary-directory)))
>  
>  (add-hook 'kill-emacs-hook 'org-babel-remove-temporary-directory)
>  
> ___
> Emacs-orgmode 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] Error during Publishing to HTML

[Noorul Islam]

On Thu, Aug 26, 2010 at 3:23 PM, cyril elkaim  wrote:

> Hi,
>
> I'm using emacs 23.2 on debian/squeeze, and i get a new problem since, i
> think, the upgrade between emacs 23.1 and 23.2. I used to be able to publish
> my project without any problem but since that migration i get the following
> error on one of my org-file (not the other one):
>
> nxml-extend-region: Invalid search bound (wrong side of point)
>
> The file seems nevertheless to be correctly exported and appears to be
> complete but the publishing routine stops in the middle of the exportation.
>
>
Do you mind posting the file here? May be stripped down version which also
faces this issue will be great.

Also please explain the steps to reproduce this issue.

Thanks and Regards
Noorul
___
Emacs-orgmode 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] Error during Publishing to HTML

[cyril elkaim]

Hi,

I'm using emacs 23.2 on debian/squeeze, and i get a new problem since, i
think, the upgrade between emacs 23.1 and 23.2. I used to be able to publish
my project without any problem but since that migration i get the following
error on one of my org-file (not the other one):

nxml-extend-region: Invalid search bound (wrong side of point)

The file seems nevertheless to be correctly exported and appears to be
complete but the publishing routine stops in the middle of the exportation.

If I export the same file to PDF (via LaTex) everything goes fine.

I've search the Web and the list for similar problems that do exist
apparently, but nothing quite like mine.

Maybe it is a change inside the document itself but i have done so many
since the last export that it will be awfully difficult to find which one is
the one to blame :)

If somebody has an idea...

Thanks,

and a kudo for Karsten for this really fabulous software

Cyril Elkaim
___
Emacs-orgmode 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] [Ann] Updates to org-drill (org topics as interactive "flashcards" using spaced repetition)

[Paul Sexton]

Org-Drill has recently been added to the contrib directory of the org 
repository.

Latest version is in repository at:
http://bitbucket.org/eeeickythump/org-drill

I have made a couple of major updates recently. Changelogs are below.
Reports of user experiences are welcome.

Version 1.0
Added README with more detailed documentation.
Items which are failed during session are presented again before the session 
ends.
Items which were failures at the last review session are presented first in the
next session.
Added recognition of leech items, based on excessive number of failures.
Leeches can be skipped or warned about.
When reviewing an item, the prompt shows the number of items remaining.
When the session finishes, the minibuffer shows a brief report givisng
statistics about total time spent reviewing, number of cards that
still need review, etc.
Fixed the regexp for cloze-deleted text.
Optional face for cloze text in org mode buffers.
New card type: twosided.

Version 1.1
Added implementation of SM2 algorithm (now supports both SM2 and SM5).
Add option 'org-drill-spaced-repetition-algorithm': choose either SM2 or SM5
algorithm.
Add option 'org-drill-add-random-noise-to-intervals-p': randomly vary repetition
intervals slightly, to avoid clumping.
Fixed a bug in org-learn's SM5 algorithm (intervals much too long).
Use overlays to display cloze deletions as '[...]' during reviews.
Cloze text can contain hints, which will visible during review.
Add option 'org-drill-failure-quality': customise which quality is regarded as
unambiguous failure (1 or 2).
Expanded documentation, and added section on 'incremental reading', with example
setup.




___
Emacs-orgmode 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] Latest git pull has bug in (org-babel-remove-temporary-directory)

[Noorul Islam]

Latest pull is throwing error while quitting emacs.

Here is the patch to fix this.

ob.el:  Fix minor bug

* lisp/ob.el (org-babel-remove-temporary-directory) : Pass correct number of
arguments to (delete-directory)

Thanks and Regards
Noorul
diff --git a/lisp/ob.el b/lisp/ob.el
index 33dbfef..32e2a54 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -1679,7 +1679,7 @@ of `org-babel-temporary-directory'."
 (defun org-babel-remove-temporary-directory ()
   "Remove `org-babel-temporary-directory' on Emacs shutdown."
   (when (boundp 'org-babel-temporary-directory)
-(delete-directory org-babel-temporary-directory t)))
+(delete-directory org-babel-temporary-directory)))
 
 (add-hook 'kill-emacs-hook 'org-babel-remove-temporary-directory)
 
___
Emacs-orgmode 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] Org-beamer and beamer overlays

[Glyn Millington]

Good Morning :-)

I'm having trouble getting beamer overlays to work properly when
producing slides via org-mode. This may well be due to my not
understanding the documentation!!


I can only get this to work by dropping down into LaTeX - which on this
scale is pretty painless - but feel sure there must be a way to do this
org too.  Can anyone show me how? 

Below are the headers for my beamer-slide template and a frame with
overlays which works.

If it helps, this is Emacs-23.2.1 and org-mode 7.01h

With thanks


Glyn



8<--8<--8<--8<--8<--8<--8<--8<--8<--

#+TITLE: Beamer slide template
#+AUTHOR:GM
#+EMAIL: g...@xyzxyz.orgle
#+DATE:  2010-08-24
#+DESCRIPTION: 
#+KEYWORDS: 
#+LANGUAGE:  en
#+OPTIONS:   H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t 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: 

#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [bigger]
#+latex_header: \mode{\usetheme{Madrid} \usecolortheme{crane}}
#+BEAMER_FRAME_LEVEL: 1
#+BEAMER_HEADER_EXTRA \beamerdefaultoverlayspecification{<+->}

#+COLUMNS: %40ITEM %10BEAMER_env(Env) %9BEAMER_envargs(Env Args) 
%4BEAMER_col(Col) %10BEAMER_extra(Extra)



* The furniture.
Some old some new 

** The Queen's old armchair :B_block:
   :PROPERTIES:
   :BEAMER_env: block
   :BEAMER_envargs: [<+->]
   :END:
# Notice we have to slip into raw LaTeX to make this work
#+begin_LATEX
\begin{itemize}[<+->]
\item Princess Anne 
\item Prince Charles 
\item corgis
\end{itemize}
#+end_LATEX




___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode