Re: [O] org-float with hours

2012-01-14 Thread Michael Brand
Hi sergio

On Sat, Jan 14, 2012 at 04:19, sergio mail...@sergio.spb.ru wrote:
 Is it possible to specify every second Friday of each month at 15:43 date?

Yes:

#+begin_src org
  , * 15:43 appointment
  ,   %%(org-float t 5 2)
#+end_src

The doc is missing that so I attached a patch.

There are other variants, some work, some don't, see
http://thread.gmane.org/gmane.emacs.orgmode/40584

Michael
From 95a93ac333b1a2a4cfa4e612a22e3b400398cc83 Mon Sep 17 00:00:00 2001
From: Michael Brand michael.ch.br...@gmail.com
Date: Sat, 14 Jan 2012 09:03:01 +0100
Subject: [PATCH] doc timestamp for diary-style sexp entries

---
 doc/org.texi |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 063f339..6dad96a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -5414,10 +5414,11 @@ @section Timestamps, deadlines, and scheduling
 can resort to special versions of these functions like @code{org-date} or
 @code{org-anniversary}.  These work just like the corresponding @code{diary-}
 functions, but with stable ISO order of arguments (year, month, day) wherever
-applicable, independent of the value of @code{calendar-date-style}.}.  For 
example
+applicable, independent of the value of @code{calendar-date-style}.}.  For
+example with optional time
 
 @example
-* The nerd meeting on every 2nd Thursday of the month
+* 22:00-23:00 The nerd meeting on every 2nd Thursday of the month
   %%(org-float t 4 2)
 @end example
 
-- 
1.7.4.2



Re: [O] org-float with hours

2012-01-14 Thread Sebastien Vauban
Hi Sergio,

 Is it possible to specify every second Friday of each month at 15:43 date?

Look for *Sexp* (or Sexpr, that is S-expressions) diary entries...

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Captions for src and example blocks

2012-01-14 Thread Nicolas Goaziou
Hello,

