Re: [O] How to escape an asterisk on org-mode

[Nick Dokos]

James Ryland Miller  writes:

> Hi Org Mode:
>
> I'm trying to escape an asterisk character, i.e. "*" to use in regular
> text. I.e., "The person wanted to say *BSD". And I don't want to use a
> verbatim or code block because monospace is not what I need.
>
> I've tried \* to escape the character and it doesn't work. I'm on Org 8.2.5h.
>

*What* doesn't work?

Since you don't tell us, I tried exporting the following to latex and
html:

--8<---cut here---start->8---
* foo
The person wanted to say *BSD.

--8<---cut here---end--->8---

and it works fine in both cases (albeit in Org-mode version 8.2.6 
(release_8.2.6-1122-g1d7c75)).

-- 
Nick

[O] [Patch] Create org-gnus links to real groups, not virtual groups

[Eric Abrahamsen]

If you create a link to a gnus message while in a nnvirtual group, the
link will become un-followable as soon as you exit the virtual group.
This patch checks to see if we're in a virtual group, and if so it
creates the link to the original group instead.

E

>From 2d1dbbeb071e256ff37be798e8e04689a40665c8 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Thu, 12 Jun 2014 12:53:15 +0800
Subject: [PATCH] Create org-gnus links from original group, not virtual

lisp/org-gnus.el (org-gnus-store-link): If we happen to be in a
		 virtual group when storing a link to a message, we
		 want the link to point to the message's "real" group,
		 as a link to a virtual group can't be followed later.
---
 lisp/org-gnus.el | 4 
 1 file changed, 4 insertions(+)

diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index 2c79347..48afb3c 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -170,6 +170,10 @@ If `org-store-link' was called with a prefix arg the meaning of
 	   (subject (copy-sequence (mail-header-subject header)))
 	   (to (cdr (assq 'To (mail-header-extra header
 	   newsgroups x-no-archive desc link)
+  (when (eq (car (gnus-find-method-for-group gnus-newsgroup-name))
+		  'nnvirtual)
+	(setq group (car (nnvirtual-map-article
+			  (gnus-summary-article-number)
   ;; Remove text properties of subject string to avoid Emacs bug
   ;; #3506
   (set-text-properties 0 (length subject) nil subject)
-- 
2.0.0

[O] How to escape an asterisk on org-mode

[James Ryland Miller]

Hi Org Mode:

I'm trying to escape an asterisk character, i.e. "*" to use in regular
text. I.e., "The person wanted to say *BSD". And I don't want to use a
verbatim or code block because monospace is not what I need.

I've tried \* to escape the character and it doesn't work. I'm on Org 8.2.5h.

Thanks in advance.

[O] bug#17746: bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Daimrod]

Stefan Monnier  writes:

>> +(defun org-recenter (&optional arg)
>> +  "Like `recenter' but ensure that the `current-buffer' is
>> +properly set."
>> +  (with-current-buffer (window-buffer)
>> +(recenter arg)))
>  
> This doesn't make much sense: in many case (window-buffer) can be
> a buffer completely unrelated to Org.

Hmm, what was the previous behaviour of `recenter'? (i.e. before it
reports an error)

Did it just do nothing?

Best,

-- 
Daimrod/Greg

[O] bug#17746: bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Stefan Monnier]

> +(defun org-recenter (&optional arg)
> +  "Like `recenter' but ensure that the `current-buffer' is
> +properly set."
> +  (with-current-buffer (window-buffer)
> +(recenter arg)))
 
This doesn't make much sense: in many case (window-buffer) can be
a buffer completely unrelated to Org.


Stefan

[O] bug#17746: bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Daimrod]

Bastien  writes:

> Nicolas Richard  writes:
>
>> David Griffiths  writes:
>>> Debugger entered--Lisp error: (error "`recenter'ing a window that does
>>> not display current-buffer.")
>>> recenter((4))
>>> org-overview()
>>
>> So that's a duplicate of #17724. It is fixed in org-mode (upstream) master
>> branch. The easy fix is to use emacs-24 branch :)
>>
>> (otherwise just remove that call to recenter in org-overview).
>
> PS: The change about throwing an error when recentering a window
> that does not display the current buffer breaks ~37 tests in Org
> master branch, even with this fix.  I need to digg this further.

