[O] org-table-edit-formulas misbehaving in 8.2.7b

[Luke Crook]

I just noticed that org does not jump to the correct cell in the table when 
examining formulas using "org-table-edit-formulas". 
This was working in 8.2.6.  In most cases, it will jump to a different 
location in the buffer.   Example table below.  
Note that I had to break the table formulae onto two 
lines to pass the 80 characters per line rule when posting.

 #+CAPTION: Sector 1
#+NAME: Sector_1
#+TBLNAME: Sector_1
|   | Field Name |  Size | Default Value |
|---++---+---|
| / | <> |<> |   |
| ! ||  bits |   |
|---++---+---|
|   | Field_1| 8 |   |
|   | Field_2| 2 |   |
|   | Field_3| 3 |   |
|   | Reserved   | 3 |   |
|   | Field_4|16 |   |
|---++---+---|
| # | RESERVED   | 0 |   |
| ^ ||   res |   |
|---++---+---|
| # | Total  |32 |   |
| ^ || tbits |   |
#+TBLFM: 
$res=if(mod(vsum(@II..@III),8)=0,0,8-mod(vsum(@II..@III),8))::
$tbits=vsum(@II..@III)+$res

Re: [O] Insert a line separator in table results

[Xavier Garrido]

This also works for me.

Thanks for your help,
Xavier

Le 17/07/2014 00:37, Arun Persaud a écrit :

This works for me.

#+BEGIN_SRC python
 x = [["label 1", "label 2", "label 3"]]
 x.append(None)
 x.append((4, 5, 6))
 x.append((7, 8, 9))
 return (x)
#+END_SRC

#+RESULTS:
| label 1 | label 2 | label 3 |
|-+-+-|
|   4 |   5 |   6 |
|   7 |   8 |   9 |

Arun

Re: [O] Insert a line separator in table results

[Thorsten Jolitz]

Xavier Garrido  writes:

Hi Xavier,

> I would like to be able to do it with =python=... Maybe it is only
> possible with =emacs-lisp= as you suggest.

I don't know python and cannot try it out here either ... but it should
be exactly the same thing:

build and return a list that consists of lists (each table row one list)
and 'hline symbols (each hline one separator line). Does python have
lists and symbols? The latter probably not...

This could be your strategy:
1. build and return a string in (named) python src-block that contains
   a 'table-list' (rows and hlines)
2. use that python-src-block as var for and elisp src-block:
   #+header: :var lst=myPythonBlock
3. read-from-string that list in emacs-lisp
   (read-from-string lst)
4. return the car from the result in source-block

#+name: myPythonBlock
#+begin_src emacs-lisp   # should be python
 (concat "((1 2 3) hline (4 5 6)"
 " (a b c) hline (e f g))")
#+end_src

#+results: myPythonBlock
: ((1 2 3) hline (4 5 6) (a b c) hline (e f g))

#+header: :var lst=myPythonblock
#+begin_src emacs-lisp :results table
 (car (read-from-string lst))
#+end_src

#+results:
| 1 | 2 | 3 |
|---+---+---|
| 4 | 5 | 6 |
| a | b | c |
|---+---+---|
| e | f | g |


but maybe a python programmer can tell you how to do it directly from
python.

> Le 16/07/2014 21:15, Thorsten Jolitz a écrit :
>> Xavier Garrido  writes:
>>
>>> Dear orgers,
>>>
>>> I would like to programmatically insert a line separator when generating
>>> a table result. Below is a minimal working example with =python=
>>> src block
>>>
>>> #+BEGIN_SRC python
>>> x = [("label 1", "label 2", "label 3"), ("-", "-", "-")]
>>> x.append((4, 5, 6))
>>> x.append((7, 8, 9))
>>> return (x)
>>> #+END_SRC
>>>
>>> #+RESULTS:
>>> | label 1 | label 2 | label 3 |
>>> |   - |   - |   - |
>>> |   4 |   5 |   6 |
>>> |   7 |   8 |   9 |
>>>
>>> Is there any possibility to interpret dash as line separator ?
>>
>> #+begin_src emacs-lisp :results table
>>   (list '(1 2 3) 'hline '(a b c) '(d e f) 'hline '(4 5 6))
>> #+end_src
>>
>> #+results:
>> | 1 | 2 | 3 |
>> |---+---+---|
>> | a | b | c |
>> | d | e | f |
>> |---+---+---|
>> | 4 | 5 | 6 |

-- 
cheers,
Thorsten

Re: [O] Insert a line separator in table results

[Arun Persaud]

This works for me.

#+BEGIN_SRC python
x = [["label 1", "label 2", "label 3"]]
x.append(None)
x.append((4, 5, 6))
x.append((7, 8, 9))
return (x)
#+END_SRC

#+RESULTS:
| label 1 | label 2 | label 3 |
|-+-+-|
|   4 |   5 |   6 |
|   7 |   8 |   9 |

Arun

Re: [O] Insert a line separator in table results

[Xavier Garrido]

Dear Thorsten,

I would like to be able to do it with =python=... Maybe it is only 
possible with =emacs-lisp= as you suggest.


Xavier

Le 16/07/2014 21:15, Thorsten Jolitz a écrit :

Xavier Garrido  writes:


Dear orgers,

I would like to programmatically insert a line separator when generating
a table result. Below is a minimal working example with =python= src block

#+BEGIN_SRC python
x = [("label 1", "label 2", "label 3"), ("-", "-", "-")]
x.append((4, 5, 6))
x.append((7, 8, 9))
return (x)
#+END_SRC

#+RESULTS:
| label 1 | label 2 | label 3 |
|   - |   - |   - |
|   4 |   5 |   6 |
|   7 |   8 |   9 |

Is there any possibility to interpret dash as line separator ?


#+begin_src emacs-lisp :results table
  (list '(1 2 3) 'hline '(a b c) '(d e f) 'hline '(4 5 6))
#+end_src

#+results:
| 1 | 2 | 3 |
|---+---+---|
| a | b | c |
| d | e | f |
|---+---+---|
| 4 | 5 | 6 |