Christian Wittern cwitt...@gmail.com writes:

 There was a thread last April about a way to introduce captions and
 labels to src and example blocks (see
 http://lists.gnu.org/archive/html/emacs-orgmode/2011-04/msg00877.html).
  Now I would like to use captions in a similar way, but not just for
 LaTex, but also for the ODT export.  So a generic org-mode solution
 would be much more helpful. I wonder if somebody has any idea about
 how to achieve this.

The new export engine has support for captions and labels for almost any
element, through the use of affiliated keywords. Thus, the following
special block will have :caption and :name properties attached to
it:

--8---cut here---start-8---
#+caption: Here is /something/.
#+name: something
#+begin_something
A special something block.
#+end_something
--8---cut here---end---8---

Now, it doesn't mean that it will do anything during export, as
back-ends can choose to make use of those properties or ignore them.

With regards to the previous special block, the e-latex back-end
currently makes use of the :name property, but ignore the :caption one.
Though it's not hard to support this by modifying accordingly the
`org-e-latex-special-block' function.


Regards,

-- 
Nicolas Goaziou



Re: [O] [babel] Code for simple set-operations on two tables. Asking for some input.

2012-01-14 Thread Marc-Oliver Ihm

Hello,

please find attached an early draft of lob-table-operations.org.

It already has a reasonable documentation and working examples, so it should be 
easy to play with.

Some features are still missing (e.g. handling of column names and hlines)
and the coding needs some improvement (using the cl-package ?).
So it is probably not yet fit for official inclusion into the library of babel.

with kind regards,
Marc-Oliver Ihm

As a side note: I am very pleased and fascinated, how easily babel and org have 
made the task of keeping together
all aspects of development; from user documentation to implementation and (of 
course !) organisation.

This has made my coding even more fun !


* Table Operations
  :PROPERTIES:
  :ID:   1f8371eb-65e8-416d-ac22-b77431a7df3f
  :END:

** Documentation
   :PROPERTIES:
   :ID:   90a0c9e2-6092-492e-bd4b-c1c737087ac5
   :END:

*** Introduction

This section within the library of babel implements some simple operations, 
that act on
one or more tables to produce other tables.

The known operations are grouped in two categories:

- Filtering the rows of a single table
- Merging two tables into one
 
*** Example tables

To demonstrate we need three tables: upper, lower and keys.

Please note, that column-names are currently not supported !

#+name: upper
|  1 | A |
|  3 | C |
|  4 | D |
| 10 | J |
|  2 | B |

#+name: lower
| 2 | b |
| 4 | d |
| 5 | e |
| 6 | h |

#+name: keys
| 1 |
| 2 |
| 4 |

The tables upper and lower both have two columns and associate a numerical 
position
within the alphabet with the matching letter. E.g. the row | 1 | A | 
within table
upper, just states that the letter A comes at position 1 within the 
alphabet.

Nearly the same is true for table lower, only that it contains lower case 
letters only
and deliberatly not quite the same ones as table upper.

The table keys finally, contains keys (i.e. positions within the alphabet), 
that can be
used to select rows from either table upper or lower.

*** Filtering a table

 Keeping rows

 Let's say, we want to select the upper-case letters (i.e. rows from the 
table upper),
 that are given in table keys (i.e. the first, second and fourth letter).

 This can be described as filtering table upper and keeping only those 
rows, that are
 specified in table keys.

 As a babel-call, this reads:

#+call: table-operations-filter-keep(upper,keys)

#+results: table-operations-filter-keep(upper,keys)
| 1 | A |
| 4 | D |
| 2 | B |

 Which gives exactly those rows from table upper, that are specified in 
keys.

 Removing rows

 Now if on the contrary you want to filter table upper to remove any rows, 
which are given
 in table keys:

#+call: table-operations-filter-remove(upper,keys)

#+results: table-operations-filter-remove(upper,keys)
|  3 | C |
| 10 | J |

*** Combining tables

Now, if we have a look at tables upper and lower (and drop table keys for 
the moment),
it comes to combining tables.

(Here we only look at combining two tables for simplicity, however, all 
examples can
be easily scaled up to seven tables.)

 Merging rows

 We have two table, one with upper-case letter and one with lower-case. 
What now if you
 want to have only one table, which contains both, upper- and lower-case ?
 
 Probably you want to merge them:

#+call: table-operations-combine-merge(upper,lower)

#+results: table-operations-combine-merge(upper,lower)
|  1 | A |   |
|  2 | B | b |
|  3 | C |   |
|  4 | D | d |
|  5 |   | e |
|  6 |   | h |
| 10 | J |   |

 This results-table combines both upper- and lower-case letters and lists 
them by
 their position within the alphabet.

 Speaking more abstract, the result is a single table. Its rows are gained 
by
 combining rows from tables upper and lower with the same key.

 Intersecting rows

 If you only want the rows, that are complete (i.e. have both lower- and 
upper-case
 letters, you should compute the intersection:

#+call: table-operations-combine-intersect(upper,lower)

#+results: table-operations-combine-intersect(upper,lower)
| 2 | B | b |
| 4 | D | d |

 which has only those keys, that apear in both tables.

** Internals

   This section is not required reading for normal users of these table 
operations. Only
   if you are curious about its implementation or development, you might want 
to have a
   look.

*** Implementation
   
   Here is the actual lisp code, that implements the functionality of 
[[id:1f8371eb-65e8-416d-ac22-b77431a7df3f][Table Operations]].

 table-operations-filter
* Directly callable blocks

#+name: table-operations-filter-keep
#+begin_src emacs-lisp :noweb yes :var table=() :var filter=() 
lob-table-operations-filter-defun
(lob-table-operations-filter 'keep table filter)
#+end_src

#+name: table-operations-filter-remove
#+begin_src emacs-lisp :noweb yes :var 

Re: [O] org-float with hours

2012-01-14 Thread sergio
On 01/14/2012 12:05 PM, Michael Brand wrote:

 #+begin_src org
   , * 15:43 appointment
   ,   %%(org-float t 5 2)
 #+end_src

Thank you!

-- 
sergio.



[O] Odd problem with time of 10:00

2012-01-14 Thread Borbus
Hi,

I have noticed a strange problem with org-agenda when a task contains a
timestamp of 10:00 in it, for example this entry is in one of my agenda
files:

** Test 2012-01-17 Mon 10:00

I now press C-c a a and select the day and press d (so I'm viewing the
day) and get this:

Day-agenda (W03):
Tuesday17 January 2012
   8:00.. 
  appt:   10:00.. Test
  10:00.. 
  12:00.. 
  14:00.. 
  16:00.. 
  18:00.. 
  20:00.. 

Notice that it places the 10:00 appointment in the 9:00 place.  Now, if
I change the time to 10:01 (or any number of minutes past) I get this:

Day-agenda (W03):
Tuesday17 January 2012
   8:00.. 
  10:00.. 
  appt:   10:01.. Test
  12:00.. 
  14:00.. 
  16:00.. 
  18:00.. 
  20:00.. 

So it is now occupying the 11:00 place and there is no 9:00 place!

I have done some tests and it seems to only occur with the 10th hour.
All appointments seem to still show so it's not a major bug, just an
aesthetic one.  Any ideas?

-- 
Borbus.



Re: [O] Odd problem with time of 10:00

2012-01-14 Thread Detlef Steuer
Hi!

 Hi,
 
 I have noticed a strange problem with org-agenda when a task contains a
 timestamp of 10:00 in it, for example this entry is in one of my agenda
 files:
 
 ** Test 2012-01-17 Mon 10:00
 
 I now press C-c a a and select the day and press d (so I'm viewing the
 day) and get this:
 
 Day-agenda (W03):
 Tuesday17 January 2012
8:00.. 
   appt:   10:00.. Test
   10:00.. 
   12:00.. 
   14:00.. 
   16:00.. 
   18:00.. 
   20:00.. 


If  you take a close look, you'll see you only have a grid with 2h differences 
defined.  There is no 9:00, nor 11:00 etc ..

Hope that helps
Detlef


 
 Notice that it places the 10:00 appointment in the 9:00 place.  Now, if
 I change the time to 10:01 (or any number of minutes past) I get this:
 
 Day-agenda (W03):
 Tuesday17 January 2012
8:00.. 
   10:00.. 
   appt:   10:01.. Test
   12:00.. 
   14:00.. 
   16:00.. 
   18:00.. 
   20:00.. 
 
 So it is now occupying the 11:00 place and there is no 9:00 place!
 
 I have done some tests and it seems to only occur with the 10th hour.
 All appointments seem to still show so it's not a major bug, just an
 aesthetic one.  Any ideas?
 
 -- 
 Borbus.
 
 





Re: [O] Odd problem with time of 10:00

2012-01-14 Thread Sebastien Vauban
Hi Detlef,

Detlef Steuer wrote:
 I have noticed a strange problem with org-agenda when a task contains a
 timestamp of 10:00 in it, for example this entry is in one of my agenda
 files:
 
 ** Test 2012-01-17 Mon 10:00
 
 I now press C-c a a and select the day and press d (so I'm viewing the
 day) and get this:
 
 Day-agenda (W03):
 Tuesday17 January 2012
8:00.. 
   appt:   10:00.. Test
   10:00.. 
   12:00.. 
   14:00.. 
   16:00.. 
   18:00.. 
   20:00.. 

 I have done some tests and it seems to only occur with the 10th hour.
 All appointments seem to still show so it's not a major bug, just an
 aesthetic one.  Any ideas?

 If you take a close look, you'll see you only have a grid with 2h
 differences defined. There is no 9:00, nor 11:00 etc ..

True. And if you set remove-match, you won't have duplicate 10:00 entries.

#+begin_src emacs-lisp
  (setq org-agenda-time-grid '((daily today remove-match)
   
   (0800 1000 1200 1400 1600 1800 2000)))
#+end_src

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Odd problem with time of 10:00

2012-01-14 Thread Borbus
On 14/01/12 10:49, Sebastien Vauban wrote:
 Detlef Steuer wrote:
 If you take a close look, you'll see you only have a grid with 2h
 differences defined. There is no 9:00, nor 11:00 etc ..
 
 True. And if you set remove-match, you won't have duplicate 10:00 entries.

Well that was embarrassingly simple!  I didn't notice the odd numbers
were missing because I have appointments at odd hours in my actual
agenda.  I think I will turn on remove-match since it looks a bit weird
having e.g. 11:00 appear and not be duped while 10:00 is.

Thanks!

-- 
Borbus.



[O] [BUG] org-clock-sum cannot handle headings with more than 29 stars (was: Re: How to debug org-clock-display: Args out of range: [48230 48230) 48230 38618 38618 0 0 0 0 0 ...], 61

2012-01-14 Thread Gregor Zattler
Hi Nick, org developers,

while preparing a minimal example of my problem I finally
realised that 61 was the deepest level of indentation of some
inline tasks in my org file.  When I wrote them I only remembered
inline tasks as with more than x stars and so I provided more
than enough :-)

But this also applies to normal headings.  My Minimal org file to
demonstrate the bug is now:


* dog
** dog
*** dog
 dog
* dog
** dog
*** dog
 dog
* dog
** dog
*** dog
 dog
* dog
** dog
*** dog
 dog
* dog
** dog
*** dog
 dog
* dog
** dog
*** dog
 dog
* dog
** dog
*** dog
 dog
* dog
** ant


doing M-x org-clock-display (which in turn execs org-clock-sum)
will fail.  It will not fail, with the last line removed.

I searched a bit in the sources (max.*level) but did not find
documentation regarding the maximum number of stars in org
files.  Perhaps it has to be documented or lmax raised in the sources.

Thanks for your help though, I first changed lmax as you proposed
and it fixed the problem.

Ciao; gregor

* Nick Dokos nicholas.do...@hp.com [12. Jan. 2012]:
 Nick Dokos nicholas.do...@hp.com wrote:
 Gregor Zattler telegr...@gmx.net wrote:
 Debugger entered--Lisp error: (args-out-of-range [49569 49569 49569 39957 3=
 9957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] 61)
   aref([49569 49569 49569 39957 39957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0=
  0 0 0 0 0 0] 61)
 
 This tries to get the 61st element of a vector that has at most 30 or so
 elements, hence the complaint. But of course, that's hardly
 enlightening.  However, the backtrace shows that this code is inside the
 function org-clock-sum (in org-clock.el).  And if you look at that
 function, you see (where I have elided large swathes of code):
 
   (let* (...
   (lmax 30)
   (ltimes (make-vector lmax 0))
   ...
 
 So ltimes is a vector with *exactly* 30 elements. I would change that 30
 to 100 or so (something greater than 61 in any case) and retest. If that
 fixes it, then we know the culprit and then we can dedice which is the
 unreasonable one: the code or your subtree :-)
 Or maybe that 61 is way off base. After all, there are only 5 non-trivial
 entries in the vector.
 
 The code that sets the level seems suspect to me:
 
 (let* ((headline-forced
 (get-text-property (point)
  :org-clock-force-headline-inclusion))
  (headline-included
   (or (null headline-filter)
   (save-excursion
 (save-match-data (funcall headline-filter))
   (setq level (- (match-end 1) (match-beginning 1)))
 
 What do match-beginning/match-end return if headline-filter is nil?
 The save-match-data is not done, so we get the results of whatever
 random  search was done last before this code executed.




Re: [O] Captions for src and example blocks

2012-01-14 Thread Jambunathan K

Hello Chris

 Dear Orgmoders,

 There was a thread last April about a way to introduce captions and
 labels to src and example blocks (see
 http://lists.gnu.org/archive/html/emacs-orgmode/2011-04/msg00877.html).
  Now I would like to use captions in a similar way, but not just for
 LaTex, but also for the ODT export.  So a generic org-mode solution
 would be much more helpful. I wonder if somebody has any idea about
 how to achieve this.

As Nicolas notes, all essential infrastructure is in place. Only thing
that needs to happen is to switch over the existing ODT backend to the
new export engine.

If you have any specific opinions on how the example blocks need to be
formatted by default - for eg, put the src blocks in a text frame, in
this font and in that size, label and caption the listings this and that
way, create an index entry for src listings, - and are willing to show
and tell with a sample ODT document I am all ears.

Jambunathan K.
-- 



Re: [O] automatic tangle

2012-01-14 Thread Eric Schulte
András Major andras.g.ma...@gmail.com writes:

 Hi Sebastien,

 I have the impression it's already there: if you edit your code directly in
 the Org buffer, without opening an indirect buffer, the only thing you have 
 to
 do is:

 That's precisely what I want to avoid.  I'd like to use the
 language-specific indentation and highlighting using the indirect
 buffer.  Basically, what I'm after is a quick keyboard command that
 tangles the entire file while I'm in the indirect buffer.


The following functions provide for (1) easily executing code in the
org-mode buffer related to the current edit buffer and (2) tangling the
org-mode buffer related to the current edit buffer.  Binding (2) to a
key in `org-src-mode' should provide the functionality you describe.

#+BEGIN_SRC emacs-lisp
  (defmacro org-src-in-org-buffer (rest body)
`(save-window-excursion
   (org-edit-src-exit 'save)
   ,@body
   (setq msg (current-message))
   (if (eq org-src-window-setup 'other-frame)
   (let ((org-src-window-setup 'current-window))
 (org-edit-src-code 'save))
 (org-edit-src-code 'save))
   (message (or msg 

  (defun org-src-tangle (arg)
(interactive P)
(org-src-in-org-buffer (org-babel-tangle arg)))
#+END_SRC

I think that the above should be folded into org-src.el, but I'm not
entirely sure how.  (1) could be used to perform a number of functions
in the org buffer from an edit buffer, although off the top of my head
I'm not sure if there exists a need for this aside from tangling.

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/



Re: [O] Syntax error warnings? (Especially important with :noweb-ref's)

2012-01-14 Thread Eric Schulte
Yu yu_...@gmx.at writes:

 Hello!

 I was wondering, if there is a way to get warnings for typos (e.g.
 when specifying invalid properties or header arguments). It can just
 easily happen that I mix up e.g. :exports and :export (though
 that's probably a very harmless example).


While there is currently no way to do this there are two related
functions which should help.

,[org-babel-view-src-block-info] bound to C-c C-v I
| org-babel-view-src-block-info is an interactive Lisp function in
| `ob.el'.
| 
| (org-babel-view-src-block-info)
| 
| Display information on the current source block.
| This includes header arguments, language and name, and is largely
| a window into the `org-babel-get-src-block-info' function.
`

and

,[org-babel-check-src-block] bound to C-c C-v c
| org-babel-check-src-block is an interactive Lisp function in `ob.el'.
| 
| (org-babel-check-src-block)
| 
| Check for misspelled header arguments in the current code block.
`

This problem is not trivial because new language are permitted to create
and use *any* header arguments they like, so there are no /wrong/ header
arguments, there are only /suspicious/ header arguments (like the
:exports option you suggest).  The above function reports any suspicious
header arguments.  Perhaps there would be a way to integrate the above
function with flyspell for automatic highlighting of suspicious header
arguments.  I'll put looking into such integration on my long-term Org
task queue.


 More important it gets though, when trying to use the literate
 programming facilities.

 Say I have a source code

 #+begin_src sh :noweb tangle :tangle foo.sh
   foo
 #+end_src
 #+begin_src sh :noweb-ref fo
   echo '... how are you?';
 #+end_src

 then tangling would run through without any indication of the typo in
 the name of the foo block. Such errors might be hard to debug,
 because there is no indication of the error, maybe nothing other than
 runtime errors.

 An error message for the /use/ of undefined references only wouldn't
 avoid such problems either, e.g. consider

 #+begin_src sh :noweb tangle :tangle foo.sh
   foo
 #+end_src
 #+begin_src sh :noweb-ref foo
   echo 'Hello World...';
 #+end_src
 #+begin_src sh :noweb-ref fo
   echo 'Hello World...';
 #+end_src

 where the only detectable error is, that fo was never used anywhere.

 A similiar question (though without the second part) was asked here:
 http://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg00273.html
 As far as I can tell, it stands unanswered.


Yes, although in many languages constructs like foo are valid code,
so it would be inappropriate for tangling to raise errors by default.
It is possible to turn on such errors on a language-by-language basis,
by customizing the following variable.

,[org-babel-noweb-error-langs]
| org-babel-noweb-error-langs is a variable defined in `ob.el'.
| Its value is nil
| 
| Documentation:
| Languages for which Babel will raise literate programming errors.
| List of languages for which errors should be raised when the
| source code block satisfying a noweb reference in this language
| can not be resolved.
`


 On a side note: What is the customary way to mention the
 noweb-relevant name of a source block in the html/pdf export? After
 all, if a code-block states
 : task1
 : task2
 the reader needs to know, which code blocks define these.


Currently there is no automated support for this, so you should simply
name code blocks manually, however this topic has been raised recently
in another thread and there does seem to be interest for automated
support.

Best,



 kind regards, Yu


-- 
Eric Schulte
http://cs.unm.edu/~eschulte/



Re: [O] [babel] org mode tables and tangling

2012-01-14 Thread Eric Schulte
Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Hi all,

 What is the suggested way to use org mode tables in connection with tangling?


Currently there is no support for including table values literally
inline in tangled R code.  While some languages (e.g., the lisps) do
include table values literally, R is not one of those.  You could
customize (read rewrite) the `org-babel-R-assign-elisp' function to use
literal R tables instead of importing values from an external file.

Alternately, if not too many values need to be included into the code,
you may want to simply assign individual cells of the table as scalars
in your R code.

Hope this helps, sorry no pre-built solution exists


 Example: If I tangle this org mode file

 /org-file=\
 | * org-tables and reproducibility  |
 |   #+name: params  |
 |   | number | param |  |
 |   |+---|  |
 |   |  0 | 1 |  |
 |   |  1 | 1 |  |
 |   |
 |   #+begin_src R :var params=params :tangle test.R |
 | apply(params, 1, print)   |
 |   #+end_src   |
 \/org-file/

 the tangled file looks like

 /test.R===\
 | params - read.table(/tmp/babel-19196cip/R-import-19196ILE, |
 |header=TRUE, row.names=NULL, sep=\t, as.is=TRUE) |
 | attach(params)|
 | apply(params, 1, print)   |
 \/test.R==/

 which depends on a temporary file.  I could distribute that along with the
 tangled file, of course.

 But I'd like a distributable, ideally self-contained version, that my
 co-workers can work with.

 Something like this, maybe:

 /sample.R===\
 | # generated with R dput()...|
 | babel_tmp_1238h098 - structure(list(means = 0:1, sds = c(1L, 1L)), |
 | .Names = c(means, sds), |
 | class = data.frame,   |
 | row.names = c(NA, -2L)) |
 | params - dget(textConnection(babel_tmp_1238h098, r))   |
 \/sample.R==/

 Is such a mode of tangling already available for R?

 Best,
 Andreas



-- 
Eric Schulte
http://cs.unm.edu/~eschulte/



Re: [O] [BUG] org-clock-sum cannot handle headings with more than 29 stars (was: Re: How to debug org-clock-display: Args out of range: [48230 48230) 48230 38618 38618 0 0 0 0 0 ...], 61

2012-01-14 Thread Nick Dokos
Gregor Zattler telegr...@gmx.net wrote:

 Hi Nick, org developers,
 
 while preparing a minimal example of my problem I finally
 realised that 61 was the deepest level of indentation of some
 inline tasks in my org file.  When I wrote them I only remembered
 inline tasks as with more than x stars and so I provided more
 than enough :-)
 
 But this also applies to normal headings.  My Minimal org file to
 demonstrate the bug is now:
 
 
 * dog
 ** dog
 *** dog
  dog
 * dog
 ** dog
 *** dog
  dog
 * dog
 ** dog
 *** dog
  dog
 * dog
 ** dog
 *** dog
  dog
 * dog
 ** dog
 *** dog
  dog
 * dog
 ** dog
 *** dog
  dog
 * dog
 ** dog
 *** dog
  dog
 * dog
 ** ant
 
 
 doing M-x org-clock-display (which in turn execs org-clock-sum)
 will fail.  It will not fail, with the last line removed.
 
 I searched a bit in the sources (max.*level) but did not find
 documentation regarding the maximum number of stars in org
 files.  Perhaps it has to be documented or lmax raised in the sources.
 
 Thanks for your help though, I first changed lmax as you proposed
 and it fixed the problem.
 
 Ciao; gregor
 
 * Nick Dokos nicholas.do...@hp.com [12. Jan. 2012]:
  Nick Dokos nicholas.do...@hp.com wrote:
  Gregor Zattler telegr...@gmx.net wrote:
  Debugger entered--Lisp error: (args-out-of-range [49569 49569 49569 39957 
  3=
  9957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] 61)
aref([49569 49569 49569 39957 39957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
  0=
   0 0 0 0 0 0] 61)
  
  This tries to get the 61st element of a vector that has at most 30 or so
  elements, hence the complaint. But of course, that's hardly
  enlightening.  However, the backtrace shows that this code is inside the
  function org-clock-sum (in org-clock.el).  And if you look at that
  function, you see (where I have elided large swathes of code):
  
(let* (...
  (lmax 30)
  (ltimes (make-vector lmax 0))
  ...
  
  So ltimes is a vector with *exactly* 30 elements. I would change that 30
  to 100 or so (something greater than 61 in any case) and retest. If that
  fixes it, then we know the culprit and then we can dedice which is the
  unreasonable one: the code or your subtree :-)
  Or maybe that 61 is way off base. After all, there are only 5 non-trivial
  entries in the vector.
  
  The code that sets the level seems suspect to me:
  
(let* ((headline-forced
(get-text-property (point)
   :org-clock-force-headline-inclusion))
   (headline-included
(or (null headline-filter)
(save-excursion
  (save-match-data (funcall headline-filter))
  (setq level (- (match-end 1) (match-beginning 1)))
  
  What do match-beginning/match-end return if headline-filter is nil?
  The save-match-data is not done, so we get the results of whatever
  random  search was done last before this code executed.
 
 

So I guess that despite my suspicions this code works (although I need
to understand how).  As for the failure, your example is of course
highly unlikely in the above form[fn:1], but much more likely in the
inline task case that bit you originally. But since expanding the vector
to 100 elements or so fixes the problem and seems to be both cheap and
expedient, I'd vote for that fix to go in and be done with it (perhaps
with a footnote in the clock section of the manual to identify the
limit).

Nick

Footnotes:

[fn:1] I doubt anybody uses  30-level deep trees, although I would not be
   surprised to hear otherwise :-)



Re: [O] Help with elisp function

2012-01-14 Thread Marcelo de Moraes Serpa
Thanks Olaf, I will check it out and let you know how it goes :)

On Fri, Jan 13, 2012 at 2:45 AM, Olaf Dietsche 
olaf+list.orgm...@olafdietsche.de wrote:

 Marcelo de Moraes Serpa celose...@gmail.com writes:

  So, I made a small elisp function that basically creates a reference
  file in my org dir and indexes it in an org file, so it can be
  searchable with the agenda without the overhead of adding the file to
  the agenda list:
 
  (defun create-reference-file (filename title tags) Creates a new
  reference and file it
(interactive (list
  (read-string Filename: ) (read-string Title: )
  (read-string Tags: ) ))
(set-buffer (get-buffer-create filename)) (beginning-of-buffer)
(insert (concat * tags  tags))
 ;;saves the buffer (when (file-writable-p filename)
(write-region (point-min) (point-max) (concat
  ~/org/data/dynamic_reference/ filename .org)))
(set-buffer (find-file-noselect ~/org/gtd/reference.org))
(end-of-buffer) ;;(create-wiki-page filename) (insert (concat ** 
title   tags :reference:file:\n)) (org-insert-time-stamp nil t
nil) (insert \n) (insert (concat
[[file://~/org/data/dynamic_reference/ filename
  .org]]))
(insert \n) (save-buffer) )
 
  I'm only beginning with elisp, so bear with me...
 
  Anyway, it works as expected, but I would like the tags prompt to be
  like the prompt org uses, with tags auto-completion and adding the : :
  automatically around the tags. Right now, I have to type the : around
  the words.

 C-h c C-c C-q runs the command org-set-tags-command.
 org-set-tags-command calls org-set-tags. Looking through org-set-tags in
 org.el, there's a part starting with a comment:

;; Get a new set of tags from the user
...
  (let ((org-add-colon-after-tag-completion t))
(org-trim
 (org-icompleting-read Tags: 
   'org-tags-completion-function
   nil nil current
 'org-tags-history))
...

 So, I guess org-icompleting-read is, what you are looking for.

 Regards, Olaf



Re: [O] :noweb header argument

2012-01-14 Thread Eric Schulte
 As I recall this was originally implemented and then later removed because
 it was causing more confusion and problems than it was worth. I hope it
 hasn't crossed the line of existence more than once. At some point it
 should be placed behind a user-customizable variable, preferably something
 like `org-babel-export-code-format' which defaults to something like
 %code but could be augmented to something like Block Name: *%name*\n
 %code. It is not immediately clear if such a variable should have
 different values for different export backends or (likely preferable)
 should expand into Org-mode text *before* export.

 I think you're right about getting this done early in the process. I've been
 thinking only about LaTeX export because that is my immediate goal--not a
 good design perspective.


I've just pushed up a minor code change which makes customization of the
format of exported code blocks possible.  I've added a new customization
variable named `org-babel-exp-code-template' which can be used to
specify the text which replaces code block bodies during export.  The
default value of this variable specifies the existing export behavior.
The attached Org-mode file demonstrates this variable in action.

#+Title: Custom code block export formats

- Example code block
  #+Name: foo
  #+BEGIN_SRC sh :bar baz
echo qux
  #+END_SRC

- Evaluate this block to export (shows the export of the name).
  #+Name: do-export-name
  #+BEGIN_SRC emacs-lisp :results silent
(let ((org-babel-exp-code-template
   \n=%name=:\n#+BEGIN_SRC %lang%flags\n%body\n#+END_SRC))
  (org-export-as-html nil))
  #+END_SRC

- Evaluate this block to export (shows the export of header arguments).
  #+Name: do-export-header-arguments
  #+BEGIN_SRC emacs-lisp :results silent
(let ((org-babel-exp-code-template
   Header arguments for =%name=.
| header  | value|
|-+--|
| bar | %bar |
| results | %results |\n#+BEGIN_SRC %lang%flags\n%body\n#+END_SRC))
  (org-export-as-html nil))
  #+END_SRC

I imagine that this variable would likely be customized on a
file-by-file basis using file local variables.


 Perhaps I could help by specifying what I'm trying to do? I'd like to write
 an article or book about particular statistical analyses. I want this also
 to be a piece of reproducible research so readers of the book can follow
 along and perhaps analyze data of their own. I'd like to write a code block
 once and then use it in the following ways: 1) evaluate and return the
 results of analyses; 2) export as a floating listing so I can refer to it in
 discussions of implementation; and 3) tangle to a source code file that can
 be used as the basis for a package that can be used outside of Org mode.


Sounds like a very cool project.  If this will be public I would love to
link to it from [1] when it is complete.


 1) is easy with #+call: With the :wrap header argument that we've
 partially implemented, I can mark the results off in whatever environment I
 like, which is a wonderful bit of flexibility. Different kinds of results
 can be presented distinctively.

 2) is partially there--the code itself is handled nicely by minted and
 I'm able to make it look as good as I want. What I'm lacking now is an easy
 way to identify the code block. Seb's suggestion that the header lines be
 included is one way, though Eric F.'s point about the special characters
 tripping up LaTeX is well taken. It might be some work to get an
 intermediate representation that can be exported to all the targets. My
 alternate idea, which is to wrap the code block in an environment to which I
 can attach a caption and a label, is the LaTeX approach and might not work
 as well for other export targets.

This new solution replaces the code block with Org-mode text before
export.  This should be the most flexible as arbitrary #+HTML and
#+LATEX lines can be used in Org-mode.

Best,

Footnotes: 
[1]  http://orgmode.org/worg/org-contrib/babel/uses.html

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/


Re: [O] [Orgmode] Automatic screenshot insertion

2012-01-14 Thread François Pinard
Skip Collins skip.coll...@gmail.com writes:

 2012/1/10 François Pinard pin...@iro.umontreal.ca:
 Some sad people think of me as a programmer.  While deep down, I am
 fundamentally an artist.  Programming is mere mean of expression :-).

 You and Jambunathan K. should form a club.

I do not know Jambunathan, but I'll pay attention! :-)

François

P.S. This Org mode mailing list is quite active.  I did not pay
attention in the last few days (being busy elsewhere) and messages
accumulated at a relatively fast pace!




Re: [O] Capitalisation and good taste ?

2012-01-14 Thread François Pinard
Sebastien Vauban writes:
 François Pinard wrote:
 Bastien writes:
 Eric Schulte writes:

 Could the highlighting be made consistent as well?  I would suggest that
 gray is uniformly kept for all one-line option/environment keywords.
 Currently, #+TITLE is gray, #+OPTIONS is red, so #+OPTION would be
 rendered the same as #+TITLE.  The gray would counter-balance the
 shouting of the capitals, making it more bearable.

 François, Are you talking of a dark theme or light theme?

I do not know, as I do not use themes.  The background is white, if this
is what you mean.

So, I'm merely speaking about Org mode defaults.  My suggestion is that
the default for #+ lines to be consistent (and if it cannot be for some
reason, that these reasons be stated somewhere in the manual).

 Did you take a look at Emacs color themes, and their customization for
 Org?

Following your suggestion, I just took a quick look.  This is far too
complex for my humble needs.  It seems that using themes is opening the
door for a lot of further customization, and I have too much of it
already.

François



P.S. For the record, I have been a long and deep user of Emacs for maybe
15 years (I have fuzzy memory of times), and with years passing by, have
grown a huge, insane Emacs customization (Gnus in particular).  So, I
decided to break out of the addiction (it has been real hard to do so,
then heal!), and switched to Vim, maybe 10 years ago.  I also have other
reasons (http://icule.blogspot.com/2003/12/thoughts-on-editors.html,
section 1).  Org mode was so appealing that I returned to Emacs
recently, but I promised myself that this time through, I will strongly
resist customization bloat.  As I have a lot already for Org mode, I
have to put breaks somewhere!  :-)



Re: [O] Capitalisation and good taste ?

2012-01-14 Thread François Pinard
Bastien b...@altern.org writes:

 Hi François,

 Could the highlighting be made consistent as well?

 As Sébastien suggested, please contribute to this page:
 http://orgmode.org/worg/color-themes-screenshot.html

Hello, Bastien.  I hope you'll forgive me if I decline this invitation.
My suggestion only pertains to Org mode's defaults.  Learning Emacs (or
Org) themes and further playing in this area would be a non-negligible
distraction for me.

François

P.S. I'm a happy Org mode user, but I do not aspire to become a
maintainer :-).



Re: [O] Capitalisation and good taste ?

2012-01-14 Thread Sebastien Vauban
Hi François,

François Pinard wrote:
 Sebastien Vauban writes:

 François, Are you talking of a dark theme or light theme?

 I do not know, as I do not use themes. The background is white, if this is
 what you mean.

Yep, that's what I meant.

 So, I'm merely speaking about Org mode defaults. My suggestion is that the
 default for #+ lines to be consistent (and if it cannot be for some reason,
 that these reasons be stated somewhere in the manual).

 Did you take a look at Emacs color themes, and their customization for Org?

 Following your suggestion, I just took a quick look. This is far too complex
 for my humble needs. It seems that using themes is opening the door for a
 lot of further customization, and I have too much of it already.

Not really a problem. This is quite short, the following being what I need to
enable my own color theme:

#+begin_src emacs-lisp
;; avoid Emacs hanging for a while changing default font
(modify-frame-parameters nil '((wait-for-wm . nil)))

;; the real color theme functions
(when (require 'color-theme-autoloads)

  ;; initialize the color theme package
  (if (fboundp 'color-theme-initialize)
  (color-theme-initialize))

  ;; color themes will be installed for all frames
  (setq color-theme-is-global t)

  ;; set my default color theme
  (when (try-require 'color-theme-leuven)
(color-theme-leuven)))
#+end_src

And it simply allows you to decide on every face you want to customize for
yourself.

 P.S. For the record, I have been a long and deep user of Emacs for maybe 15
 years (I have fuzzy memory of times), and with years passing by, have grown
 a huge, insane Emacs customization (Gnus in particular). So, I decided to
 break out of the addiction (it has been real hard to do so, then heal!), and
 switched to Vim, maybe 10 years ago. I also have other reasons
 (http://icule.blogspot.com/2003/12/thoughts-on-editors.html, section 1). Org
 mode was so appealing that I returned to Emacs recently, but I promised
 myself that this time through, I will strongly resist customization bloat.
 As I have a lot already for Org mode, I have to put breaks somewhere! :-)

I know the feeling. I'm using Emacs since 1999, and now have 10,998 lines in
my .emacs file. Though, every line being commented, and having a blank line
between each customization, that represent more or less 3,400 real lines.

That said, it's huge. But it now becomes much more feasible since I've LP'ed[1]
my .emacs file, thanks to Org Babel: now, I can put a lot of comments outside
of my .emacs file, and quickly access what I need to read or update with Org's
sparse trees (`C-c / /').

It is even easy to not tangle parts of Emacs custom, for debug needs, for
example. Or get a nicely printed HTML output. Or... just name it, I can go on
with advantages of using both Emacs and Org-mode, even heavily customized ;-)

Best regards,
  Seb

Footnotes:

[1] Literate Programming (à la NoWeb)

-- 
Sebastien Vauban




Re: [O] :noweb header argument

2012-01-14 Thread Thomas S. Dye
Eric Schulte eric.schu...@gmx.com writes:

 As I recall this was originally implemented and then later removed because
 it was causing more confusion and problems than it was worth. I hope it
 hasn't crossed the line of existence more than once. At some point it
 should be placed behind a user-customizable variable, preferably something
 like `org-babel-export-code-format' which defaults to something like
 %code but could be augmented to something like Block Name: *%name*\n
 %code. It is not immediately clear if such a variable should have
 different values for different export backends or (likely preferable)
 should expand into Org-mode text *before* export.

 I think you're right about getting this done early in the process. I've been
 thinking only about LaTeX export because that is my immediate goal--not a
 good design perspective.


 I've just pushed up a minor code change which makes customization of the
 format of exported code blocks possible.  I've added a new customization
 variable named `org-babel-exp-code-template' which can be used to
 specify the text which replaces code block bodies during export.  The
 default value of this variable specifies the existing export behavior.
 The attached Org-mode file demonstrates this variable in action.


 #+Title: Custom code block export formats

 - Example code block
   #+Name: foo
   #+BEGIN_SRC sh :bar baz
 echo qux
   #+END_SRC

 - Evaluate this block to export (shows the export of the name).
   #+Name: do-export-name
   #+BEGIN_SRC emacs-lisp :results silent
 (let ((org-babel-exp-code-template
\n=%name=:\n#+BEGIN_SRC %lang%flags\n%body\n#+END_SRC))
   (org-export-as-html nil))
   #+END_SRC

 - Evaluate this block to export (shows the export of header arguments).
   #+Name: do-export-header-arguments
   #+BEGIN_SRC emacs-lisp :results silent
 (let ((org-babel-exp-code-template
Header arguments for =%name=.
 | header  | value|
 |-+--|
 | bar | %bar |
 | results | %results |\n#+BEGIN_SRC %lang%flags\n%body\n#+END_SRC))
   (org-export-as-html nil))
   #+END_SRC


 I imagine that this variable would likely be customized on a
 file-by-file basis using file local variables.


 Perhaps I could help by specifying what I'm trying to do? I'd like to write
 an article or book about particular statistical analyses. I want this also
 to be a piece of reproducible research so readers of the book can follow
 along and perhaps analyze data of their own. I'd like to write a code block
 once and then use it in the following ways: 1) evaluate and return the
 results of analyses; 2) export as a floating listing so I can refer to it in
 discussions of implementation; and 3) tangle to a source code file that can
 be used as the basis for a package that can be used outside of Org mode.


 Sounds like a very cool project.  If this will be public I would love to
 link to it from [1] when it is complete.


 1) is easy with #+call: With the :wrap header argument that we've
 partially implemented, I can mark the results off in whatever environment I
 like, which is a wonderful bit of flexibility. Different kinds of results
 can be presented distinctively.

 2) is partially there--the code itself is handled nicely by minted and
 I'm able to make it look as good as I want. What I'm lacking now is an easy
 way to identify the code block. Seb's suggestion that the header lines be
 included is one way, though Eric F.'s point about the special characters
 tripping up LaTeX is well taken. It might be some work to get an
 intermediate representation that can be exported to all the targets. My
 alternate idea, which is to wrap the code block in an environment to which I
 can attach a caption and a label, is the LaTeX approach and might not work
 as well for other export targets.

 This new solution replaces the code block with Org-mode text before
 export.  This should be the most flexible as arbitrary #+HTML and
 #+LATEX lines can be used in Org-mode.

 Best,

 Footnotes: 
 [1]  http://orgmode.org/worg/org-contrib/babel/uses.html