Err, what's the rational behind this change?

In the meantime I've a simple fix (quickly tested for `org-agenda' which
was also broken).

>From 659bc5072253967ee2737f668c8ac035a4b8aa32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= 
Date: Thu, 12 Jun 2014 10:14:16 +0900
Subject: [PATCH] Use `org-recenter' as a wrapper around `recenter'

* lisp/org.el (org-recenter): New function that behaves exactly like
`recenter' except that it sets the `current-buffer' to the buffer
displayed by the selected window.

(org-fix-ellipsis-at-bol)
(org-optimize-window-after-visibility-change)
(org-first-headline-recenter)
* contrib/lisp/org-index.el (org-index)
(org-index--create-new-index)
(org-index--do-head)
* contrib/lisp/org-toc.el (org-toc-goto)
* lisp/org-agenda.el (org-agenda-list)
(org-agenda-redo)
(org-recenter-heading)
(org-agenda-recenter)
* lisp/org-bibtex.el (org-execute-file-search-in-bibtex)
* lisp/org-clock.el (org-clock-goto)
* lisp/org-table.el (org-table-show-reference): Use `org-recenter' instead of `recenter'.
---
 contrib/lisp/org-index.el | 12 ++--
 contrib/lisp/org-toc.el   |  4 ++--
 lisp/org-agenda.el| 12 ++--
 lisp/org-bibtex.el|  2 +-
 lisp/org-clock.el |  2 +-
 lisp/org-table.el |  4 ++--
 lisp/org.el   | 13 +
 7 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/contrib/lisp/org-index.el b/contrib/lisp/org-index.el
index 64974eb..f77d64d 100644
--- a/contrib/lisp/org-index.el
+++ b/contrib/lisp/org-index.el
@@ -633,7 +633,7 @@ command \"head\" for reference \"237\".
   ;; simply go into table
   (goto-char org-index--below-hline)
   (show-subtree)
-  (recenter)
+  (org-recenter)
   (if what-adjusted
   (setq message-text "Nothing to search for; at index table")
 (setq message-text "At index table")))
@@ -1581,7 +1581,7 @@ retrieves the value of the count-column for reference 12.
 (org-id-goto id)
 (org-show-context)
 (show-subtree)
-(recenter 1)
+(org-recenter 1)
 (setq org-index-id id)
 (if (y-or-n-p "This is your new index table. It is already set for this emacs session. Do you want to save its id to make it available for future emacs sessions too ? ")
 (progn
@@ -1598,7 +1598,7 @@ retrieves the value of the count-column for reference 12.
 (goto-char org-index--point)
 (org-show-context)
 (show-subtree)
-(recenter 1)
+(org-recenter 1)
 (delete-other-windows)
 ;; show new index
 (select-window (split-window-vertically))
@@ -1606,7 +1606,7 @@ retrieves the value of the count-column for reference 12.
 (org-id-goto id)
 (org-show-context)
 (show-subtree)
-(recenter 1)
+(org-recenter 1)
 (error "Please compare your existing index (upper window) and a temporary new one (lower window) to correct the previous error (\"%s\"); the explanations following the new index table should help." reason)
 
 
@@ -1778,12 +1778,12 @@ retrieves the value of the count-column for reference 12.
 (pop-to-buffer buffer)
 (goto-char point)
 (org-reveal t)
-(recenter)
+(org-recenter)
 (pop-to-buffer "*org-index-occur*"))
 (org-pop-to-buffer-same-window buffer)
 (goto-char point)
 (org-reveal t)
-(recenter)))
+(org-recenter)))
   (setq message-text (format "Did not find '%s'" (or ref link))
 message-text))
 
