Re: [O] Howto: different faces for "begin_src" and "results"

[Miguel Ruiz]

Thank you Bastien, Fabrice, Jambunathan.

In the meantime I have discovered org-font-lock-keywords and related.

Miguel.

> -Original Message-
> From: rbeni...@inbox.com
> Sent: Mon, 10 Mar 2014 02:49:08 -0800
> To: emacs-orgmode@gnu.org
> Subject: [O] Howto: different faces for "begin_src" and "results"
> 
> Hi
> 
> I was wondering if it's possible to have different faces for
> "#+begin_src/#+end_src" and "results" so distinguishing the blocks is
> easier.
> 
> TIA.
> 
> 
> Protect your computer files with professional cloud backup.
> Get PCRx Backup and upload unlimited files automatically.
> Learn more at http://backup.pcrx.com/mail


Protect your computer files with professional cloud backup.
Get PCRx Backup and upload unlimited files automatically. 
Learn more at http://backup.pcrx.com/mail

Re: [O] Bug in export of call lines

[Thomas S. Dye]

Eric Schulte  writes:

> I think it is allowable for raw results to include newlines.  After if R
> returns a newline, the purpose of raw results is specifically to *not*
> change the result.  I believe the best approach is to customize the
> inline results wrap as above, and then use non-raw processed results
> when inline results without newlines are desired.
>
> Does this sound reasonable?

I'm able to export my document correctly by removing :results raw from
the R source code blocks.

I can control wrapping of the results by making the calls :results raw,
which removes the wrap. 

I don't see any change in newline behavior by changing
org-babel-inline-result-wrap.

Unlike your shell block, I don't get an extraneous newline.

I only see unexpected behavior with R source code blocks when :results
raw is set at the source code block.

The following tables summarize what I'm seeing.

* Tables of results:noexport:

With "%s", modified value of org-babel-inline-result-wrap

#+name: R-results
|| call raw   | call not raw |
|++--|
| source raw | newline| verbatim and newline |
| source not raw | no newline | no newline   |

#+name sh-results
|| call raw   | call not raw |
|++--|
| source raw | no newline | no newline   |
| source not raw | no newline | no newline   |

With "=%s=", the default value of org-babel-inline-result-wrap

#+name: R-results-default
|| call raw   | call not raw|
|++-|
| source raw | newline| verbatim and newline, no texttt |
| source not raw | no newline | no newline, texttt  |

#+name sh-results-default
|| call raw   | call not raw   |
|++|
| source raw | no newline | no newline, texttt |
| source not raw | no newline | no newline, texttt |

I'll dig deeper tomorrow to see why my shell source code blocks don't
behave as yours do.  In any case, my document exports again.

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

Re: [O] [PATCH] document org-babel-inline-result-wrap

[Eric Schulte]

Committed, Thanks Tom.

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