Hi Eric,

Many thanks.  This works like a charm.  It is deeply satisfying to find
my code block names in the book's List of listings.

I really appreciate your attention to these details.

All the best,
Tom


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



[O] Agenda, yellow bar delayed

2012-01-14 Thread François Pinard
Hi, Org mode friends!

Let me report a tiny annoyance, nothing serious.  It seems to coincide
with a recent git pull, but the coincidence may be accidental.

Whenever I use the I key to clock-in from the agenda, the background
on the agenda line used to immediately go yellow.  Now, it does not
change immediately, yet if I do r to redo, then it changes.  Am I
alone in having observed this?

François





Re: [O] Including source when exporting in PDF

2012-01-14 Thread Frozenlock
This babel block should do the following:

- When exporting, automatically tangle the babel blocks.
- Then take the resulting files and add them to a zip file, along with
the original .org file.
- Add the necessary \usepackage and latex commands to insert the zipfile.

Let me know if something isn't like you want.

Here is the babel block to add to your source (org) file:


#+BEGIN_SRC emacs-lisp :results org :exports results :var
buffer-file-name=(buffer-file-name)
(let ((filename (file-name-nondirectory (file-name-sans-extension
buffer-file-name
(shell-command
 (concat zip -j  filename  .zip  filename.org 
 (mapconcat '(lambda (arg)
   (convert-standard-filename
(expand-file-name arg)))
(org-babel-tangle)
 )))
(concat #+LATEX_HEADER:\\usepackage{attachfile2}\n
#+LATEX: \\vfill \\textattachfile[print=false,color=0.5
0.5 0.5]{filename.zip}{Source (.org) \\ other files...}\n))
#+END_SRC
==


On a related note, I've added some improvements to my own way to
export in multiple format and add the files along with the source. The
latex commands and usepackage are included, so no need to add them
elswhere in the org file:

==
# Make sure this babel block is the last one in the buffer;
# block after this one won't be evaluated before the txt and html export.
#+BEGIN_SRC emacs-lisp :results org :exports results :var
buffer-file-name=(buffer-file-name)
(let ((org-export-babel-evaluate nil)); don't evaluate in 'recursive' exports
  (save-window-excursion ;; avoid leakage when more than one org export in block
(org-export-as-ascii org-export-headline-levels))
  (save-window-excursion (org-export-as-html org-export-headline-levels))
  (let ((filename (file-name-nondirectory (file-name-sans-extension
buffer-file-name)))
(to-include-files (directory-files (file-name-directory 
buffer-file-name
(shell-command
 (concat zip -j  filename  .zip 
 (mapconcat '(lambda (arg) arg)
(remove-if
 '(lambda (file)
(string-match 
\\.$\\|\\.pdf$\\|\\.atfi$\\|\\.tex$\\|# file))
 ;; don't include useless files
 to-include-files)
 )))
(concat #+LATEX_HEADER:\\usepackage{attachfile2}\n
#+LATEX: \\vfill \\textattachfile[print=false,color=0.5 0.5
0.5]{filename.zip}{Source (.org)  html, txt...}\n)))
#+END_SRC
==


Enjoy!



On Thu, Jan 12, 2012 at 8:59 AM, Rainer M Krug r.m.k...@gmail.com wrote:
 On 12 January 2012 14:54, Frozenlock frozenl...@gmail.com wrote:
 The code block I previously sent only require you to specify which
 _extension_ you want or don't want. No need to include any specific
 filename (other than the .zip file in the latex include command).

 Am I to understand you want something to include *all and only* tangled 
 files?

 Yes - and the files do have different extensions (e.g. .R, .sh, .sub,
 none) and are not tangled necessarily in a specific directory.

 and the original org file, but that is not a problem.

 Rainer


 --

 I tried :exports result with no success. I'll try to send a minimum
 working example shortly.

 On Thu, Jan 12, 2012 at 4:11 AM, Rainer M Krug r.m.k...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 12/01/12 03:06, Frozenlock wrote:
 To include multiple files, I export all of the required files
 before the PDF creation and zip them. This way, I only need to
 include a single zip file.

 Good idea.


 #+BEGIN_SRC emacs-lisp :exports none ;; various exports
 (save-window-excursion (org-export-as-ascii
 org-export-headline-levels)) (save-window-excursion
 (org-export-as-html org-export-headline-levels))

 ;;zip the required files (let ((filename (file-name-sans-extension
 (file-name-nondirectory (buffer-file-name) (shell-command
 (concat zip  filename .zip  (mapconcat '(lambda (arg) arg)
 (remove-if '(lambda (filename) (string-match
 \\.$\\|\\.pdf$\\|\\.atfi$\\|# filename)) (directory-files
 (file-name-directory (buffer-file-name   #+END_SRC

 (I've added this code in a babel block to evaluate just before the
 PDF export.)

 I actually did not want to fiddle with the file names, as it is to
 easy to forget some: this concerns in my case literate programming of
 a simulation model in R, resul;ting in several files of different
 extensions - it is to easy to forget one.

 If I tangle, I get all the names of the tangled files, but I do not
 know how I can feed them into the zip file.


 As you can see, I make sure I don't include a previous PDF, or any
 other useless file.

 True.


 If you wish to add only a single type of file, simply replace
 remove-if by remove-if-not and change the value in the
 string-match 

Re: [O] [Orgmode] Automatic screenshot insertion

2012-01-14 Thread Marcelo de Moraes Serpa
A bit OT, but related.

---
It would be *awesome* if we could somehow hook into the emacs
paste/(drag-and)drop events and automatically paste or drop the image
in an org buffer. I don't know if it's possible, but I imagine that if
hooking into those events was somehow possible, then we could get the
event handle with information regarding the file, and automatically
insert a link to it, and if iimage is activated, it would then render the
image. It would be freaking awesome, this is the only thing I miss from
Evernote.
---

- Marcelo.


2012/1/14 François Pinard pin...@iro.umontreal.ca

 Skip Collins skip.coll...@gmail.com writes:

  2012/1/10 François Pinard pin...@iro.umontreal.ca:
  Some sad people think of me as a programmer.  While deep down, I am
  fundamentally an artist.  Programming is mere mean of expression :-).

  You and Jambunathan K. should form a club.

 I do not know Jambunathan, but I'll pay attention! :-)

 François

 P.S. This Org mode mailing list is quite active.  I did not pay
 attention in the last few days (being busy elsewhere) and messages
 accumulated at a relatively fast pace!





[O] Including an active timestamp in encrypted (crypt) org entries

2012-01-14 Thread Marcelo de Moraes Serpa
Hi folks,

So I timestamp everything I input into my (org-based) GTD system (except
for inbox items, that I'm sure I will review soon anyway). Here's how I do
it:

* Sample entry
  2012-01-15 Sun 00:52

I have  (org-insert-time-stamp nil t nil) bound to C-x C-y and I just
insert it below the entry. This makes for a nice chronologic history of
every data in the system.

However, I have a problem with encrypted entries. Of course, if I add it as
part of the content to be encrypted, it will not appear as plain text, but
i tried to do like this:

1) Create the entry:

* Sample Entry

2) Write its contents
3) Tag with :crypt:

* Sample Entry :crypt:

3) Save the buffer. The contents are now encrypted:

* Sample Entry :crypt:
-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.11 (Darwin)

hQEMA7MmqOB5vxnzAQgAy6tE4lj1uLMaAm8+dPL9N2LHxZsH+VWyiig6gY1rE0M0
Y1wDLDPYTIR+AUoSMGmU4S+9DZ9v4xoTBev4tjhtZIA9Lvw6aqf3Xlb2YGTJCCeq
...
-END PGP MESSAGE-

4) Add the timestamp *before* the --BEGIN PGP MESSAGE-- line:

* Sample Entry :crypt:
  2012-01-15 Sun 00:52
-BEGIN PGP MESSAGE-
...

5) Save again.

Expected: Encrypted message and timestamp to stay as is.
What happens: A new encrypted message is written, with the timestamp + the
old encrypted message as part of it.

Any hints appreciated :)

- Marcelo.