diff --git a/contrib/lisp/org-toc.el b/contrib/lisp/org-toc.el
index 255b79e..e06de55 100644
--- a/contrib/lisp/org-toc.el
+++ b/contrib/lisp/org-toc.el
@@ -294,8 +294,8 @@ If CYCLE is non-nil, cycle the targeted subtree in the Org window."
 	   (org-show-entry))
 	 (org-show-context)))
 (if org-toc-recenter-mode
-	(if (>= org-toc-recenter 1000) (recenter)
-	  (recenter org-toc-recenter)))
+	(if (>= org-toc-recenter 1000) (org-recenter)
+	  (org-recenter org-toc-recenter)))
 (cond ((null jump)
 	   (switch-to-buffer-other-window toc-buf))
 	  ((eq jump 'delete)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
inde

Re: [O] still seeing semi-regular lockups

[Daimrod]

Nicolas Goaziou  writes:

> Hello,
>
> Daimrod  writes:
>
>> Okay, so I've found a more or less reliable way to reproduce this bug (on my
>> machine at least).
>>
>> 1. $ emacs -Q -l debug.el test.org
>> 2. Expand headline ()
>> 3. go below the first headline (C-n)
>> 4. press `i' a couple of seconds ~10 chars
>> 5. delete the line (C-a C-k)
>> 6. goto 4 until if locks up
>>
>> As I said, it's not completely reliable but so far the lockup always
>> happens. Sometimes it happens after the third iteration, sometimes after
>> the tenth iteration, but it always happen.
>>
>> I've attached `debug.el' and `test.org'.
>>
>
> [...]
>
>> Do you confirm the lockup with this setting?
>
> Yes, I do. I will investigate on this soon. Thank you for providing this
> recipe.

Cool!

Also, I should have mentioned that I didn't trace the function
`org-element--cache-key-less-p' because when I do so, Emacs stays locked
even when I send it the signal SIGUSR2. However, this function appears
in the backtrace produced by `xbacktrace' in a gdb session if I call it
during a lockup.

My guess is that the lockup happens in `org-element--cache-key-less-p',
called by `org-element--cache-process-request'.

Best,

-- 
Daimrod/Greg

Re: [O] Tangling with variables in R

[Andreas Leha]

Hi Rainer,

Rainer M Krug  writes:

> Hi
>
> I just realized (again) that tangling with variables in R contains many
> particularities.
>
> 1) it only works with non-tables, i.e. single values.
>
> When defining the following variables:
>
> #+NAME: YEARS
> |   | year  |
> |---+---|
> | 1 | 1990  |
> | 2 | 2000  |
> #+PROPERTY: var+ YEARS=YEARS
> #+PROPERTY: var+ PRESENT=2008
>
>
> I get the following code in the tangled .R file:
>
> ,
> | YEARS <- 
> read.table("/var/folders/50/wcr5bjwn75q595n6x82gxj28gn/T/babel-97151aBD/R-import-97151vpn",
> |   header=TRUE,
> |   row.names=1,
> |   sep="\t",
> |   as.is=TRUE)
> | PRESENT <- 2008
> `
>
> Variable transfer from tables does not work, as it is based on a
> temporary file, which is not easy to distribute together with the
> tangled.R file and requires manual work as the path will be different.
>
> I consider this as a bug which should be fixed.

Me too, see http://thread.gmane.org/gmane.emacs.orgmode/51067


>
> 2) With regards to variables which are defined non-file wide, (i.e. in
> properties in a subtree and variables defined per code block and
> function call), these are set when they occur in the tangled code, but
> they are not unset *for the next code block* or *for R code in the next
> subtree* (I hope you know what I mean). They are therefore similar to
> the use of a session header argument instead of non-session evaluation
> of the code.
>
> This is a (conceptually) a more complex issue, and requires some initial
> thought on how this should be dealt with and how the tangled code should
> relate to the executed code.
>
> - Should the tangled .R file result in the same output as the execution in
> the org file, i.e. an accompanying .R file to a exported pdf, so that
> the .R file can be used to reproduce the graphs and analysis in the .pdf
> exported from the .org? or
>
> - Is tangling a completely thing to execution, and the resulting R code
> in the .R file is not expected to reproduce the results in the org file?
>
> - Finally, does tangling with variables makes sense?
>
> My opinions are 
>
> a) *All* variables should be transferred to the .R file. This can be
> already disabled via the :no-expand header argument. Unfortunately, this
> is combined with noweb expansion, and it might be useful to split these
> two, i.e. to be able to only disable variable expansion but to keep
> noweb (I don't use noweb so far, so it is not a problem to me as it is
> now).
>
> b) The variable assignments should be per code block / function call. So
> a tangled block should look as follow:
>
> #+NAME: YEARS
> |   | year  |
> |---+---|
> | 1 | 1990  |
> | 2 | 2000  |
> #+PROPERTY: var+ YEARS=YEARS
> #+PROPERTY: var+ PRESENT=2008
>
> #+begin_src R
> x <- 4
> cat(x^2)
> #+end_src
>
> should result in something like the following:
>
> ,
> | ## # Set the variables
> | YEARS <- TRANSFER_TABLE()
> | PRESENT <- TRANSFER_VALUE()
> | ## Here begins the real code
> | x <- 4
> | cat(x^2)
> | ## # Unset all variables previously set
> `
>
> but I prefer the following approach, as the result would be very
> similar, only that the variables are still present afterwards which
> would make debugging easier:
>
> ,
> | ## # Unset all variables previously set
> | ## # Set the variables
> | YEARS <- TRANSFER_TABLE()
> | PRESENT <- TRANSFER_VALUE()
> | ## Here begins the real code
> | x <- 4
> | cat(x^2)
> `
>
> This is effectively already implemented by using R environments. See [1]
> and particularly [2] and [3] for how it is implemented. This does not
> yet address the concern about the transfer of tables, but I will look at
> this.

These are good thoughts!

For the general question on whether tangling should directly reflect
weaving, there was a long (and fruitless) discussion or R-devel lately.
See http://thread.gmane.org/gmane.comp.lang.r.devel/36031 and maybe
http://thread.gmane.org/gmane.comp.lang.r.devel/36031/focus=36075 where
Yihui states that it is very hard to tangle code that produces the
same result as weaving.  This might actually be easier in org than in
Sweave/knitr, but still the org setup will have a big impact, that would
be hard to replicate in the tangled R code.

Setting aside the general question:
In my opinion, it should definitely be possible to tangle with
variables.  I think the approach of the environments to address (2) is a
good one.



>
> Apologies for a long post, but I would like to know which direction of
> the tangling / variable transfer from org to R should take - I don't
> want to spend a lot of time solving a problem which does not really
> exist.
>
> So - any comments? Suggestions?
>

See above.  And thanks for your work on ob-R!  Keep it up!

> Thanks,
>
> Rainer
>
> Footnotes: 
> [1]  https://github.com/rkrug/orgmode-dev
>
> [2]  https://github.com/rkrug/orgmode-dev

Re: [O] still seeing semi-regular lockups

[Nicolas Goaziou]

Hello,

Daimrod  writes:

> Okay, so I've found a more or less reliable way to reproduce this bug (on my
> machine at least).
>
> 1. $ emacs -Q -l debug.el test.org
> 2. Expand headline ()
> 3. go below the first headline (C-n)
> 4. press `i' a couple of seconds ~10 chars
> 5. delete the line (C-a C-k)
> 6. goto 4 until if locks up
>
> As I said, it's not completely reliable but so far the lockup always
> happens. Sometimes it happens after the third iteration, sometimes after
> the tenth iteration, but it always happen.
>
> I've attached `debug.el' and `test.org'.
>

[...]

> Do you confirm the lockup with this setting?

Yes, I do. I will investigate on this soon. Thank you for providing this
recipe.


Regards,

-- 
Nicolas Goaziou

Re: [O] bug in exporter (org-babel-exp-process-buffer)

[Nicolas Goaziou]

"Charles C. Berry"  writes:

> When run with master, after the prompt for evaluating the src block,
> an error is thrown. *Messages* shows
>
> ,
> | Evaluate this emacs-lisp code block on your system? (y or n)  y
> | executing Emacs-Lisp code block...
> | Code block evaluation complete.
> | cond: Wrong type argument: integer-or-marker-p, nil
> `
>
> evidently the result of (goto-char ,head) with nil as the value of
> head when trying to evaluate src_R{...}.
>
> Adding the lines results in correct export with no prompt at the
> (later) inline src block.

Applied to master. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-mode and/versus make/makefiles

[Grant Rettke]

On Wed, Jun 11, 2014 at 2:24 PM, Greg Minshall  wrote:
> i'm wondering if anyone else, having wrestled with these issues,

Yes.

> has any recipes for some approximation of happiness.  or, some totally 
> different
> approach i'm too set in my ways to see.

For me it has been the same approach defined in the macro writers handbook:
1. Do it manually until I know how it works.
2. Make sure that it works well in a couple other places.
3. Automate it

Sometimes it is just easier to explain to a human what is happening
when you use a makefile because if you are using noweb references then
you've already got a lot on your cognitive plate. My build is kind of
basic, but it depends upon your perspective.

The Makefile just makes it crystal clear, it prepares the document for
tangling or does the weaving, nothing more, and for now that works
fine.

Use the best tool for the job, by your definition.

[O] org-mode and/versus make/makefiles

[Greg Minshall]

hi, all.

if this is out of scope, or likely to be too much of a rat hole, please
let me know (and otherwise ignore).

occasionally, i work on something complicated enough that i feel the
need of using make to manage dependencies, allow for cleaning up working
directories (via "make clean" functionality), and generally organize the
structure of my project (by forcing me to specify the various input
files, output files ("targets"), and processes).

but, when this happens, i have a hard time splitting the
responsibilities for various parts of my build process between the
makefile and the .org file.  for example, i very much like writing small
scripts in my .org file, rather than as stand-alone files.  but, then if
i decide to migrate the output of that script to the makefile, i have to
split out the script to a separate file (and thus lose, or obfuscate,
whatever version control history i have of that script).

as another example, occasionally i feel i should have the .org file call
out to the makefile, either to build something, or to retrieve some
shared parameter (second-normal-form obsessiveness).  or, have the
makefile call the .org file, via some mechanism i've not explored, for
similar reasons.  then, if i have one calling the other calling the
first...

i'm wondering if anyone else, having wrestled with these issues, has any
recipes for some approximation of happiness.  or, some totally different
approach i'm too set in my ways to see.

cheers, Greg Minshall

[O] bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Nicolas Richard]