> Aloha all,
>
> A brief documentation patch.
>
> All the best,
> Tom
>
>
> From 0b3898a0b0fa9150c6e8de88de267a2db9345bdb Mon Sep 17 00:00:00 2001
> From: tsdye 
> Date: Tue, 11 Mar 2014 15:09:43 -1000
> Subject: [PATCH] Documented org-babel-inline-result-wrap
>
> ---
>  doc/org.texi | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/doc/org.texi b/doc/org.texi
> index 7e66034..62c2476 100644
> --- a/doc/org.texi
> +++ b/doc/org.texi
> @@ -13957,10 +13957,13 @@ its results into the Org mode buffer.
>  @cindex #+CALL
>  
>  It is also possible to evaluate named code blocks from anywhere in an Org
> -mode buffer or an Org mode table.  Live code blocks located in the current
> -Org mode buffer or in the ``Library of Babel'' (see @ref{Library of Babel})
> -can be executed.  Named code blocks can be executed with a separate
> -@code{#+CALL:} line or inline within a block of text.
> +mode buffer or an Org mode table.  These named code blocks can be located in
> +the current Org mode buffer or in the ``Library of Babel'' (see @ref{Library
> +of Babel}).  Named code blocks can be evaluated with a separate
> +@code{#+CALL:} line or inline within a block of text. In both cases
> +the result is wrapped according to the value of
> +@var{org-babel-inline-result-wrap}, which by default is @code{"=%s="} for
> +markup that produces verbatim text.
>  
>  The syntax of the @code{#+CALL:} line is
>  
> -- 
> 1.8.5.5

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] Bug in export of call lines

[Eric Schulte]

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

> Hi Eric,
>
> Eric Schulte  writes:
>
>> This actually is also an issue with shell code blocks.  The fix is to
>> customize the org-babel-inline-result-wrap variable (e.g., as follows)
>> instead of setting the result type to RAW.
>>
>>   (setq org-babel-inline-result-wrap "%s")
>>
>> Perhaps a note about this variable should be added to the description of
>> inline code blocks (both call and src_*) in the manual.
>
> AFAICT, this variable has no effect on export of calls to R source code
> blocks, where the source code block is set with :results raw.
>

Correct, however I believe the following should give the behavior you're
after no?

#+Options: ^:{}

First set the inline result wrap.
#+begin_src emacs-lisp :results silent
  (setq org-babel-inline-result-wrap "%s")
#+end_src

* Desirable newline behavior

The call_r1() should not export with a newline.

#+name: r1
#+begin_src R
2
#+end_src

>
> Also, AFAICT, the behavior of R source code blocks differs from others,
> including shell.
>

#+Options: ^:{}

* Undesirable newline behavior
  :PROPERTIES:
  :results:  raw
  :END:

Both of these *do* introduce undesirable newlines.  A shell code block
call_shell2() and an R code block call_R2().

#+name: shell2
#+begin_src sh
echo 2
#+end_src

#+name: R2
#+begin_src R
2
#+end_src

>
> With the default value of org-babel-inline-result-wrap I get this
> LaTeX
> export:
>
>   \section{Export this subtree raw to \LaTeX{}}
>   \label{sec-1}
>   Will shell-2 export 2 with a newline?
>
>   Will r-2 export 2 with a newline?
>
>   Will shell-2-raw export 2 with a newline?
>
>   Will r-2-raw export 2
>with a newline?
>   \section{Export this subtree without raw to \LaTeX{}}
>   \label{sec-2}
>
>   Will shell-2 export \texttt{2} with a newline?
>
>   Will r-2 export \texttt{2} with a newline?
>
>   Will shell-2-raw export \texttt{2} with a newline?
>
>   \begin{verbatim}
>   Will r-2-raw export 2
>   \end{verbatim}
>   with a newline?
>   % Emacs 24.3.1 (Org mode 8.2.5h)
>
> With org-babel-inline-result-wrap set to "%s" I get this:
>
>   \section{Export this subtree raw to \LaTeX{}}
>   \label{sec-1}
>   Will shell-2 export 2 with a newline?
>
>   Will r-2 export 2 with a newline?
>
>   Will shell-2-raw export 2 with a newline?
>
>   Will r-2-raw export 2
>with a newline?
>   \section{Export this subtree without raw to \LaTeX{}}
>   \label{sec-2}
>
>   Will shell-2 export 2 with a newline?
>
>   Will r-2 export 2 with a newline?
>
>   Will shell-2-raw export 2 with a newline?
>
>   \begin{verbatim}
>   Will r-2-raw export 2
>   \end{verbatim}
>   with a newline?
>   % Emacs 24.3.1 (Org mode 8.2.5h)
>
> Note that there is no change in the LaTeX export of the R calls.
>
> I think this is a bug in ob-R.el.  From my experiments, it behaves
> differently than the other babel languages, including shell.
>
> For LaTeX export, the workaround is to avoid :results raw with R source
> code blocks. Although a spurious newline is inserted into the source,
> this is ignored by LaTeX.
>

I think it is allowable for raw results to include newlines.  After if R
returns a newline, the purpose of raw results is specifically to *not*
change the result.  I believe the best approach is to customize the
inline results wrap as above, and then use non-raw processed results
when inline results without newlines are desired.

Does this sound reasonable?

Best,

>
> All the best,
> Tom

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] tabs inserted in code blocks

[Nick Dokos]

"Stephen J. Barr"  writes:

> Hello,
>
> I have the following code block in an org-mode file:
>
> 
>
> #+CAPTION: Matlab Dynamic Programming Solution
> #+LABEL: code:matlab-outer-loop-reference
> #+BEGIN_SRC octave  
>   Normal_BuildT = realmax * ones(T, i_max, j_max);
>   for i=(1:i_max)
>   for j=(1:j_max)
>   Normal_BuildT(T,i,j) = compute_cell_final(i,j);
>   end
>   end
>   
>   for t=((T-1):-1:1)
>   for i=(1:i_max)
>   for j=(1:j_max)
>  Normal_BuildT(t,i,j) = compute_cell(t,i,j, 
> Normal_BuildT(t+1,:,:));
>   end
>   end
>   end
> #+END_SRC 
>
> 
>
> I am exporting this to LaTeX, which gives me the following code.
> See that there are tab characters inserted before the lines with 
> Normal_BuildT. 
> This is causing minted to render with these strange ^^I characters. 
>
> 
>
> \begin{listing}[H]
> \begin{minted}[]{octave}
> Normal_BuildT = realmax * ones(T, i_max, j_max);
> for i=(1:i_max)
> for j=(1:j_max)
>   Normal_BuildT(T,i,j) = compute_cell_final(i,j);
> end
> end
>
> for t=((T-1):-1:1)
> for i=(1:i_max)
>   for j=(1:j_max)
>  Normal_BuildT(t,i,j) = compute_cell(t,i,j, Normal_BuildT(t+1,:,:));
>   end
> end
> end
> \end{minted}
> \caption{\label{code:matlab-outer-loop-reference}Matlab Dynamic Programming 
> Solution}
> \end{listing}
>
> 
>
> How do I disable this behavior?
>

Untested and not sure it'll work: (setq indent-tabs-mode nil) or perhaps
(setq-default indent-tabs-mode nil) - in the latter case, you might have
to turn it on in specific modes. You will also have to restart emacs.

-- 
Nick

[O] mark parent of current heading

[Matt Price]

is it possible to mark, not the current subtree, but one level up from
the current subtree?  I would like to add that level to the org
bindings for expand-region,

https://github.com/magnars/expand-region.el/blob/master/the-org-mode-expansions.el

Thanks folks!

Matt

[O] Export problem with #+BEGIN_EXAMPLE block

[Christian Wittern]

Dear Orgmode users,

The following minimal example shows a problem I have with export (tested 
with 8.25 from git and the one bundled in Emacs 24.3.1):


#+OPTIONS: toc:nil ^:nil
* Page numbers
  The page number is given in the following form:
#+BEGIN_EXAMPLE

#+END_EXAMPLE


Whatever I do, neither an export to HTML nor to PDF shows the part within 
the example block.  In the real file, there is in fact a part of the text 
after the example also falling out, but I tried to remove everything to make 
a minimal example.  Any ideas what might wrong here are welcome.


Christian

--
Christian Wittern, Kyoto

Re: [O] Insert TODO Item at Bottom

[Esben Stien]

Bastien  writes:

> From git master repo, you can now use C-u C-u M-RET or C-u C-u S-M-RET
> to insert the subtree at the end of the parent subtree.

Hmm, to insert the subtree at the end of the parent subtree is not what
I needed. I need a way to insert the new TODO at the bottom of "inside"
the current node.

F.ex take this tree: 

** foo
*** TODO 1
*** TODO 2
*** TODO 3

If I stand on "foo" and hit a key combination, I want to insert a new
TODO at the bottom of the current node, so that it becomes "TODO 4"

Any way to do this?

-- 
Esben Stien is b0ef@e s  a 
 http://www. s tn m
  irc://irc.  b  -  i  .   e/%23contact
   sip:b0ef@   e e 
   jid:b0ef@n n

Re: [O] Insert TODO Item at Bottom

[Esben Stien]

Bastien  writes:

> From git master repo, you can now use C-u C-u M-RET or C-u C-u S-M-RET
> to insert the subtree at the end of the parent subtree.

Oh, I didn't catch this. Thanks;). I'll try immediately.

-- 
Esben Stien is b0ef@e s  a 
 http://www. s tn m
  irc://irc.  b  -  i  .   e/%23contact
   sip:b0ef@   e e 
   jid:b0ef@n n

[O] [PATCH] Support for links to Ebib's entries

[Daimrod]

Hi,

I've attached a small patch to support links (opening and storing) to
Ebib's[1] entries.

Can I integrate it?

1: http://joostkremers.github.io/ebib/

From acd007302d56d40189659853ef146407bb64ba20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= 
Date: Wed, 12 Mar 2014 08:06:13 +0900
Subject: [PATCH] contrib/lisp/org-ebib.el: Support for links to Ebib's entries

* contrib/lisp/org-ebib.el: Support for links to Ebib's entries.
(org-ebib-open): Open an Ebib's entry.
(org-ebib-store-link): Store a link to an Ebib's entry.
---
 contrib/lisp/org-ebib.el | 47 +++
 1 file changed, 47 insertions(+)
 create mode 100644 contrib/lisp/org-ebib.el

diff --git a/contrib/lisp/org-ebib.el b/contrib/lisp/org-ebib.el
new file mode 100644
index 000..2136a13
--- /dev/null
+++ b/contrib/lisp/org-ebib.el
@@ -0,0 +1,47 @@
+;;; org-ebib.el - Support for links to Ebib's entries in Org
+;;
+;; Author: Grégoire Jadi 
+;;
+;; This file is not yet part of GNU Emacs.
+;;
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 3, or (at your option)
+;; any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see .
+;
+;;
+;;; Commentary:
+
+(require 'org)
+
+(org-add-link-type "ebib" 'org-ebib-open)
+
+(add-hook 'org-store-link-functions 'org-ebib-store-link)
+
+(defun org-ebib-open (key)
+  "Open Ebib and jump to KEY."
+  (ebib nil key))
+
+(defun org-ebib-store-link ()
+  "Store a key to an Ebib entry."
+  (when (memq major-mode '(ebib-index-mode ebib-entry-mode))
+;; This is an Ebib entry
+(let* ((key (ebib-cur-entry-key))
+   (link (concat "ebib:" key))
+   (description (ignore-errors (ebib-db-get-field-value 'title key ebib-cur-db
+  (org-store-link-props
+   :type "ebib"
+   :link link
+   :description description
+
+(provide 'org-ebib)
+
+;;; org-ebib.el ends here
-- 
1.8.0.2722.gc0242e5


-- 
Daimrod/Greg


signature.asc
Description: PGP signature

[O] Single Search Hit and Quick Jump

[Esben Stien]

I have a long tree, like this: 

* foo
** bar
*** baz
 hukarz
 qux
 quux
*** corge
 grault
text: corge
 garply
text: corge
*** azerty
 plugh
text: corge
 ethud
corge

Now, If I f.ex do C-c a s corge, I get multiple hits, but I really only
search for level 3 items always. Is there any way to restrict the search
to only level 3 items?

Also, when I find a result, I want to jump to the last item in that
tree, so if I search for "corge", I want to end up with point on the
level 4 item " garply"

Any pointers as to how I can do this?

-- 
Esben Stien is b0ef@e s  a 
 http://www. s tn m
  irc://irc.  b  -  i  .   e/%23contact
   sip:b0ef@   e e 
   jid:b0ef@n n

[O] Org-Mobile -- clearing the tasks for testing purposes

[David Masterson]

If I setup a set of test cases for org-mobile, how do I then clear out
MobileOrg after the tests and prepare to use it in production?  Is there
ways that I can flip back and forth between Org-Mobile environments
without getting messed up by leftovers in either Emacs or MobileOrg?
-- 
David Masterson

[O] [PATCH] Update documentation for :exports (applicable to blocks only, not inline)

[John Hendy]

Per Eric's comment to a previous thread, I took a stab at updating two
locations in the documentation that discuss using the :exports options
so that users (like myself!) don't try to use them on inline code
blocks.
- http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg00285.html

Patch is attached.

Feel free to counter my changes with suggestions/improvements and I'll
re-submit.


Best regards,
John
From 0b178a22c29c7abe02a30aece6731ce3f77ac12e Mon Sep 17 00:00:00 2001
From: John Henderson 
Date: Tue, 11 Mar 2014 20:33:36 -0500
Subject: [PATCH] updated documentation for :exports argument to specify that
 it's only relevant for blocks, no inline code

---
 doc/org.texi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 7e66034..cd9aa35 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -13828,7 +13828,8 @@ results of code block evaluation.  For information on exporting code block
 bodies, see @ref{Literal examples}.
 
 The @code{:exports} header argument can be used to specify export
-behavior:
+behavior (note that these arguments are only relevant for code blocks, not
+inline code):
 
 @subsubheading Header arguments:
 
@@ -14828,7 +14829,8 @@ which the link does not point.
 @cindex @code{:exports}, src header argument
 
 The @code{:exports} header argument specifies what should be included in HTML
-or @LaTeX{} exports of the Org mode file.
+or @LaTeX{} exports of the Org mode file.  Note that the @code{:exports}
+option is only relevant for code blocks, not inline code.  
 
 @itemize @bullet
 @item @code{code}
-- 
1.9.0

Re: [O] Feature request: edit time stamp from agenda

[Matt Lundin]

torys.ander...@gmail.com (Tory S. Anderson) writes:

> Hello friends, 
> I just discovered org-agenda-diary-entry, which is a terrific command
> to streamline my planning process as I move away from using the raw
> diary file. But it lacks a feature that is key to my usage: it
> conveniently creates a diary item in my configured org file and sticks
> a time stamp on it; but I need to be able to edit that time stamp to
> add an hour to it, so I can plug it into the details of my day. It (I
> would assume `C-.' ) ought to work the same way C-d or C-s does on an
> agenda entry, allowing you to change and refine the deadline/schedule
> time of the item. But search as I might, this doesn't seem to be
> implemented yet.

You can change the timestamp from the agenda with ">".

,[ (info "(org) Agenda commands")
| ‘> (org-agenda-date-prompt)’
|  Change the timestamp associated with the current line.  The key ‘>’
|  has been chosen, because it is the same as ‘S-.’ on my keyboard.
`

> Also, it doesn't really seem to play nicely with adding deadline or
> schedule to the same item, as you will end up with multiple agenda
> entries on the same day for the same item (with the generic timestamp
> being the least useful of these entries). Is there a use case for
> this, or is it as redundant as it looks to me right now?

See the following variables:

org-agenda-skip-deadline-prewarning-if-scheduled
org-agenda-skip-scheduled-if-deadline-is-shown
org-agenda-skip-timestamp-if-deadline-is-shown
org-agenda-skip-additional-timestamps-same-entry

Best,
Matt

[O] [OT] document scanner with ADF

[Samuel Wales]

We had a great discussion about scanners and ADFs here a while back.
The Fujitsu ScanSnap 1500 seemed to be a favorite.  We also talked
about what resolutions to scan at.

What's the current status of document scanners for Linux?  How good
are the ADFs physically?

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

[O] [PATCH] document org-babel-inline-result-wrap

[Thomas S. Dye]

Aloha all,

A brief documentation patch.

All the best,
Tom

>From 0b3898a0b0fa9150c6e8de88de267a2db9345bdb Mon Sep 17 00:00:00 2001
From: tsdye 
Date: Tue, 11 Mar 2014 15:09:43 -1000
Subject: [PATCH] Documented org-babel-inline-result-wrap

---
 doc/org.texi | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 7e66034..62c2476 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -13957,10 +13957,13 @@ its results into the Org mode buffer.
 @cindex #+CALL
 
 It is also possible to evaluate named code blocks from anywhere in an Org
-mode buffer or an Org mode table.  Live code blocks located in the current
-Org mode buffer or in the ``Library of Babel'' (see @ref{Library of Babel})
-can be executed.  Named code blocks can be executed with a separate
-@code{#+CALL:} line or inline within a block of text.
+mode buffer or an Org mode table.  These named code blocks can be located in
+the current Org mode buffer or in the ``Library of Babel'' (see @ref{Library
+of Babel}).  Named code blocks can be evaluated with a separate
+@code{#+CALL:} line or inline within a block of text. In both cases
+the result is wrapped according to the value of
+@var{org-babel-inline-result-wrap}, which by default is @code{"=%s="} for
+markup that produces verbatim text.
 
 The syntax of the @code{#+CALL:} line is
 
-- 
1.8.5.5


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

Re: [O] [PATCH] Change to org-src-preserve-indentation documentation

[John Hendy]

On Sun, Feb 2, 2014 at 3:35 PM, Nicolas Goaziou  wrote:
> Hello,

> Thank you for the patch. It is certainly better than what we have
> actually.
>
> Some comments follow.
>

[snip]

Thanks for the comments, and sorry for the delay in re-submitting!
Hopefully I followed your explanation; I tried to incorporate what
would be relevant in understanding the variable's behavior without
getting too caught in summarizing internals that aren't really
necessary for using the variable successfully.

Let me know if you have further suggestions on the change.


Best regards,
John

>
>
> Regards,
>
> --
> Nicolas Goaziou
From db2109a1fee1fe62dbfbdd0c97e8cf4f6892d74b Mon Sep 17 00:00:00 2001
From: John Henderson 
Date: Tue, 11 Mar 2014 20:23:39 -0500
Subject: [PATCH] modified documentation for org-src-preserve-indentation

---
 doc/org.texi | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 7e66034..42c76b0 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -13804,8 +13804,13 @@ can be used to map arbitrary language names to existing major modes.
 @item org-src-window-setup
 Controls the way Emacs windows are rearranged when the edit buffer is created.
 @item org-src-preserve-indentation
-This variable is especially useful for tangling languages such as
-Python, in which whitespace indentation in the output is critical.
+By default, the value is @code{nil}, which means that when code blocks are
+evaluated during export or tangled, they are re-inserted into the code block,
+which may replace sequences of spaces with tab characters.  When non-nil,
+whitespace in code blocks will be preserved during export or tangling,
+exactly as it appears.  This variable is especially useful for tangling
+languages such as Python, in which whitespace indentation in the output is
+critical.  
 @item org-src-ask-before-returning-to-edit-buffer
 By default, Org will ask before returning to an open edit buffer.  Set this
 variable to @code{nil} to switch without asking.
-- 
1.9.0

Re: [O] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[John Hendy]

On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug  wrote:
>
>
>
> On 02/07/14, 17:47 , Eric Schulte wrote:
> > Rainer M Krug  writes:
> >
> >> On 02/07/14, 07:18 , John Hendy wrote:
> >>> Greetings,
> >>>
> >>>
> >>> I don't usually tangle, but am creating a code file to go along with a
> >>> presentation I'm giving this weekend so that attendees can try things
> >>> out afterward by cloning my github repo where all the data and
> >>> necessary files are stored.
> >>>
> >>> In my presentation (Beamer), I create plots via the R pdf() device,
> >>> and noticed that all of the tangled code where plots are generated
> >>> contains the following:
> >>>
> >>> pdf(file="file.pdf"); tryCatch({
> >>>
> >>>   code block contents here
> >>>
> >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
> >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
> >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
> >>>
> >>> Is there a way to omit this?
> >>
> >> This is a bug which must have been introduced some time ago - in the
> >> stock version of emacs (Org-mode version 7.9.3f
> >> (release_7.9.3f-17-g7524ef @
> >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
> >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
> >> don't have an older version at hand to go further back).
> >>
> >
> > I believe this was introduced by your commit eaa3a761d.  Reversion of
> > which with the following should provide a temporary workaround.
>
> I checked it with version 8.2, which was, as far as I remember, before
> my change of the R code to include the error handling, and the pdf(...)
> ... dev.off() was in the tangled file as well - so the behaviour must
> have been introduced earlier. The only change I did was to change the R
> code, so no change in the behavior if it is tangled or not.
>
> I will look at it again on Monday to go back through the released
> versions to narrow down where this had changed.
>
>

Just following up on this to see if the current behavior is desired or
if, indeed, something should/could change.

Thanks!
John

> >
> >   git revert eaa3a761d
>
> I don't think that this actually changes much - only that the enclosing
> code will become pdf(...) THE CODE dev.off()
>
> Cheers,
>
> Rainer
>
> >
> > Perhaps the try/catch code should be moved from org-babel-expand-body:R
> > to org-babel-execute:R.  Alternately, the code should stay as is and you
> > should use the no-expand header argument during tangling.
> >
> > I'm not sure which makes the most sense, but I'd lean towards the
> > former.
> >
> > Best,
> >
> >>
> >>>
> >>> I'm guessing this is here to create a blank plot with the error as the
> >>> output when something goes awry?
> >>
> >> Yes.
> >>
> >>>
> >>> I checked around variable completions of org-babel-tangle-* and
> >>> searched google for terms like "org babel tangle try catch" but am not
> >>> finding anything that looks like what I need.
> >>
> >> There is nothing, as it should not be tangled. The enclosing commands
> >> concern the export, but not tangling,
> >>
> >> I agree that the :result graphics header argument caused commands should
> >> not be in the tangled file.
> >>
> >> Another question is about the :epilogue and :prologue which I think
> >> should be present (haven't checked if they are...).
> >>
> >> Cheers,
> >>
> >> Rainer
> >>
> >>
> >>>
> >>>
> >>> Thanks,
> >>> John
> >>>
> >
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax :   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
>

Re: [O] Bug in export of call lines

[Thomas S. Dye]

Hi Eric,

Eric Schulte  writes:

> This actually is also an issue with shell code blocks.  The fix is to
> customize the org-babel-inline-result-wrap variable (e.g., as follows)
> instead of setting the result type to RAW.
>
>   (setq org-babel-inline-result-wrap "%s")
>
> Perhaps a note about this variable should be added to the description of
> inline code blocks (both call and src_*) in the manual.

AFAICT, this variable has no effect on export of calls to R source code
blocks, where the source code block is set with :results raw.

Also, AFAICT, the behavior of R source code blocks differs from others,
including shell.

With the default value of org-babel-inline-result-wrap I get this LaTeX
export:

  \section{Export this subtree raw to \LaTeX{}}
  \label{sec-1}
  Will shell-2 export 2 with a newline?

  Will r-2 export 2 with a newline?

  Will shell-2-raw export 2 with a newline?

  Will r-2-raw export 2
   with a newline?
  \section{Export this subtree without raw to \LaTeX{}}
  \label{sec-2}

  Will shell-2 export \texttt{2} with a newline?

  Will r-2 export \texttt{2} with a newline?

  Will shell-2-raw export \texttt{2} with a newline?

  \begin{verbatim}
  Will r-2-raw export 2
  \end{verbatim}
  with a newline?
  % Emacs 24.3.1 (Org mode 8.2.5h)

With org-babel-inline-result-wrap set to "%s" I get this:

  \section{Export this subtree raw to \LaTeX{}}
  \label{sec-1}
  Will shell-2 export 2 with a newline?

  Will r-2 export 2 with a newline?

  Will shell-2-raw export 2 with a newline?

  Will r-2-raw export 2
   with a newline?
  \section{Export this subtree without raw to \LaTeX{}}
  \label{sec-2}

  Will shell-2 export 2 with a newline?

  Will r-2 export 2 with a newline?

  Will shell-2-raw export 2 with a newline?

  \begin{verbatim}
  Will r-2-raw export 2
  \end{verbatim}
  with a newline?
  % Emacs 24.3.1 (Org mode 8.2.5h)

Note that there is no change in the LaTeX export of the R calls.

I think this is a bug in ob-R.el.  From my experiments, it behaves
differently than the other babel languages, including shell.

For LaTeX export, the workaround is to avoid :results raw with R source
code blocks. Although a spurious newline is inserted into the source,
this is ignored by LaTeX.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] words starting with call_ confuse C-c C-c and export

[Nicolas Goaziou]

Eric Schulte  writes:

>> Note there is no limitation on the contents of NAME keywords. Unless the
>> same limitation propagates to those (but should it?), Babel calls will
>> be ignored if forbidden characters are used.
>>
>
> I think it is more important that code block names resemble data names
> than macro names, so I'm afraid that I'm back to my original position of
> preferring to keep as many characters as possible in function names.

You can still have forbidden characters even with the current permissive
regexp:

  #+NAME: how do you call me?

is a valid NAME value but not a valid Babel name.

Another option is, as noted before, to restrict NAME values accordingly.


Regards,

-- 
Nicolas Goaziou

[O] tabs inserted in code blocks

[Stephen J. Barr]

Hello,

I have the following code block in an org-mode file:



#+CAPTION: Matlab Dynamic Programming Solution
#+LABEL: code:matlab-outer-loop-reference
#+BEGIN_SRC octave  
  Normal_BuildT = realmax * ones(T, i_max, j_max);
  for i=(1:i_max)
  for j=(1:j_max)
  Normal_BuildT(T,i,j) = compute_cell_final(i,j);
  end
  end
  
  for t=((T-1):-1:1)
  for i=(1:i_max)
  for j=(1:j_max)
 Normal_BuildT(t,i,j) = compute_cell(t,i,j, Normal_BuildT(t+1,:,:));
  end
  end
  end
#+END_SRC 



I am exporting this to LaTeX, which gives me the following code.
See that there are tab characters inserted before the lines with Normal_BuildT. 
This is causing minted to render with these strange ^^I characters. 



\begin{listing}[H]
\begin{minted}[]{octave}
Normal_BuildT = realmax * ones(T, i_max, j_max);
for i=(1:i_max)
for j=(1:j_max)
Normal_BuildT(T,i,j) = compute_cell_final(i,j);
end
end

for t=((T-1):-1:1)
for i=(1:i_max)
for j=(1:j_max)
   Normal_BuildT(t,i,j) = compute_cell(t,i,j, Normal_BuildT(t+1,:,:));
end
end
end
\end{minted}
\caption{\label{code:matlab-outer-loop-reference}Matlab Dynamic Programming 
Solution}
\end{listing}



How do I disable this behavior?

Thanks,
Stephen

-- 
Sent with my mu4e

Re: [O] advice on ways to quicken refiling..perhaps a hotkey to refile to specific org file/header?

[Oleh]

> I can post the code on github if anyone's interested in the details.
>
> yes please :)
>

Posted here: https://github.com/abo-abo/org-fu

Oleh

Re: [O] advice on ways to quicken refiling..perhaps a hotkey to refile to specific org file/header?

[Xebar Saram]

I can post the code on github if anyone's interested in the details.

yes please :)


thx!

Z

On Tue, Mar 11, 2014 at 5:09 PM, Oleh  wrote:
>
> > On Tue, Mar 4, 2014 at 6:19 PM, Xebar Saram  wrote:
> > Thx Oleh
> >  you said you dont refile much latley, is there a better solution ;-)
>
>
> There is, actually.
> It's quite simple: capture all the tasks into the proper place right away,
> instead of dumping them into one place and sorting out later.
>
> Firstly, there's capturing into project.
> A project is just a heading at gtd.org/Projects/project-name.
> Once a task is in a project, there's rarely any need to refile it.
> I tag each task with the project tag anyway, just in case.
> The project setup is a list entry like this:
>
> '("TINY" "y" "tiny.el")
>
> That's the tag, key binding and heading name. I push this data into
> `org-capture-templates`.
> Now I can capture into project gtd.org/Projects/tiny.el with "C-- y".
>
> Secondly, there's a special capture for pdf files, I've posted it on
> the list before.
>
> Thirdly, there are captures from `org-protocol`. I have this setup:
>
> (setq org-protocol-default-template-key "l")
> (push '("l" "Link" entry (function org-handle-link)
> "* TODO %(org-wash-link)\nAdded: %U\n%(org-link-hooks)\n%?")
>   org-capture-templates)
>
> `org-handle-link` will distinguish:
>
> 1. Links for StackOverflow questions, putting them in wiki/
stack.org/Questions.
> 2. Links to YouTube, downloading the video with `youtube-dl` and
including both
>the link to the original and the downloaded videos in the captured
item.
>I highly recommend `youtube-dl`: watching videos in vlc compared to
firefox
>is like editing in Emacs compared to gedit:)
> 3. All the rest will be dumped into ent.org/Articles.
>
> `org-wash-link` currently just strips the unnecessary " - Stack
> Overflow" from the link description, since the task is already in
> wiki/stack.org/Questions. It's possible to add other rules per website
> of course.
>
> Hopefully some of the described tricks are useful.
> I can post the code on github if anyone's interested in the details.
>
> regards,
> Oleh

Re: [O] words starting with call_ confuse C-c C-c and export

[Eric Schulte]

>>
>> Does this sound about right?
>
> Note there is no limitation on the contents of NAME keywords. Unless the
> same limitation propagates to those (but should it?), Babel calls will
> be ignored if forbidden characters are used.
>

I think it is more important that code block names resemble data names
than macro names, so I'm afraid that I'm back to my original position of
preferring to keep as many characters as possible in function names.

Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] exporter for latex g-brief - #+INCLUDE: escapes curlies \{

[Rasmus]

LanX  writes:

> Thanks for the help so far! :) Unfortunately I'm stuck at this system with
> the old emacs/org-mode version but I'm going to migrate in April anyway.
>
> One more question, I'm trying to put latex code for Adress of recipient and
> so on in external files to be included
>
> unfortunately does
> #+INCLUDE: "filename.tex"

#+LATEX: \input{filename.tex}

-- 
The Kids call him Billy the Saint

Re: [O] exporter for latex g-brief - #+INCLUDE: escapes curlies \{

[LanX]

Thanks for the help so far! :) Unfortunately I'm stuck at this system with
the old emacs/org-mode version but I'm going to migrate in April anyway.

One more question, I'm trying to put latex code for Adress of recipient and
so on in external files to be included

unfortunately does
#+INCLUDE: "filename.tex"

automatically escape the curlies, such that I get

\Postvermerk \{E I N S C H R E I B E N\}

Whats the best way to avoid this? I couldn't find any documentation
regarding this...

cheers
  Rolf



2014-03-10 14:29 GMT+01:00 Rasmus :

> LanX,
>
> LanX  writes:
>
> > Have you tried ox-koma-letter.el?
> >>
> >>
> > not yet, I just started recently switching back to latex and g-brief did
> > what I needed for a formal german letter and I just need it once per
> month
> > so far.
>
> KOMA-Script has build in support for DIM.
>
> >> #+TITLE: title
> >>
> >> #+BEGIN_g-brief
> >> ... here comes text
> >> #+END_g-brief
> >>
> >
> > OK thanks, I take it as indication that the exporter can't be configured
> to
> > do this implicitely...
>
> Sure, you can make a derived class, use a filter or something else.
> Ox-koma-letter is an example of a derived class for letters.  There is
> also a letter exporter using groff as backend.  Note that the special
> heading keywords (see the wiki) are not compatible across the two
> exporters.
>
> > could you please be more specific?
>
> It's a new and in all dimension superior export engine.  On this list
> we'll generally assume you're using a recent version of Org.
> Currently, this implies a version ≥ 8.
>
> Hope it helps,
> Rasmus
>
> --
> This space is left intentionally blank
>
>
>

Re: [O] Bug in export of call lines

[Eric Schulte]

Hi Tom,

This actually is also an issue with shell code blocks.  The fix is to
customize the org-babel-inline-result-wrap variable (e.g., as follows)
instead of setting the result type to RAW.

  (setq org-babel-inline-result-wrap "%s")

Perhaps a note about this variable should be added to the description of
inline code blocks (both call and src_*) in the manual.

Best,

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

> Eric Schulte  writes:
>
>> Somehow this doesn't seem to be a problem with other languages, so I
>> believe the necessary fix may be R specific.
>
> Following is a small test that appears to indicate that the bug is R
> specific and only bites when the source code block has :results raw.
>
>   #+DATE: \today
>   #+LATEX_CLASS: article
>   #+LATEX_CLASS_OPTIONS:
>   #+LATEX_HEADER:
>   #+LATEX_HEADER_EXTRA:
>
>
>   * Export this subtree to LaTeX
> :PROPERTIES:
> :results:  raw
> :END:
>
>   Will lisp-2 export call_lisp-2() with a newline?
>
>   Will python-2 export call_python-2() with a newline?
>
>   Will r-2 export call_r-2() with a newline?
>
>   Will lisp-2-raw export call_lisp-2-raw() with a newline?
>
>   Will python-2-raw export call_python-2-raw() with a newline?
>
>   Will r-2-raw export call_r-2-raw() with a newline?
>
>   * Similar code in three languages
>
>   #+name: lisp-2
>   #+begin_src lisp
>   (+ 1 1)
>   #+end_src
>
>   #+name: python-2
>   #+begin_src python
>   return(1 + 1)
>   #+end_src
>
>   #+name: r-2
>   #+begin_src R
>   1 + 1
>   #+end_src
>
>   #+name: lisp-2-raw
>   #+begin_src lisp :results raw
>   (+ 1 1)
>   #+end_src
>
>   #+name: python-2-raw
>   #+begin_src python :results raw
>   return(1 + 1)
>   #+end_src
>
>   #+name: r-2-raw
>   #+begin_src R :results raw
>   1 + 1
>   #+end_src
>
> Here is the relevant portion of the LaTeX export:
>
>   Will lisp-2 export 2 with a newline?
>
>   Will python-2 export 2 with a newline?
>
>   Will r-2 export 2 with a newline?
>
>   Will lisp-2-raw export 2 with a newline?
>
>   Will python-2-raw export 2 with a newline?
>
>   Will r-2-raw export 2
>with a newline?
>   % Emacs 24.3.1 (Org mode 8.2.5h)
>
> All the best,
> Tom

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

[O] [PATCH] Fix: `org-agenda-skip-scheduled-if-deadline-is-shown': show TODOs without deadline

[Markus]

I noticed that if `org-agenda-skip-scheduled-if-deadline-is-shown' is set
to 'repeated-after-deadline, tasks without a DEADLINE are not shown at
all.  You can reproduce it like this:

1. Setting the variable
(setq org-agenda-skip-scheduled-if-deadline-is-shown
'repeated-after-deadline)

2. Having at least the following tasks

```
** TODO Task 1
   DEADLINE: <2014-03-14 Fri> SCHEDULED: <2014-03-11 Tue +1d>
** TODO Task 2
   SCHEDULED: <2014-03-15 Sat>
```

Without the fix, only 'Task 1' entries are shown in the agenda, after the
fix 'Task 1' and 'Task 2' entries are shown.  I guess this was the intended
semantics, or am I wrong?

I attached the patch.

Best,
Markus
From f83ebc58a7a2d2797a74b9fc1108013319f44ccc Mon Sep 17 00:00:00 2001
From: Markus Hauck 
Date: Tue, 11 Mar 2014 16:06:17 +0100
Subject: [PATCH] Fix: `org-agenda-skip-scheduled-if-deadline-is-shown': show
 TODOs without deadline

* lisp/org-agenda.el (org-agenda-get-scheduled): If
  `org-agenda-skip-scheduled-if-deadline-is-shown' is set to
  'repeated-after-deadline, still show tasks without any deadline

The problem was that the check for the deadline seems to return a
default time even if no deadline is set for the task.  This adds a
check if there is a deadline at all, if there is none, the task is
shown in the agenda, otherwise the old semantics apply.

TINYCHANGE
---
 lisp/org-agenda.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index f9318e1..3ad82aa 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -6250,6 +6250,7 @@ an hour specification like [h]h:mm."
 		category-pos (get-text-property (point) 'org-category-position))
 	  (if (and (eq org-agenda-skip-scheduled-if-deadline-is-shown
 			   'repeated-after-deadline)
+		   (org-get-deadline-time (point))
 		   (<= 0 (- d2 (time-to-days (org-get-deadline-time (point))
 		  (throw :skip nil))
 	  (if (not (re-search-backward "^\\*+[ \t]+" nil t))
-- 
1.8.3

Re: [O] Org Bash Utils

[Samuel Loury]

Hi,
OSiUX  writes:

> Try: org-clock | org-timeline
>
> https://github.com/osiris/org-bash-utils
Awesome :-)!

-- 
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature

Re: [O] advice on ways to quicken refiling..perhaps a hotkey to refile to specific org file/header?

[Oleh]

> On Tue, Mar 4, 2014 at 6:19 PM, Xebar Saram  wrote:
> Thx Oleh
>  you said you dont refile much latley, is there a better solution ;-)


There is, actually.
It's quite simple: capture all the tasks into the proper place right away,
instead of dumping them into one place and sorting out later.

Firstly, there's capturing into project.
A project is just a heading at gtd.org/Projects/project-name.
Once a task is in a project, there's rarely any need to refile it.
I tag each task with the project tag anyway, just in case.
The project setup is a list entry like this:

'("TINY" "y" "tiny.el")

That's the tag, key binding and heading name. I push this data into
`org-capture-templates`.
Now I can capture into project gtd.org/Projects/tiny.el with "C-- y".

Secondly, there's a special capture for pdf files, I've posted it on
the list before.

Thirdly, there are captures from `org-protocol`. I have this setup:

(setq org-protocol-default-template-key "l")
(push '("l" "Link" entry (function org-handle-link)
"* TODO %(org-wash-link)\nAdded: %U\n%(org-link-hooks)\n%?")
  org-capture-templates)

`org-handle-link` will distinguish:

1. Links for StackOverflow questions, putting them in wiki/stack.org/Questions.
2. Links to YouTube, downloading the video with `youtube-dl` and including both
   the link to the original and the downloaded videos in the captured item.
   I highly recommend `youtube-dl`: watching videos in vlc compared to firefox
   is like editing in Emacs compared to gedit:)
3. All the rest will be dumped into ent.org/Articles.

`org-wash-link` currently just strips the unnecessary " - Stack
Overflow" from the link description, since the task is already in
wiki/stack.org/Questions. It's possible to add other rules per website
of course.

Hopefully some of the described tricks are useful.
I can post the code on github if anyone's interested in the details.

regards,
Oleh

Re: [O] [bug] Wrong scrolling with org-agenda-toto in agenda views

[Francesco Pizzolante]

Hi Bastien,

Sorry for my late reply.


>> The view should not scroll at all but only modify the selected task.
>
> I remember fixing this bug a while ago and cannot reproduce it with
> Org from master.
>
> What is the version of Org you use?

Indeed, you're right. I didn't notice that my minimal test was using an
old version of Org. Now, with a recent version of Org, my minimal test
works well.

Anyway, I still have this issue with my full setup... it should then
come from somewhere else. I need some more time to locate the faulty
spot.

Thanks a lot for your help.

Regards,
 Francesco

Re: [O] org-edit-special cannot tell ditaa from table

[Thomas Holst]

Hi,

· zwz  wrote:

> Here is an example:
>
> * test
> #+BEGIN_SRC ditaa
>   ++  +-+
>   ||  | |
>   ||  | |
>   ++  +-+
> #+END_SRC
> When I hit C-c ', the minibuffer says "Recognizing tables...done",
> and the org src scratch buffer does not turn picture-mode on.

I had the same problem. If you insert a blank line at top of the ditaa
block and hit C-c ' with point in that line artist mode comes up. At
least for me.

HTH

-- 
Bis neulich ...
  Thomas

Re: [O] [bug] Incompatible agenda commands

[Sebastien Vauban]

Hello Bastien and Matt,

Matt Lundin wrote:
> Bastien  writes:
>> Sebastien Vauban writes:
>>> "Sebastien Vauban" wrote:
 Bastien wrote:
> "Sebastien Vauban" writes:
>
>> While a custom agenda command such as the following used to work some 
>> time
>> ago, it does not anymore.
>>
>>   (add-to-list 'org-agenda-custom-commands
>>'("D" "Stuck + agenda"
>>  ((stuck "")
>>   (agenda ""
>>   ((org-agenda-span 'week) t)
>>
>> Now, it seems that the "stuck" block view inhibits any extra view to be
>> displayed afterward.
>
> do I understand correctly that you only get the stuck view and not the
> agenda view?  If so, I cannot reproduce it.

 I'll try to provide you with a reproducible recipe, then.
>>>
>>> Add the following line to this ECM:
>>>
>>>   (setq org-agenda-sticky nil)
>>>
>>> and you'll be bitten by that bug!
>>
>> Mhh... still can't reproduce the bug.  Anyone else?
>
> Unfortunately, I cannot reproduce it either. Both the stuck agenda and
> the weekly agenda display on my end.

Sorry, I meant: setting `org-agenda-sticky' to a non-nil value... as nil
is its default value, anyway...

--8<---cut here---start->8---
(require 'org-agenda)

(add-to-list 'org-agenda-custom-commands
 '("D" "Stuck + agenda"
   ((stuck "")
(agenda ""
((org-agenda-span 'week) t)

(setq org-agenda-sticky t)
--8<---cut here---end--->8---

This time (I don't know why I did not see it the other times), I even
see an error message:

--8<---cut here---start->8---
save-current-buffer: No buffer named *Org Agenda(D:+LEVEL=2/-DONE)*
--8<---cut here---end--->8---

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] words starting with call_ confuse C-c C-c and export

[Nicolas Goaziou]

Hello,

Eric Schulte  writes:

> Is "/" allowed in macro names?

No. Macro names use the following regexp:

  [a-zA-Z][-a-zA-Z0-9_]*

> I think the biggest benefit here is
> unification between macro and function names.  Is there a macro name
> regexp which could be used directly (to ensure that these two stay
> unified)?  I don't see one, so I expect we'll want to add an
> org-babel-function-name regexp along the lines of "[a-zA-Z0-9\-\/]+".
> This would then be used in the following variables.
> - org-babel-src-block-regexp
> - org-babel-src-name-w-name-regexp
>
> And the following functions should be updated to ensure that the name
> only includes the allowed characters.
> - org-babel-named-data-regexp-for-name
> - org-babel-named-src-block-regexp-for-name
>
> Does this sound about right?

Note there is no limitation on the contents of NAME keywords. Unless the
same limitation propagates to those (but should it?), Babel calls will
be ignored if forbidden characters are used.


Regards,

-- 
Nicolas Goaziou

Re: [O] Babel should not work in the subtree marked as not exported

[Rainer M Krug]

Ken Mankoff  writes:

> On 2014-03-11 at 08:47, zwz wrote:
>> In my setup, there is 
>> (setq org-export-exclude-tags '("private" "exclude")
>>
>> and In my test.org:
>>
>> * test
>>
>> ** Not exported:exclude:
>>#+BEGIN_SRC ditaa :file test.png :cmdline -E
>>   ++---+---+---+---+---+---+---+  
>> +---+---+---+---+---+---+---+---+
>>   x   | 0 cRED | 0 | 0 | 0 | 0 | 0 | 0 | 0 |  | 0 | 0 | 0 | 0 | 1 | 0 | 
>> 1 | 1 |
>>   ++---+---+---+---+---+---+---+  
>> +---+---+---+---+---+---+---+---+
>>#+END_SRC
>>
>> ** blah blah
>>blah blah blah
>>
>>
>> When I try to export it to pdf, the test.png is still generated,
>> although it is not used for the pdf at all.
>> So I think the export procedure may be optimized for more efficiency.
>
> No, because I often have code and sections I don't want exported, but
> I want their side-effects active. For example, code with sessions
> where part is not exported, but I need that code run so code
> elsewhere, using the same session, is able to run and be exported.

AFAIK, this depends if you use a session. When you are using a session,
*all* code blocks are evaluated, if you do not set the header argument
session, only the ones which are exported are evaluated - precisely the
reason you give.

Rainer

>
>   -k.
>
>

-- 
Rainer M. Krug

email: RMKruggmailcom


pgpTTgnYILt1h.pgp
Description: PGP signature

[O] Org Bash Utils

[OSiUX]

Try: org-clock | org-timeline

https://github.com/osiris/org-bash-utils

-- 

::

  Osiris Alejandro Gomez (OSiUX) os...@osiux.com.ar
  DC44 95D2 0D5D D544 FC1A F00F B308 A671 9237 D36C
  http://www.osiux.com.ar http://www.altermundi.net


signature.asc
Description: Digital signature

Re: [O] Babel should not work in the subtree marked as not exported

[Ken Mankoff]

Hi Andreas,

On 2014-03-11 at 09:41, Andreas Leha wrote:
> Hi Ken,
>
> Ken Mankoff  writes:
>
>> On 2014-03-11 at 08:47, zwz wrote:
>>> In my setup, there is 
>>> (setq org-export-exclude-tags '("private" "exclude")
>>>
>>> and In my test.org:
>>>
>>> * test
>>>
>>> ** Not exported:exclude:
>>>#+BEGIN_SRC ditaa :file test.png :cmdline -E
>>>   ++---+---+---+---+---+---+---+  
>>> +---+---+---+---+---+---+---+---+
>>>   x   | 0 cRED | 0 | 0 | 0 | 0 | 0 | 0 | 0 |  | 0 | 0 | 0 | 0 | 1 | 0 | 
>>> 1 | 1 |
>>>   ++---+---+---+---+---+---+---+  
>>> +---+---+---+---+---+---+---+---+
>>>#+END_SRC
>>>
>>> ** blah blah
>>>blah blah blah
>>>
>>>
>>> When I try to export it to pdf, the test.png is still generated,
>>> although it is not used for the pdf at all.
>>> So I think the export procedure may be optimized for more efficiency.
>>
>> No, because I often have code and sections I don't want exported, but
>> I want their side-effects active. For example, code with sessions
>> where part is not exported, but I need that code run so code
>> elsewhere, using the same session, is able to run and be exported.
>>
>>   -k.
>
>
> So what is your suggestion for the OP to achieve what he is after?
> noexport and noeval at the same time.
>

I do not have a suggestion. I'm not very familiar with the various
options, and didn't know noeval exists. That sounds like a good
solution. The OP suggestion of "may be optimized" is vague, but I took
it, perhaps incorrectly, to mean "don't run code in noexport
sections", hence my disagreement.

  -k.

Re: [O] Babel should not work in the subtree marked as not exported

[Andreas Leha]

Hi Ken,

Ken Mankoff  writes:

> On 2014-03-11 at 08:47, zwz wrote:
>> In my setup, there is 
>> (setq org-export-exclude-tags '("private" "exclude")
>>
>> and In my test.org:
>>
>> * test
>>
>> ** Not exported:exclude:
>>#+BEGIN_SRC ditaa :file test.png :cmdline -E
>>   ++---+---+---+---+---+---+---+  
>> +---+---+---+---+---+---+---+---+
>>   x   | 0 cRED | 0 | 0 | 0 | 0 | 0 | 0 | 0 |  | 0 | 0 | 0 | 0 | 1 | 0 | 
>> 1 | 1 |
>>   ++---+---+---+---+---+---+---+  
>> +---+---+---+---+---+---+---+---+
>>#+END_SRC
>>
>> ** blah blah
>>blah blah blah
>>
>>
>> When I try to export it to pdf, the test.png is still generated,
>> although it is not used for the pdf at all.
>> So I think the export procedure may be optimized for more efficiency.
>
> No, because I often have code and sections I don't want exported, but
> I want their side-effects active. For example, code with sessions
> where part is not exported, but I need that code run so code
> elsewhere, using the same session, is able to run and be exported.
>
>   -k.


So what is your suggestion for the OP to achieve what he is after?
noexport and noeval at the same time.

Regards,
Andreas

Re: [O] advice on ways to quicken refiling..perhaps a hotkey to refile to specific org file/header?

[Yasushi SHOJI]

Hi,

At Tue, 4 Mar 2014 17:43:41 +0200,
Xebar Saram wrote:
> 
> i find the normal C-c w then manually choosing a file to allocate each
> 'capture' pretty slow. i am looking for any advice on workflows you
> guys have to make this quicker.
> 
> one thing i was thinking of was maybe assigning a hotkey to do a
> refile to a specific note/heading. so ill have 5-6 hotkeys to my most
> common files to speed things up, can this be done? if so can anyone
> show my an example of such a thing?

Nice idea.

A quick grance at `org-refile' in org.el, something like this will do:

(defun org-refile-to-myfile ()
  "Refile to myfile.org"
  (interactive)
  (org-refile nil nil '("my refiling pos" "myfile.org" "" 0)))

The 3rd argument seems to be `(list message file re pos)', but not
sure how `re' and `pos' works.  Could someone enlignten me?
-- 
yashi

Re: [O] Babel should not work in the subtree marked as not exported

[Ken Mankoff]

On 2014-03-11 at 08:47, zwz wrote:
> In my setup, there is 
> (setq org-export-exclude-tags '("private" "exclude")
>
> and In my test.org:
>
> * test
>
> ** Not exported:exclude:
>#+BEGIN_SRC ditaa :file test.png :cmdline -E
>   ++---+---+---+---+---+---+---+  
> +---+---+---+---+---+---+---+---+
>   x   | 0 cRED | 0 | 0 | 0 | 0 | 0 | 0 | 0 |  | 0 | 0 | 0 | 0 | 1 | 0 | 1 
> | 1 |
>   ++---+---+---+---+---+---+---+  
> +---+---+---+---+---+---+---+---+
>#+END_SRC
>
> ** blah blah
>blah blah blah
>
>
> When I try to export it to pdf, the test.png is still generated,
> although it is not used for the pdf at all.
> So I think the export procedure may be optimized for more efficiency.

No, because I often have code and sections I don't want exported, but
I want their side-effects active. For example, code with sessions
where part is not exported, but I need that code run so code
elsewhere, using the same session, is able to run and be exported.

  -k.

[O] org-edit-special cannot tell ditaa from table

[zwz]

Here is an example:

* test
#+BEGIN_SRC ditaa
  ++  +-+
  ||  | |
  ||  | |
  ++  +-+
#+END_SRC

When I hit C-c ', the minibuffer says "Recognizing tables...done",
and the org src scratch buffer does not turn picture-mode on.

[O] Babel should not work in the subtree marked as not exported

[zwz]

In my setup, there is 
(setq org-export-exclude-tags '("private" "exclude")

and In my test.org:

* test

** Not exported:exclude:
   #+BEGIN_SRC ditaa :file test.png :cmdline -E
  ++---+---+---+---+---+---+---+  
+---+---+---+---+---+---+---+---+
  x   | 0 cRED | 0 | 0 | 0 | 0 | 0 | 0 | 0 |  | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 
1 |
  ++---+---+---+---+---+---+---+  
+---+---+---+---+---+---+---+---+
   #+END_SRC

** blah blah
   blah blah blah


When I try to export it to pdf, the test.png is still generated,
although it is not used for the pdf at all.
So I think the export procedure may be optimized for more efficiency.

[O] [bug] #+constants line has to be at column 0

[Eric S Fraga]

Hello,

Unlike some other #+ directives, the #+constants: one has to be at
column 0 or else it is not understood/parsed by org.  This has
consequences for lists.  See attached example.

#+TITLE: examplebug.org
#+AUTHOR:Eric S Fraga

* Table constants
Assume that I have a list:
1. and in this list, one of the entries is a table
2. This is the table
#+constants: param=-5

   |   | X |  Y |
   | ! | x |  y |
   |---+---+|
   | # | 1 | -4 |
   | # | 2 | -3 |
   | # | 3 | -2 |
   #+TBLFM: $3=$x+$param

1. The constants line cannot be indented as it is not understood if it is.
2. This means that the list has been interrupted.

Obviously, I can move the constants line elsewhere and/or use the $
directive within the table but I thought that this was an inconsistency
in the parsing of org files?  Maybe not?

Org up to date and verified with emacs -Q.

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.2, Org release_8.2.5h-687-g9d39aa