[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug

[Lionel Henry]

I cannot reproduce it with emacs -Q
I will try to investigate which of my settings causes the problem.

Thanks for your time.


Le 16 juil. 2014 à 18:38, Eli Zaretskii  a écrit :

>> From: Lionel Henry 
>> Date: Wed, 16 Jul 2014 15:39:04 +0200
>> 
>> Activating both linum-mode and org-indent-mode will cause several graphical 
>> glitches in the current line.
>> See http://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg01204.html
> 
> That discussion provides no reproducible recipe.
> 
> If I start "emacs -Q", visit an Org file, then invoke org-indent-mode
> in that Org buffer, and finally turn on linum-mode, I see nothing like
> this:
> 
>  clicking on any line in an org-mode file will cause the cursor and
>  text on the line to quickly shift back a few spaces, and the line
>  number for that line to disappear, and then after a fraction of a
>  second it will return to normal.
> 
> When I click on a line, nothing happens, except that the cursor jumps
> to the place where I clicked.
> 
> I tried with both the latest trunk and emacs-24 branch, using the
> version of Org provided with each branch.
> 
> So please provide a reproducible recipe, starting from "emacs -Q", and
> perhaps also an Org file where you see the problem.  If there is a
> need to use a version of Org newer than the ones currently in the
> Emacs repository, please tell where to get that version of Org.
> 
> Thank you.

Re: [O] [PATCH] better parsing of latex fragments

[Nicolas Goaziou]

Hello,

Florian Beck  writes:

> this patch allows, once again, latex fragments inside parentheses and
> also fragments like $\left(\frac12\right.$

AFAIR, this syntax wasn't valid before. This limitation is due to the
fact that $ is also a currency.

In doubt, use \(...\).


Regards,

-- 
Nicolas Goaziou

Re: [O] Insert a line separator in table results

[Thorsten Jolitz]

Xavier Garrido  writes:

> Dear orgers,
>
> I would like to programmatically insert a line separator when generating 
> a table result. Below is a minimal working example with =python= src block
>
> #+BEGIN_SRC python
>x = [("label 1", "label 2", "label 3"), ("-", "-", "-")]
>x.append((4, 5, 6))
>x.append((7, 8, 9))
>return (x)
> #+END_SRC
>
> #+RESULTS:
> | label 1 | label 2 | label 3 |
> |   - |   - |   - |
> |   4 |   5 |   6 |
> |   7 |   8 |   9 |
>
> Is there any possibility to interpret dash as line separator ?

#+begin_src emacs-lisp :results table
 (list '(1 2 3) 'hline '(a b c) '(d e f) 'hline '(4 5 6))
#+end_src

#+results:
| 1 | 2 | 3 |
|---+---+---|
| a | b | c |
| d | e | f |
|---+---+---|
| 4 | 5 | 6 |


-- 
cheers,
Thorsten

[O] Insert a line separator in table results

[Xavier Garrido]

Dear orgers,

I would like to programmatically insert a line separator when generating 
a table result. Below is a minimal working example with =python= src block


#+BEGIN_SRC python
  x = [("label 1", "label 2", "label 3"), ("-", "-", "-")]
  x.append((4, 5, 6))
  x.append((7, 8, 9))
  return (x)
#+END_SRC

#+RESULTS:
| label 1 | label 2 | label 3 |
|   - |   - |   - |
|   4 |   5 |   6 |
|   7 |   8 |   9 |

Is there any possibility to interpret dash as line separator ?

Thanks for your help,
Xavier

Re: [O] random weekly event

[Ivan Kanis]

July, 15 at 23:58 Thorsten Jolitz wrote:

> Ivan Kanis  writes:
>
>> I need to have org agenda (and then appt) manage an event once a week.
>> The catch is that is should happen at a random day and hour.
>>
>> My thinking is that populating programmatically a year entry is probably
>> the sanest way to go about it.
>>
>> Has anyone else done it?
>
> This is not an arcane scientific solution, but should give a random
> timestamp for between tomorrow and the end of the current week. You
> could write a function (using run-with-timer) that runs this sunday at
> 00:00h and inserts a todo item with the returned timestamp into an
> agenda file:

Hi Thorsten,

Thanks it will get me there when I will write it. I turn off emacs at
home and at work so the run-with-timer will not work.

Take care,

Ivan
-- 
Hard drive sleeping. Let it wake up on it's own...
-- BOFH excuse #43

[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug

[Michael Heerdegen]

Michael Heerdegen  writes:

> > > Activating both linum-mode and org-indent-mode will cause several
> > > graphical glitches in the current line.
> > > See
> > > http://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg01204.html
> >
> > That discussion provides no reproducible recipe.

But I think I found something that is related (before-string overlays
vs. text properties) and is reproducible for emacs -Q:

- visit a file under version control (I tried a git controlled file here)
- M-x vc-annotate
- v (i.e. vc-annotate-toggle-annotation-visibility)
- M-x linum-mode

==> all lines but one loose their coloring.  Those lines that are still
colored loose their line number.

nlinum-mode behaves similarly.


Michael.

[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug

[Michael Heerdegen]

Eli Zaretskii  writes:

> > Activating both linum-mode and org-indent-mode will cause several
> > graphical glitches in the current line.
> > See
> > http://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg01204.html
>
> That discussion provides no reproducible recipe.

FWIW, I think we see something similar or related in helm:

  https://github.com/emacs-helm/helm/issues/560

Sadly, there's also no recipe for emacs -Q.


Michael.

Re: [O] emails written in Org Mode

[Joseph Vidal-Rosset]

Many thanks for this effort, Eric. I will try to test Gnorb as soon as
possible.

Best wishes

Jo.


2014-07-16 5:03 GMT+02:00 Eric Abrahamsen :

> Joseph Vidal-Rosset  writes:
>
> > Hello,
> >
> > This is very interesting indeed. But is there somewhere a good
> > tutorial to read or video to see ? It would be helpful for people who
> > want to use Gnus + Org-mode in optimal way.
>
> Someone asked me about a screencast recently, around the same time that
> I realized the README isn't actually very readable! Part of getting the
> package Elpa-ready will also be writing a proper Info manual.
>
> For the time being, the very basics of email tracking (though Gnorb does
> a lot more) would look like this:
>
> 1. Start by making a TODO which represents a message that you have to
>send. That could be using plain old capture on an incoming message
>you want to reply to. Or using gnorb-gnus-outgoing-do-todo on a
>message while you're composing it. Or just typing out a TODO. One way
>or the other, you want a TODO heading that contains a mailto link, or
>a bbdb link, or a gnus message link (or some combination thereof).
>
> 2. Call gnorb-org-handle-mail on that heading. You'll end up composing a
>message of some sort.
>
> 3. Send the message. You'll be taken back to the original TODO heading,
>and prompted to take a note or change the TODO state. For example,
>from EMAIL to WAIT. It's useful to enable state-change logging.
>
> 4. Wait for a reply. When you get it, Gnorb will know (I hope) that the
>reply is relevant to the original TODO, and will prompt you to call
>gnorb-gnus-incoming-do-todo on the message. Do that.
>
> 5. Again you'll be taken back to the TODO, and prompted to take a note
>or change the TODO state -- for example, from WAIT to REPLY. A link
>to the received message can (and should) be inserted into the
>state-change drawer.
>
> 6. Go back to step two, and repeat until your email conversation is
>done.
>
> What it boils down to is calling gnorb-org-handle-mail on your TODO
> heading, and gnorb-gnus-incoming-do-todo on received messages.
> Everything else is gravy. (But there's a lot of gravy!)
>
> The moment something doesn't work the way you like it, look at the
> customization options.
>
> Maybe what I need here is a diagram...
>
> Eric
>
> > 2014-07-15 16:11 GMT+02:00 Alan Schmitt <
> > alan.schm...@polytechnique.org>:
> >
> > On 2014-07-15 02:57, Thorsten Jolitz  writes:
> >
> > > Hadn't have the time to try Gnorb, but the combination of gnus&
> > org is
> > > definitely interesting for me.
> >
> > I highly recommend this library. I haven't scratched the surface,
> > but
> > one great "aha" moment was when I was reading in email in gnus
> > and saw
> > a message in the minibuffer about a relevant task from my todo
> > list.
> >
> > I mostly use it to track "waiting for" sent email: after sending
> > an
> > email, with one keystroke I can create a waiting for task with a
> > link to
> > the sent email. I also use it to create "reply to" tasks.
> >
> > Alan
> >
> > --
> > OpenPGP Key ID : 040D0A3B4ED2E5C7
>

[O] [PATCH] New option for org-notmuch links

[Suvayu Ali]

Hi,

The latest version of notmuch (actually for quite a while now) ships
with an alternate nicely threaded search interface called notmuch-tree.
Earlier this was in contrib, but now it is part of core.  So I thought
it would be nice to use that to follow org-notmuch links.

Attached are two patches: the first adds the customize options, the
second provides a function that uses notmuch-tree to follow links.  The
defaults are set to the old behaviour, so this should not cause any
surprises.

I have done some light testing, and the patches seem to behave nicely.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.
>From bf01edab91f50a6360e142a3762ad259e1db3f05 Mon Sep 17 00:00:00 2001
From: Suvayu Ali 
Date: Wed, 16 Jul 2014 18:08:36 +0200
Subject: [PATCH 1/2] contrib/lisp/org-notmuch.el: customisable notmuch open
 functions

* contrib/lisp/org-notmuch.el: org-notmuch-open-function,
  org-notmuch-open-search-function: New defcustoms, can be used to set
  custom notmuch-open functions.
---
 contrib/lisp/org-notmuch.el | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/contrib/lisp/org-notmuch.el b/contrib/lisp/org-notmuch.el
index 2ab5c17..e6dbfa6 100644
--- a/contrib/lisp/org-notmuch.el
+++ b/contrib/lisp/org-notmuch.el
@@ -41,6 +41,29 @@
 
 (require 'org)
 
+;; customisable notmuch open functions
+(defcustom org-notmuch-open-function
+  'org-notmuch-follow-link
+  "Function used to follow notmuch links.
+
+Should accept a notmuch search string as the sole argument."
+  :group 'org-notmuch
+  :version "24.4"
+  :package-version '(Org . "8.0")
+  :type 'function)
+
+(defcustom org-notmuch-search-open-function
+  'org-notmuch-search-follow-link
+  "Function used to follow notmuch-search links.
+
+Should accept a notmuch search string as the sole argument."
+  :group 'org-notmuch
+  :version "24.4"
+  :package-version '(Org . "8.0")
+  :type 'function)
+
+
+
 ;; Install the link type
 (org-add-link-type "notmuch" 'org-notmuch-open)
 (add-hook 'org-store-link-functions 'org-notmuch-store-link)
@@ -62,7 +85,7 @@
 
 (defun org-notmuch-open (path)
   "Follow a notmuch message link specified by PATH."
-  (org-notmuch-follow-link path))
+  (funcall org-notmuch-open-function path))
 
 (defun org-notmuch-follow-link (search)
   "Follow a notmuch link to SEARCH.
@@ -91,7 +114,7 @@ Can link to more than one message, if so all matching 
messages are shown."
 (defun org-notmuch-search-open (path)
   "Follow a notmuch message link specified by PATH."
   (message path)
-  (org-notmuch-search-follow-link path))
+  (funcall org-notmuch-search-open-function path))
 
 (defun org-notmuch-search-follow-link (search)
   "Follow a notmuch link by displaying SEARCH in notmuch-search mode."
-- 
1.9.3

>From 0aad539c541d4c17cd1ba2c414902a859419efee Mon Sep 17 00:00:00 2001
From: Suvayu Ali 
Date: Wed, 16 Jul 2014 18:17:56 +0200
Subject: [PATCH 2/2] contrib/lisp/org-notmuch.el: new notmuch open function

* contrib/lisp/org-notmuch.el: org-notmuch-tree-follow-link: New function,
  can be used to follow notmuch or notmuch-search links.
---
 contrib/lisp/org-notmuch.el | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/contrib/lisp/org-notmuch.el b/contrib/lisp/org-notmuch.el
index e6dbfa6..ae9b50b 100644
--- a/contrib/lisp/org-notmuch.el
+++ b/contrib/lisp/org-notmuch.el
@@ -121,6 +121,13 @@ Can link to more than one message, if so all matching 
messages are shown."
   (require 'notmuch)
   (notmuch-search (org-link-unescape search)))
 
+
+
+(defun org-notmuch-tree-follow-link (search)
+  "Follow a notmuch link by displaying SEARCH in notmuch-tree mode."
+  (require 'notmuch)
+  (notmuch-tree (org-link-unescape search)))
+
 (provide 'org-notmuch)
 
 ;;; org-notmuch.el ends here
-- 
1.9.3

Re: [O] LaTeX export problem

[Thomas S. Dye]

Aloha Nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> With a recent Org from git and this source:
>>
>>   #+attr_latex: :width 0.8\textwidth :placement [htb]
>>   #+name: fig:harris-errors
>>   #+caption[Structural effects of false transitives]: Structural effects of 
>> false transitives with the stratigraphic section in Figure 
>> [[fig:fig12-open]]:
>
>> I get this incorrect LaTeX output:
>
> [...]
>
>> If I place a space between the final colon and the link on the
>> first #+caption: line, then I get the output I'm expecting (although
>> there is the extraneous space):
>
> [...]
>
>
> This is because regexp finding short captions is greedy. It thus catches
> everything up to the last "]:" in the first line, making the link
> invalid.
>
>> Is there a work-around?
>
> Just make sure the line containing the short caption doesn't end with
> "]:", e.g.,
>
>   ...
>   #+caption[Structural effects of false transitives]:
>   #+caption: Structural effects of false transitives with the stratigraphic 
> section in Figure [[fig:fig12-open]]:
>   ...

Perfect.  Thanks!

All the best,
Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug

[Eli Zaretskii]

> From: Lionel Henry 
> Date: Wed, 16 Jul 2014 15:39:04 +0200
> 
> Activating both linum-mode and org-indent-mode will cause several graphical 
> glitches in the current line.
> See http://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg01204.html

That discussion provides no reproducible recipe.

If I start "emacs -Q", visit an Org file, then invoke org-indent-mode
in that Org buffer, and finally turn on linum-mode, I see nothing like
this:

  clicking on any line in an org-mode file will cause the cursor and
  text on the line to quickly shift back a few spaces, and the line
  number for that line to disappear, and then after a fraction of a
  second it will return to normal.

When I click on a line, nothing happens, except that the cursor jumps
to the place where I clicked.

I tried with both the latest trunk and emacs-24 branch, using the
version of Org provided with each branch.

So please provide a reproducible recipe, starting from "emacs -Q", and
perhaps also an Org file where you see the problem.  If there is a
need to use a version of Org newer than the ones currently in the
Emacs repository, please tell where to get that version of Org.

Thank you.

Re: [O] how to hide titles marked with "DONE"

[Daimrod]

bofe  writes:

> Hi,
>   I use org to manage my projects. When some works are finished ,I
> marked the titles “DONE”,but as time goes by ,there are too many of
> them, that I can’t focus on the rest of unfinished works.
>   Is there a way to hide the “DONE" titles,rather than delete them?

You can toggle the archive tag (C-c C-x a) or archive the tasks
(C-c C-x C-a).

-- 
Daimrod/Greg

Re: [O] Scheduled tasks: total time since last DONE

[J. David Boyd]

Fletcher Charest  writes:

> Dear all,
>
> I'm sorry if this is a common question but I had trouble finding the
> right keywords.
>
> I am a little puzzled by the way scheduled tasks work. I will give an
> example. Let's have this task:
>
> * TODO Clean the kitchen
> SCHEDULED: <2014-07-20 jeu. .+1w>
>
> If I'm lazy and don't do it for one whole week, on 2014-07-27 I will
> see this in my agenda:
>
> Scheduled: TODO Clean the kitchen
>
> But I would really like to see this instead:
>
> Sched. 7x: TODO Clean the kitchen
>
> This way I could see it's been 7 days I didn't do it, and tasks would
> be better organized in the agenda. RIght now, a task that I have to do
> on a weekly basis never has a number greater than '6x', and even if it
> hasn't been done for months, it still appears on the bottom of the
> list in the agenda, with a small number.
>
> So is there a way to correct this? How do you proceed?
>
> Thank you very much for your help!
>
> Regards,
>
> FC


Hmm, I think that is how mine does work.   Sorry, everything is up to date at
the moment, but I'll let one run over and see what it looks like.

Dave

[O] how to hide titles marked with "DONE"

[bofe]

Hi,
I use org to manage my projects. When some works are finished ,I marked 
the titles “DONE”,but as time goes by ,there are too many of them, that I can’t 
focus on the rest of unfinished works.
Is there a way to hide the “DONE" titles,rather than delete them?

Thanks a lot!
-
bofe

[O] how to hide titles marked with "DONE"

[bofe]

Hi,
I use org to manage my projects. When some works are finished ,I marked 
the titles “DONE”,but as time goes by ,there are too many of them, that I can’t 
focus on the rest of unfinished works.
Is there a way to hide the “DONE" titles,rather than delete them?

Thanks a lot!
-
bofe

Re: [O] Beamer export: can't get frame level right

[Josiah Schwab]

On 16 July 2014 at 02:58 PDT, Gabor Retvari wrote:

>> I think you may be using the regular LaTeX exporter.  Adding beamer to
>> your LaTeX_CLASS is not sufficient (or necessary).  Rather, you want to
>> use the Beamer export commands.
>> 
>> http://orgmode.org/manual/Beamer-export.html
>
> Thanks a lot, org-beamer-export-to-pdf seems to solve this issue. 
>
> Interestingly, C-c C-e l P (thank you John for the tip) does not work by 
> default as org-export-dispatch does not seem to know about beamer specific 
> export commands initially. Only after running org-beamer-export-to-pdf once 
> the 
> beamer specific export options show up in the dispatcher's
> list. Strange.

Not all exporters are loaded by default.
http://orgmode.org/manual/Export-back_002dends.html#Export-back_002dends

Have you done something like

,
| (require 'ox-beamer)
`

in your .emacs?  Or customized  `org-export-backends' ?


> Anyways, it would be nice to have this behavior better documented. Maybe a 
> huge 
> warning in the tutorial saying "Use beamer export options, standard LaTeX 
> export will screw up your slide structure!" or somesuch. I see now that the 
> tutorial mentions that "tutorials and references available for both org-mode 
> itself, for LaTeX exporting, and for Beamer Class Export", but the link to 
> the 
> "Beamer Class Export" document does not quite work.
>
> http://orgmode.org/worg/exporters/beamer/tutorial.html

I have fixed the link you mention.

Best,
Josiah

Re: [O] Beamer export: can't get frame level right

[John Hendy]

On Wed, Jul 16, 2014 at 4:58 AM, Gabor Retvari  wrote:
> Hi,
>
> On Monday 14 July 2014 08:29:40 Josiah Schwab wrote:
>> Which export command are you using?
>>
>> I think you may be using the regular LaTeX exporter.  Adding beamer to
>> your LaTeX_CLASS is not sufficient (or necessary).  Rather, you want to
>> use the Beamer export commands.
>>
>> http://orgmode.org/manual/Beamer-export.html
>
> Thanks a lot, org-beamer-export-to-pdf seems to solve this issue.
>
> Interestingly, C-c C-e l P (thank you John for the tip) does not work by
> default as org-export-dispatch does not seem to know about beamer specific
> export commands initially. Only after running org-beamer-export-to-pdf once 
> the
> beamer specific export options show up in the dispatcher's list. Strange.
>
> Anyways, it would be nice to have this behavior better documented. Maybe a 
> huge
> warning in the tutorial saying "Use beamer export options, standard LaTeX
> export will screw up your slide structure!" or somesuch. I see now that the
> tutorial mentions that "tutorials and references available for both org-mode
> itself, for LaTeX exporting, and for Beamer Class Export", but the link to the
> "Beamer Class Export" document does not quite work.
>
> http://orgmode.org/worg/exporters/beamer/tutorial.html

Sorry... looks like a by-product of still being pretty recent on the
new export engine and thus we have some instances of both new/old
instruction sets being out there in the wild. Can you see if this
works properly?
- http://orgmode.org/worg/exporters/beamer/ox-beamer.html

Aka, simply having this in .emacs:

(require 'ox-latex)
(add-to-list 'org-latex-classes
 '("beamer"
   "\\documentclass\[presentation\]\{beamer\}"
   ("\\section\{%s\}" . "\\section*\{%s\}")
   ("\\subsection\{%s\}" . "\\subsection*\{%s\}")
   ("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))


Good luck,
John


> Again, thank you for the help, it really is appreciated.
>
> Regards,
> Gabor
>
>

Re: [O] LaTeX export problem

[Nicolas Goaziou]

Hello,

t...@tsdye.com (Thomas S. Dye) writes:

> With a recent Org from git and this source:
>
>   #+attr_latex: :width 0.8\textwidth :placement [htb]
>   #+name: fig:harris-errors
>   #+caption[Structural effects of false transitives]: Structural effects of 
> false transitives with the stratigraphic section in Figure [[fig:fig12-open]]:

> I get this incorrect LaTeX output:

[...]

> If I place a space between the final colon and the link on the
> first #+caption: line, then I get the output I'm expecting (although
> there is the extraneous space):

[...]


This is because regexp finding short captions is greedy. It thus catches
everything up to the last "]:" in the first line, making the link
invalid.

> Is there a work-around?

Just make sure the line containing the short caption doesn't end with
"]:", e.g.,

  ...
  #+caption[Structural effects of false transitives]:
  #+caption: Structural effects of false transitives with the stratigraphic 
section in Figure [[fig:fig12-open]]:
  ...


Regards,

-- 
Nicolas Goaziou

Re: [O] org strips math delimiters from inline footnotes

[Nicolas Goaziou]

Hello,

Florian Beck  writes:

> the latex export of inline footnotes doesn't work correctly.
>
> This happens since commit ca6ecf9e498e6c4750f279e9f0ea0185bc8b1d10.
>
> text[fn:1: a footnote with $\sqrt{4}$.]
>
> exports as
>
> text\footnote{a footnote with \sqrt{4}.}

This should be fixed.  Thank you for reporting it.


Regards,

-- 
Nicolas Goaziou

Re: [O] fill-paragraph running slowly in org mode

[Nicolas Goaziou]

Hello,

Sean Markan  writes:

> I just upgraded to a new version of Linux/emacs/org-mode, and am finding
> that fill-paragraph (M-q) runs very slowly in org-mode on large files.
> With about 50k lines in the buffer, fill-paragraph takes around 3 seconds
> even if the paragraph is only a couple lines.  (The behavior is correct,
> the problem is just the slowness.)  The time seems to scale linearly with
> the number of lines in the buffer as if the whole file is being processed
> during each fill-paragraph.

Actually, the full section is processed. It can be slow on very large
sections, indeed. Though, you could use a profiler (M-x profiler-start)
to check if something is suspicious.

Note that Org 8.3+ makes it a lot better with a cache mechanism, but it
is still buggy at the moment.

> I have tried (setq  fill-paragraph-function nil) in an effort to use emacs'
> default fill function instead of org mode's, but that did not fix the
> problem.

You could set it locally, in a hook (e.g., `org-mode-hook').


Regards,

-- 
Nicolas Goaziou

[O] Documentation for Beamer export headlines

[gmail]

Thanks to Gabor's code I learned that the new way to get headlines and sections 
is with "#+OPTIONS: H:2". I had spent far too much time trying to google and 
through the .el file to figure this out; the command mentioned at 
http://orgmode.org/worg/exporters/beamer/tutorial.html is 
"#+BEAMER_FRAME_LEVEL: 2" which seems to be no longer supported. My searches at 
other sites were no more helpful. So, thank you, Gabor! And, whoever maintains 
documentation on the excellent Org-Beamer export, please update that. Thanks! 
- Tory

emacs-orgmode-requ...@gnu.org writes:

> Send Emacs-orgmode mailing list submissions to
>   emacs-orgmode@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.gnu.org/mailman/listinfo/emacs-orgmode
> or, via email, send a message with subject or body 'help' to
>   emacs-orgmode-requ...@gnu.org
>
> You can reach the person managing the list at
>   emacs-orgmode-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Emacs-orgmode digest..."
>
>
> Today's Topics:
>
>1. Re: Beamer export: can't get frame level right (John Hendy)
>2. Re: Org mode 8.2.5h and emacs-24.3.1: exporting org-beamer
>   presentation doesn't break presentation in slides (Josiah Schwab)
>3. Re: Org mode 8.2.5h and emacs-24.3.1: exporting org-beamer
>   presentation doesn't break presentation in slides (Nick Dokos)
>4. Re: Org mode 8.2.5h and emacs-24.3.1: exporting org-beamer
>   presentation doesn't break presentation in slides (Suhas Pai)
>5. Re: How to call org-display-inline-images so that after a
>   graphviz block is evaluated the image is refreshed? (John Kitchin)
>6. Macros in included file not expanded in batch export (Suvayu Ali)
>7. proposal to make C-c C-c not remove latex overlays (John Kitchin)
>8. [PATCH] better parsing of latex fragments (Florian Beck)
>9. Re: key collision for auto completion (John Kitchin)
>   10. Re: emails written in Org Mode (John Kitchin)
>   11. Re: proposal to make C-c C-c not remove latex overlays
>   (Aaron Ecay)
>   12. Re: emails written in Org Mode (Eric Abrahamsen)
>   13. Re: emails written in Org Mode (Thorsten Jolitz)
>   14. Re: emails written in Org Mode (Eric Abrahamsen)
>   15. Re: proposal to make C-c C-c not remove latex overlays
>   (Grant Rettke)
>   16. Re: still seeing semi-regular lockups (York Zhao)
>   17. Re: Macros in included file not expanded in batch export
>   (Nick Dokos)
>   18. Test failures (Nick Dokos)
>   19. Re: Macros in included file not expanded in batch export
>   (Suvayu Ali)
>   20. Re: Test failures (Achim Gratz)
>   21. Re: Macros in included file not expanded in batch export
>   (Nick Dokos)
>   22. Re: emails written in Org Mode (Alan Schmitt)
>   23. Re: emails written in Org Mode (Joseph Vidal-Rosset)
>   24. Re: Babel : python generate org source block with anextra
>   comma before * characters (Roland DONAT)
>   25. :RESULTS: drawer exported in LaTeX (Roland DONAT)
>
>
> --
>
> Message: 1
> Date: Mon, 14 Jul 2014 13:38:08 -0500
> From: John Hendy 
> To: Josiah Schwab 
> Cc: emacs-orgmode , Gabor Retvari
>   
> Subject: Re: [O] Beamer export: can't get frame level right
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Jul 14, 2014 at 10:29 AM, Josiah Schwab  wrote:
>> Hi Gabor,
>>
>>> I guess this should be easy but I just can't get frame levels right in my
>>> beamer exports.
>>>
>>> So as far as I understand, this should get my first level headlines (`*
>>> headline 1' and stuff) into separate frames in my beamer export.
>>>
>>> ... snipped 61 lines ...
>>>
>>> No `OPTIONS: H:n' setting seems to solve this problem. So how do I get this
>>> right?
>>
>> Which export command are you using?
>>
>> I think you may be using the regular LaTeX exporter.  Adding beamer to
>> your LaTeX_CLASS is not sufficient (or necessary).  Rather, you want to
>> use the Beamer export commands.
>
> Tend to agree. Make sure you're doing C-c C-e l P (capital P).
>
> Attached my result of running your example, which I think is what
> you're looking for?
>
> John
>
> P.S. Don't feel bad. I've done the exact same thing multiple times
> wondering what the hell was going on :)
>
>>
>> http://orgmode.org/manual/Beamer-export.html
>>
>> Hope that helps,
>> Josiah
>>
> -- next part --
> A non-text attachment was scrubbed...
> Name: test.pdf
> Type: application/pdf
> Size: 31662 bytes
> Desc: not available
> URL: 
> 
>
> --
>
> Message: 2
> Date: Mon, 14 Jul 2014 12:15:25 -0700
> From: Josiah Schwab 
> To: Suhas Pai 
> Cc: "emacs-orgmode@gnu.org" 
> Subject: Re: [O] Org mode 8.2.5h and emacs-24.3.1: exporting
>   org-beamer  p

Re: [O] proposal to make C-c C-c not remove latex overlays

[John Kitchin]

I favor the toggling behavior. There is an org-ctrl-c-ctrl-c-hook
variable that can always have functions in it that keep the current
behavior, but that can be removed if they are not desired.

John

Nick Dokos  writes:

> Andreas Leha  writes:
>
>> Hi all,
>>
>> John Kitchin  writes:
>>
>>> I am using org-mode files with equations and code blocks in lectures,
>>> and it is problematic that C-c C-c removes the equation overlays when
>>> running a code block. First, you have to press C-c C-c twice to run the
>>> block, since the first one gets rid of the equations, but then you have
>>> run C-c C-x C-l to get the equations back! and the cycle repeats
>>> throughout a lecture.
>>>
>>> I would prefer that the equations stay untouched, and that the code
>>> blocks run without modifying them. 
>>>
>>> I think the best behavior would be for C-c C-x C-l to toggle the
>>> equations, and to remove the C-c C-c behavior for latex overlays
>>> completely.
>>
>> Since this thread focusses on work arounds and local customizations so
>> far, let me just say, that I completely agree here.  What is the
>> reasoning behind the current key binding?  Is there any benefit over
>> using the same key binding to toggle the state?
>>
>
> I'm inclined to agree too: I imagine it would be very annoying after
> a while.
>
> There are three things that C-c C-c currently undoes in an ad-hoc
> fashion. The first cond clause in the function looks like this:
>
> ,
> |((or (and (boundp 'org-clock-overlays) org-clock-overlays)
> | org-occur-highlights
> | org-latex-fragment-image-overlays)
> | (and (boundp 'org-clock-overlays) (org-clock-remove-overlays))
> | (org-remove-occur-highlights)
> | (org-remove-latex-fragment-image-overlays)
> | (message "Temporary highlights/overlays removed from current buffer"))
> `
>
> So if there are clock overlays or occur highlights or latex fragment
> image overlays, they are undone and the function is finished. This seems
> like a separate issue from the main thrust of what C-c C-c does (and it
> does a lot), so my inclination would be to suggest that each of the
> above conditions be togglable, using the standard keybinding for each
> (C-c C-x C-l for latex fragment image overlay toggling, C-c C-x C-d for
> clock display - occur highlights only happen from org-goto with the "/"
> keybinding, but there is no org-global keybinding I believe).
>
> However there is a variable that modifies that behavior:
>
> ,
> | org-remove-highlights-with-change is a variable defined in `org.el'.
> | Its value is t
> | 
> | Documentation:
> | Non-nil means any change to the buffer will remove temporary highlights.
> | Such highlights are created by `org-occur' and `org-clock-display'.
> | When nil, `C-c C-c needs to be used to get rid of the highlights.
> | The highlights created by `org-preview-latex-fragment' always need
> | `C-c C-c' to be removed.
> `
>
> If most of us leave that variable's value at default, the ad-hoc-kery
> probably does not raise its head except for latex fragments. If that's
> the case, then getting rid of just latex fragment undoing in
> org-ctrl-c-ctrl-c and toggling with C-c C-x C-l is probably the best
> solution. It probably would be a good idea to make the handling of clock
> overlays similar as well and make C-c C-x C-d toggle the clock overlay
> state (I'd be inclined to take that out of org-ctrl-c-ctrl-c as well,
> since I suspect that almost nobody uses it, given the variable above and
> its default value - but that's only a hunch).  That would leave only
> occur highlights to be undone by org-ctrl-c-ctrl-c - which is ugly but
> the function is a kitchen-sink kind of function anyway, so that's
> probably OK.
>
> Alternatively, make org-ctrl-c-ctrl-c undo these things as it does
> today, but only with a triple prefix arg (which afaict is not used
> today).
>
> As Nicolas would say, WDYT?

-- 
---
John Kitchin
Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu

Re: [O] proposal to make C-c C-c not remove latex overlays

[John Kitchin]

DOH! thanks, that is exactly what I forgot to do. This works fine after
you activate it! Thanks.

Nick Dokos  writes:

> John Kitchin  writes:
>
>> Aaron Ecay  writes:
>>
>> Thanks for the advice idea, that is a nice one. It doesn't work for me
>> like this though:
>>
>> #+BEGIN_SRC emacs-lisp
>> (defadvice org-ctrl-c-ctrl-c (around latex-overlays)
>>   "ignore latex overlays in C-cC-c"
>>   (let ((org-latex-fragment-image-overlays nil))
>> ad-do-it))
>> #+END_SRC
>>
>> maybe because that is a buffer local variable?
>>
>
> You probably forgot to activate it:
>
> (ad-activate 'org-ctrl-c-ctrl-c)

-- 
---
John Kitchin
Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu

Re: [O] [bug?, org-element] latex-environment delimiters must be at BOL

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> Looking at org-element-latex-environment-parser LaTeX environments are
> recognized as "[ \t]*begin{\\([A-Za-z0-9]+\\*?\\)}" (for start)
> and "^[ \t]*end{%s}[ \t]*$" (for the end).
>
> However, for e.g. small equations one might want to write
>
> (*) \begin{equation} PLACEHOLDER \end{equation},
>
> i.e. in one line.  This fails to be recognized as the latter regexp is
> not satisfied.  For code generated by humans this is not an issue.
> However, e.g. SymPy generates code in the (*) format.  Prefixing (*)
> with "#+LATEX:" will prevent ox-html from recognizing it.
>
> Should org-element try to catch one-line environments as the one
> above?  Or is it "a can of worms"?

I think allowing them is possible, as long as \end{equation} ends the
last line (with trailing whitespaces tolerated).

I assume that, for simplicity, PLACEHOLDER could be longer than one
line, too.

If Bastien agrees and if you want to provide a patch, please be sure to
include tests in test-org-element.el, and appropriate changes to "Org
Syntax" document. The manual may need to be updated, too.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] ox-latex.el: add out-of-the-box fontification for makefile source block

[Nicolas Goaziou]

Hello,

Rainer M Krug  writes:

> THis patch adds out-of-the-box fontification of makefile source code
> blocks when using the package listings. As the makefile code blocks are
> named =makefile= and the name of the language definition in the package
> =listings= is m=make= the value (makefile "make") is added to the
> variable org-latex-listings-langs.

Thank you for the patch. Since you modify the default value of
a defcustom, could you also add :version and :package-version keywords
to the variable? See `org-latex-known-warnings' for an example.


Regards,

-- 
Nicolas Goaziou

Re: [O] proposal to make C-c C-c not remove latex overlays

[John Kitchin]

That is nice. For those of us using windows sometimes, you can kind of
get super and hyper keys (see
http://ergoemacs.org/emacs/emacs_hyper_super_keys.html). Although,
without also using autohotkey, your super keys are limited because
windows uses some of them (e.g.s-e launches explorer). H-e works fine.

Grant Rettke  writes:

> C-c C-v C-e might seem like a lot but it nice to have control and be
> sure when code is getting evaluated.
>
> That said, I do have a more obvious one using "super" which is indeed, super:
>
> (local-set-key (kbd "s-t") 'org-babel-tangle)
> (local-set-key (kbd "s-e") 'org-babel-execute-maybe)
> Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
> g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
> “Wisdom begins in wonder.” --Socrates
> ((λ (x) (x x)) (λ (x) (x x)))
> “Life has become immeasurably better since I have been forced to stop
> taking it seriously.” --Thompson
>
>
> On Tue, Jul 15, 2014 at 4:00 PM, John Kitchin  wrote:
>> I actually love C-c C-c to run code blocks! Maybe I should just bind it
>> to f5 or something, I am just so used to C-cC-c now!
>>
>> Grant Rettke  writes:
>>
>>> On Mon, Jul 14, 2014 at 7:33 PM, Aaron Ecay  wrote:
 The first is to use the C-c C-v C-e binding to execute source blocks
 rather than C-c C-c.
>>>
>>> Like this?
>>>
>>> (setq org-babel-no-eval-on-ctrl-c-ctrl-c +1)
>>>
>>>
>>
>> --
>> ---
>> John Kitchin
>> Professor
>> Doherty Hall A207F
>> Department of Chemical Engineering
>> Carnegie Mellon University
>> Pittsburgh, PA 15213
>> 412-268-7803
>> http://kitchingroup.cheme.cmu.edu
>
>

-- 
---
John Kitchin
Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu

Re: [O] proposal to make C-c C-c not remove latex overlays

[Nick Dokos]

Andreas Leha  writes:

> Hi all,
>
> John Kitchin  writes:
>
>> I am using org-mode files with equations and code blocks in lectures,
>> and it is problematic that C-c C-c removes the equation overlays when
>> running a code block. First, you have to press C-c C-c twice to run the
>> block, since the first one gets rid of the equations, but then you have
>> run C-c C-x C-l to get the equations back! and the cycle repeats
>> throughout a lecture.
>>
>> I would prefer that the equations stay untouched, and that the code
>> blocks run without modifying them. 
>>
>> I think the best behavior would be for C-c C-x C-l to toggle the
>> equations, and to remove the C-c C-c behavior for latex overlays
>> completely.
>
> Since this thread focusses on work arounds and local customizations so
> far, let me just say, that I completely agree here.  What is the
> reasoning behind the current key binding?  Is there any benefit over
> using the same key binding to toggle the state?
>

I'm inclined to agree too: I imagine it would be very annoying after
a while.

There are three things that C-c C-c currently undoes in an ad-hoc
fashion. The first cond clause in the function looks like this:

,
|((or (and (boundp 'org-clock-overlays) org-clock-overlays)
|   org-occur-highlights
|   org-latex-fragment-image-overlays)
| (and (boundp 'org-clock-overlays) (org-clock-remove-overlays))
| (org-remove-occur-highlights)
| (org-remove-latex-fragment-image-overlays)
| (message "Temporary highlights/overlays removed from current buffer"))
`

So if there are clock overlays or occur highlights or latex fragment
image overlays, they are undone and the function is finished. This seems
like a separate issue from the main thrust of what C-c C-c does (and it
does a lot), so my inclination would be to suggest that each of the
above conditions be togglable, using the standard keybinding for each
(C-c C-x C-l for latex fragment image overlay toggling, C-c C-x C-d for
clock display - occur highlights only happen from org-goto with the "/"
keybinding, but there is no org-global keybinding I believe).

However there is a variable that modifies that behavior:

,
| org-remove-highlights-with-change is a variable defined in `org.el'.
| Its value is t
| 
| Documentation:
| Non-nil means any change to the buffer will remove temporary highlights.
| Such highlights are created by `org-occur' and `org-clock-display'.
| When nil, `C-c C-c needs to be used to get rid of the highlights.
| The highlights created by `org-preview-latex-fragment' always need
| `C-c C-c' to be removed.
`

If most of us leave that variable's value at default, the ad-hoc-kery
probably does not raise its head except for latex fragments. If that's
the case, then getting rid of just latex fragment undoing in
org-ctrl-c-ctrl-c and toggling with C-c C-x C-l is probably the best
solution. It probably would be a good idea to make the handling of clock
overlays similar as well and make C-c C-x C-d toggle the clock overlay
state (I'd be inclined to take that out of org-ctrl-c-ctrl-c as well,
since I suspect that almost nobody uses it, given the variable above and
its default value - but that's only a hunch).  That would leave only
occur highlights to be undone by org-ctrl-c-ctrl-c - which is ugly but
the function is a kitchen-sink kind of function anyway, so that's
probably OK.

Alternatively, make org-ctrl-c-ctrl-c undo these things as it does
today, but only with a triple prefix arg (which afaict is not used
today).

As Nicolas would say, WDYT?

-- 
Nick

Re: [O] :RESULTS: drawer exported in LaTeX

[Roland DONAT]

Hello,

Nicolas Goaziou  nicolasgoaziou.fr> writes:

> 
> Hello,
> 
> Roland DONAT  gmail.com> writes:
> 
> > You're right, there is something wrong between the parser and the 
> > headlines... I hope it's a bug because I can't think of a reason to 
prevent 
> > user from inserting headlines between drawers, and I pointed, I haven't 
> > other non-dirty solution ;)
> 
> Only headlines can contain headlines. This is the top-most syntax
> element in Org, you cannot put it into something smaller.
> 
> Regards,
> 

Ok, I understand... That I'm dead :(.
Thanks anyway for the explanation, 
Regards,
Roland.

Re: [O] proposal to make C-c C-c not remove latex overlays

[Andreas Leha]

Hi all,

John Kitchin  writes:

> I am using org-mode files with equations and code blocks in lectures,
> and it is problematic that C-c C-c removes the equation overlays when
> running a code block. First, you have to press C-c C-c twice to run the
> block, since the first one gets rid of the equations, but then you have
> run C-c C-x C-l to get the equations back! and the cycle repeats
> throughout a lecture.
>
> I would prefer that the equations stay untouched, and that the code
> blocks run without modifying them. 
>
> I think the best behavior would be for C-c C-x C-l to toggle the
> equations, and to remove the C-c C-c behavior for latex overlays
> completely.

Since this thread focusses on work arounds and local customizations so
far, let me just say, that I completely agree here.  What is the
reasoning behind the current key binding?  Is there any benefit over
using the same key binding to toggle the state?

[...]

Regards,
Andreas

Re: [O] Beamer export: can't get frame level right

[Gabor Retvari]

Hi,

On Monday 14 July 2014 08:29:40 Josiah Schwab wrote:
> Which export command are you using?
> 
> I think you may be using the regular LaTeX exporter.  Adding beamer to
> your LaTeX_CLASS is not sufficient (or necessary).  Rather, you want to
> use the Beamer export commands.
> 
> http://orgmode.org/manual/Beamer-export.html

Thanks a lot, org-beamer-export-to-pdf seems to solve this issue. 

Interestingly, C-c C-e l P (thank you John for the tip) does not work by 
default as org-export-dispatch does not seem to know about beamer specific 
export commands initially. Only after running org-beamer-export-to-pdf once the 
beamer specific export options show up in the dispatcher's list. Strange.

Anyways, it would be nice to have this behavior better documented. Maybe a huge 
warning in the tutorial saying "Use beamer export options, standard LaTeX 
export will screw up your slide structure!" or somesuch. I see now that the 
tutorial mentions that "tutorials and references available for both org-mode 
itself, for LaTeX exporting, and for Beamer Class Export", but the link to the 
"Beamer Class Export" document does not quite work.

http://orgmode.org/worg/exporters/beamer/tutorial.html

Again, thank you for the help, it really is appreciated.

Regards,
Gabor

Re: [O] :RESULTS: drawer exported in LaTeX

[Nicolas Goaziou]

Hello,

Roland DONAT  writes:

> You're right, there is something wrong between the parser and the 
> headlines... I hope it's a bug because I can't think of a reason to prevent 
> user from inserting headlines between drawers, and I pointed, I haven't 
> other non-dirty solution ;)

Only headlines can contain headlines. This is the top-most syntax
element in Org, you cannot put it into something smaller.


Regards,

-- 
Nicolas Goaziou

Re: [O] no src-fontify-natively on emacs 24.4.50.1

[Ian Kelling]

Just want to say that I am experiencing this bug too. I'm using emacs &
org dev sources from the last few days.