Bastien  writes:

> Nicolas Richard  writes:
>
>> Bastien  writes:
>>> PS: The change about throwing an error when recentering a window
>>> that does not display the current buffer breaks ~37 tests in Org
>>> master branch, even with this fix.  I need to digg this further.
>>
>> For me, fixing also org-fix-ellipsis-at-bol made all tests run as
>> expected.
>
> What do you mean by "fixing"?  Removing it entirely?

Yes, I admit, I did : (defsubst org-fix-ellipsis-at-bol () nil)
But I must have done something wrong or misread the results because now
I see some other failures. Moreover, the backtrace that I get from "make
test" seems incomplete and it's not obvious to me where the recenter
call is made.

OTOH I hope that wrapping every call to recenter in a
(when (eq (current-buffer) (window-buffer))
   (recenter ...))
would fix the tests, no ?

-- 
Nico.

[O] bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Eli Zaretskii]

> From: Stefan Monnier 
> Cc: Bastien , theonewiththeevill...@yahoo.fr,
>  17...@debbugs.gnu.org, dogriffi...@gmail.com
> Date: Wed, 11 Jun 2014 14:15:08 -0400
> 
> > Say thanks to Stefan for flagging all those bugs ;-)
> 
> Now that I think about it, I should make `car' signal an error every
> 100th call, as well.  Would flag many bugs (with some false positives,
> of course, but what's a few false positives among friends?)!

Not just 'car', 'cdr' as well, I'd say.

[O] bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Stefan Monnier]

> Say thanks to Stefan for flagging all those bugs ;-)

Now that I think about it, I should make `car' signal an error every
100th call, as well.  Would flag many bugs (with some false positives,
of course, but what's a few false positives among friends?)!


Stefan

[O] bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Eli Zaretskii]

> From: Bastien 
> Date: Wed, 11 Jun 2014 17:50:02 +0200
> Cc: 17...@debbugs.gnu.org, David Griffiths 
> 
> PS: The change about throwing an error when recentering a window
> that does not display the current buffer breaks ~37 tests in Org
> master branch, even with this fix.  I need to digg this further.

Say thanks to Stefan for flagging all those bugs ;-)

[O] bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Bastien]

Nicolas Richard  writes:

> Bastien  writes:
>> PS: The change about throwing an error when recentering a window
>> that does not display the current buffer breaks ~37 tests in Org
>> master branch, even with this fix.  I need to digg this further.
>
> For me, fixing also org-fix-ellipsis-at-bol made all tests run as
> expected.

What do you mean by "fixing"?  Removing it entirely?

-- 
 Bastien

[O] bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Nicolas Richard]

Bastien  writes:
> PS: The change about throwing an error when recentering a window
> that does not display the current buffer breaks ~37 tests in Org
> master branch, even with this fix.  I need to digg this further.

For me, fixing also org-fix-ellipsis-at-bol made all tests run as
expected.

-- 
Nico.

[O] bug#17746: 24.4.50; "byte-code: `recenter'ing a window that does not display current-buffer." when composing a message

[Bastien]

Nicolas Richard  writes:

> David Griffiths  writes:
>> Debugger entered--Lisp error: (error "`recenter'ing a window that does
>> not display current-buffer.")
>> recenter((4))
>> org-overview()
>
> So that's a duplicate of #17724. It is fixed in org-mode (upstream) master
> branch. The easy fix is to use emacs-24 branch :)
>
> (otherwise just remove that call to recenter in org-overview).

PS: The change about throwing an error when recentering a window
that does not display the current buffer breaks ~37 tests in Org
master branch, even with this fix.  I need to digg this further.

-- 
 Bastien

Re: [O] [RFC] org-noweb: org-tangle + org-weave for literate programming using Org

[Grant Rettke]

Understood.

The quick and dirty approach removes the ability for headings to
inherit the noweb properties of, and override, the properties of its
parent header.

That feature enables the true literate programming to remove it would
be a great loss.
Grant Rettke | AAAS, ACM, ASA, FSF, IEEE, SIAM, Sigma Xi
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 Wed, Jun 11, 2014 at 3:18 AM, Nicolas Girard
 wrote:
> 2014-06-10 19:54 GMT+02:00 Grant Rettke :
>> On Tue, Jun 10, 2014 at 9:46 AM, Nicolas Girard
>>  wrote:
>>>
>>> - About =org-babel-use-quick-and-dirty-noweb-expansion=:
>>>   should it be set to 't' by default ? I'd be tempted to say yes,
>>>   given the dramatic performance gain
>> Use Emacs to run Emacs Lisp and set
>> org-babel-use-quick-and-dirty-noweb-expansion to nil.
>
> Hi Grant,
>
> thanks for your reply. There might be a slight misunderstanding though.
> My question was: should org-tangle and org-weave enable
> "org-babel-use-quick-and-dirty-noweb-expansion" before doing their
> jobs ? For now I let the default value to be =nil=, and I was
> wondering if it wouldn't be bette to do the opposite instead, that is,
> enable "quick-and-dirty-noweb-expansion" by default and provide a
> -noquick option.
> What do you think ?
>
> Cheers,
> Nicolas

Re: [O] ditaa problem with latest org mode

[Grant Rettke]

I'm on:

Emacs version: GNU Emacs 24.3.1 (x86_64-apple-darwin13.1.0, NS
apple-appkit-1265.19)
of 2014-04-24 on orion
Org version: 8.2.6
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
ditaa0_9.jar

And org-babel-tangle on this

#+begin_src ditaa :file ditaa-simple.png :tangle no :exports both
  +--+   +-+   +-+   +-+
  |{io}  |   |{d}  |   |{s}  |   |cBLU |
  | Foo  +---+ Bar +---+ Baz +---+ Moo |
  |  |   | |   | |   | |
  +--+   +-+   +--+--+   +-+
  |
 /-\  |  +--+
 | |  |  | c1AB |
 | Goo +--+---=--+ Shoo |
 \-/ |  |
 +--+
#+end_src

Produces a png.
Grant Rettke | AAAS, ACM, ASA, FSF, IEEE, SIAM, Sigma Xi
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, Jun 10, 2014 at 9:29 PM, Adrian Burd  wrote:
> I am wondering if anyone else running Mavericks (OSX 10.9.2) on a Mac is
> also having problems with ditaa? I'm running Emacs 24.3 and org-mode 8.2.6
>
> Whenever I try to process some ditaa source code (either via an org file or
> even from the command line) using the version if ditaa that comes with org,
> I get the following unpleasant error
>
> ditaa version 0.9, Copyright (C) 2004--2009  Efstathios (Stathis) Sideris
>
> Exception in thread "main" java.lang.NoSuchMethodError:
> org.stathissideris.ascii2image.core.ConversionOptions.(Lorg/apache/commons/cli/CommandLine;)V
> at org.stathissideris.ascii2image.core.CommandLineConverter.main(Unknown
> Source)
>
> even when running with the simplest of ditaa files.
>
> I get the same error if I use Apples Java (java 6) or Oracle's Java (java
> 7u60).
>
> PlantUML code runs like a charm, so it's something in the way Java is
> interacting with ditaa.
>
> It does work on a similar Mac (in the office) running OSX 10.7 with org mode
> 8.2.1, so I'm suspecting that there's something messed up with Mavericks.
>
> Is anyone else seeing this?
>
> Thanks,
>
> Adrian
>
>
>

Re: [O] Include TODO for once-off events?

[Eric Abrahamsen]

SabreWolfy  writes:

> I use the following to include once-off events in my Agenda:
>
> * Once-Off Task
> <2014-06-11 Wed 09:00>
>
>
> What is the difference (benefit) to rather doing this:
>
> * TODO Once-Off Task
> <2014-06-11 Wed 09:00>
>
> The second method gives me a red "TODO" in the Agenda and allows me to mark
> the task as "DONE". Is that the primary reason for using "TODO"? If the
> state of a task is not important, there is no need to include "TODO"?

Yup, if you don't care about keeping track of the state of the task,
there's not much point in using the todo keyword. But generally I think
people use plain headlines + timestamps (no keyword) to keep track of
_events_, and headlines plus a keyword to keep track of _tasks_. If it's
a task that needs doing until it's done, then use a keyword, if only for
the satisfaction of marking it finished.

More to the point, the Agenda will only show you not-done todos --
picking and choosing what you want displayed in your agenda is one of
the main reasons for using todo keywords. If it's just something like a
meteor shower that will come and go, there's nothing for you to do, and
hence no need for a todo keyword.

E

[O] Include TODO for once-off events?

[SabreWolfy]

I use the following to include once-off events in my Agenda:

--8<---cut here---start->8---
* Once-Off Task
<2014-06-11 Wed 09:00>

--8<---cut here---end--->8---

What is the difference (benefit) to rather doing this:

--8<---cut here---start->8---
* TODO Once-Off Task
<2014-06-11 Wed 09:00>

--8<---cut here---end--->8---

The second method gives me a red "TODO" in the Agenda and allows me to mark
the task as "DONE". Is that the primary reason for using "TODO"? If the
state of a task is not important, there is no need to include "TODO"?

Re: [O] babel python example not reproducible

[Doyley, Marvin]

Works for me, see example below
#+BEGIN_SRC python :results output :session foo

x=100
print "hello"
2
print "bye"
#+END_SRC

#+RESULTS:
: 
: >>> hello
: 2
: bye

#+BEGIN_SRC python :results output :session foo

print "hello good bye"
print "Printing value from previous session", x
#+END_SRC

#+RESULTS:
: 
: hello good bye
: Printing value from previous session 100

The only difference is that I like to give my session a name and for
what it is worth I am using ipython (don't think this will make a difference). 
You can do this including the
following statement in your .emacs file

(setq python-shell-interpreter "ipython")
(setq python-shell-interpreter-args "--pylab")

Hope this help.
Cheers,
M

Re: [O] Orgmode on Android.

[Johann Spies]

Hallo John,

On 10 June 2014 23:27, John Hendy  wrote:

> More information would be helpful. There is a setup procedure from the
> Emacs/Org side, and also from the Mobile-Org side. What, for example,
> did you do for the steps described here?

- http://orgmode.org/manual/MobileOrg.html
>

I will document my steps tonight and send it.

>
> And did you push from Emacs?
>

Yes.


>
> There's too many variables here, so more steps and descriptions are
> probably going to be necessary. I wrote an ad-hoc "howto" in another
> post on the Org mailing list a couple months ago:
> - http://article.gmane.org/gmane.emacs.orgmode/82891
>
> That might help walk through the steps to see if something might have gone
> awry?
>

I suspect there is nothing wrong on my emacs-side because the MobileOrg on
my Iphone is working.  I recently bought an Android tablet and just wanted
it there too.

I have read last night (GMT+2) about a bug as far as something changed
recently in the Dropbox API and I suspected that the problem might be
related to it (https://github.com/matburt/mobileorg-android/wiki/FAQ):

"Because mobileorg-android still uses the deprecated v0 of the Dropbox API,
you will need to file a Dropbox API support request from the developer site
 and ask them to specifically enable
your app keys to work with API v0.

NOTE: I received this from Dropbox 3/27/14 in response to a request to
enable my keys for API v0:

Thanks for writing in. The old v0 version of the API is no longer
available, so unfortunately I can't make it available for your app. There's
a migration guide here though:

https://www.dropbox.com/developers/reference/migration";

I am not a developer (as far as orgmode is concerned) and i did not have
time so far to look at the "migration reference" referred to in the above
quote.


Regards

Johann

Regards
Johann

Re: [O] still seeing semi-regular lockups

[Daimrod]

Daimrod  writes:

> Nicolas Goaziou  writes:
>
>> Hello,
>>
>> Daimrod  writes:
>>
>>> I've attached part of the traces (the whole traces are way too big) and
>>> the backtraces.
>>
>> Thanks for looking into this. However, you are running a compiled Org,
>> which renders backtraces less useful.
>
> Ok, I was wondering why the backtraces was so ugly, I didn't think about
> byte-compilation... Thanks for the tip.
>
>> Also, you may want to disable cache refresh on idle time with, e.g.,
>>
>>   (setq org-element-cache-sync-idle-time 3600)
>>
>> It could make the bug easier to reproduce.
>
> Thanks, I'll try again this w.e.

Okay, so I've found a more or less reliable way to reproduce this bug (on my
machine at least).

1. $ emacs -Q -l debug.el test.org
2. Expand headline ()
3. go below the first headline (C-n)
4. press `i' a couple of seconds ~10 chars
5. delete the line (C-a C-k)
6. goto 4 until if locks up

As I said, it's not completely reliable but so far the lockup always
happens. Sometimes it happens after the third iteration, sometimes after
the tenth iteration, but it always happen.

I've attached `debug.el' and `test.org'.

`debug.el' setup the "environment" to reproduce the bug, you may need to
change the path to your orgmode source base and you'll need
`adaptive-wrap-prefix-mode' (available on ELPA).

I've been able to reproduce the bug without `adaptive-wrap-prefix-mode'
though other people have reported the same symptoms without using it.


`test.org' is a simple org file with two headlines. It seems that two
headlines are required to trigger the cache mechanism (with
`org-element-cache--sync').


Do you confirm the lockup with this setting?

Best,


* i

* i
i


debug.el
Description: application/emacs-lisp


-- 
Daimrod/Greg

Re: [O] Repeat work / week days

[SabreWolfy]

Nick Dokos  gmail.com> writes:

> `C-c C-x c' (`org-clone-subtree-with-time-shift')

Thanks. This looks like the best solution.

Re: [O] [RFC] org-noweb: org-tangle + org-weave for literate programming using Org

[Nicolas Girard]

2014-06-10 19:54 GMT+02:00 Grant Rettke :
> On Tue, Jun 10, 2014 at 9:46 AM, Nicolas Girard
>  wrote:
>>
>> - About =org-babel-use-quick-and-dirty-noweb-expansion=:
>>   should it be set to 't' by default ? I'd be tempted to say yes,
>>   given the dramatic performance gain
> Use Emacs to run Emacs Lisp and set
> org-babel-use-quick-and-dirty-noweb-expansion to nil.

Hi Grant,

thanks for your reply. There might be a slight misunderstanding though.
My question was: should org-tangle and org-weave enable
"org-babel-use-quick-and-dirty-noweb-expansion" before doing their
jobs ? For now I let the default value to be =nil=, and I was
wondering if it wouldn't be bette to do the opposite instead, that is,
enable "quick-and-dirty-noweb-expansion" by default and provide a
-noquick option.
What do you think ?

Cheers,
Nicolas