[O] Wrong results from R source block when returning a list

[Rainer M Krug]

Hi

The following code block returns a wrong table / list:


#+begin_src R :results value list
list(1:10, 1:5)
#+end_src

#+RESULTS:
- (1 1)
- (2 2)
- (3 3)
- (4 4)
- (5 5)
- (6 1)
- (7 2)
- (8 3)
- (9 4)
- (10 5)

The result is actually in R:

#+begin_src R :results output
list(1:10, 1:5)
#+end_src

#+RESULTS:
: [[1]]
:  [1]  1  2  3  4  5  6  7  8  9 10
: 
: [[2]]
: [1] 1 2 3 4 5

This is likely caused by the recycling rules in R, but it is actually
wrong in the org context:

The shown result is:

#+begin_src R :results table
list(1:10, 1:5)
#+end_src

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


Whil;e I would expect:

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

I have no idea if this is a bug or wrong result due to incompatible
types (R list and org table)?

Is this mentioned in the manual?

Rainer

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

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] bug in org-habits

[John Wiegley]

> Puneeth Chaganti  writes:

>> Actually there has been introduced a constraint on the ordering planning
>> lines and property drawers in 8.3. See http://orgmode.org/Changes.html.>
>> This at least invalidates to use PROPERTIES before SCHEDULED afaics.

> Yes, that is correct and you can use the `org-repair-property-drawers`
> utility function provided to fix your org trees.

I would very much like to see this constraint removed from 8.3. I have always
preferred having SCHEDULED before PROPERTIES, as this is how all my Org files
are arranged.

In fact, this one aspect of 8.3 has kept me at 8.2. I do not understand the
need for such an abitrary restriction.

John

[O] Combine tables which are results from calculations?

[Rainer M Krug]

Hi

Considering the following example:

--8<---cut here---start->8---
#+NAME t1
#+begin_src R :colnames yes
data.frame(a = 1:3)
#+end_src

#+RESULTS:
| a |
|---|
| 1 |
| 2 |
| 3 |

#+NAME t2
#+begin_src R :colnames yes
data.frame(b = 1:10)
#+end_src

#+RESULTS:
|  b |
||
|  1 |
|  2 |
|  3 |
|  4 |
|  5 |
|  6 |
|  7 |
|  8 |
|  9 |
| 10 |

#+NAME t3
#+begin_src R :colnames yes
data.frame(c = 1:7)
#+end_src

#+RESULTS:
| c |
|---|
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |

What I would like to have is:

|  a |  b |  c |
||||
|  1 |  1 |  1 |
|  2 |  2 |  2 |
|  3 |  3 |  3 |
||  4 |  4 |
||  5 |  5 |
||  6 |  6 |
||  7 |  7 |
||  8 ||
||  9 ||
|| 10 ||
--8<---cut here---end--->8---

How can I combine t1, t2 and t3 column wise?

Thanks,

Rainer

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

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Publishing a Book as PDF and ePub.

[Eric S Fraga]

On Monday,  2 Nov 2015 at 15:37, Ian Barton wrote:
> Next year our mountaineering club has its 50th anniversary. On the
> 21st anniversary we published a book of articles written by members of
> the club. 
[...]

> However, as a Latex
> neophyte I was wondering which of the several Latex packages would be
> suitable.

The book class may be enough for you.  In org, it is trivial to
use.  Simply put the line

#+latex_class: book

in your org file and export to pdf (C-c C-e l p).  Top level headlines
are parts, second level headlines are chapters, third level headlines
are section headings, etc.

I've attached a very small org file and the resulting PDF.

If you need to customise the output, you can look at the settings of
org-latex-classes.  If you have any specific needs, just ask here!
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33
#+title: This is my book
#+latex_class: book
* The main part of the book
** The first chapter
*** Introduction
This is some text.
** The second chapter
*** Motivation
This is some more text.
** The first chapter
*** Results
This is some text with an image

[[file:~/s/test/mip.png][file:~/s/test/mip.png]]


t.pdf
Description: Adobe PDF document

Re: [O] bug in org-habits

[Puneeth Chaganti]

On Tue, Nov 3, 2015 at 3:26 PM, Marco Wahl  wrote:
>
>
> Actually there has been introduced a constraint on the ordering planning
> lines and property drawers in 8.3.  See http://orgmode.org/Changes.html.
>
> This at least invalidates to use PROPERTIES before SCHEDULED afaics.


Yes, that is correct and you can use the `org-repair-property-drawers`
utility function provided to fix your org trees.

-- 
Puneeth

Re: [O] bug in org-habits

[Marco Wahl]

"Mark A. Hershberger"  writes:

> org-habit.el is sensitive to the ordering PROPERTIES and SCHEDULED
> and expects them /in only/ the following order:
>
>  * TODO habit name
>  SCHEDULED: <2015-11-03 Tue 07:00 .+1d>
>  :PROPERTIES:
>  :LAST_REPEAT: [2015-11-02 Mon 07:54]
>  :STYLE: habit
>  :END:
>
> Any other ordering, or doubling of PROPERTIES (e.g. STYLE in one, LAST
> REPEAT in another) and the habit will show up as a simple scheduled item
> and not a habit in the agenda view.
>
> org-version: 8.3.2

Actually there has been introduced a constraint on the ordering planning
lines and property drawers in 8.3.  See http://orgmode.org/Changes.html.

This at least invalidates to use PROPERTIES before SCHEDULED afaics.


HTH
-- 
Marco Wahl
GPG: 0x49010A040A3AE6F2

[O] Adding new switch or header

[Phillip Lord]

I am trying to implement a new backend based on the HTML export. I need
to do some post-processing to the source blocks that needs to be
optional. For some blocks I need to replace "[" with "\[" and for some I
don't.

I am not sure whether to use headers or switches.

So

#+begin_src java -s
  student[ 4 ]
#+end_src

would produce html with

  student\[ 4 ]

inside, while

#+begin_src java
  student[ 4 ]
#+end_src

would produce just

  student[ 4 ]


Is it possible to add new switches? And in the exporter how do I know
which switches are present on a block?

Phil

Re: [O] org-capture templates broken?

[Kaushal Modi]

I have bound org-capture to "C-c c" and "C-c c j" is working fine when
using the latest version of org-plus-contrib from org elpa.

[O] Favorite contrib/ packages?

[Kaushal Modi]

HI all,

What are your favorite org contrib/ packages that you simply can't
live without, and consider them to be a part of your org-mode core?

For now, I compile just 3 contrib/ packages by putting the below in my local.mk:

ORG_ADD_CONTRIB = org-eldoc org-mime org-eww


--
Kaushal Modi

Re: [O] bug in org-habits

[John Wiegley]

> Nicolas Goaziou  writes:

> This is not a bug. The order is HEADLINE (SCHEDULED PROPERTIES).

Ah, I had misspoken. It's not SCHEDULE-before-PROPERTIES that has broken for
me, it is the inability to have PROPERTIES at the very end of the entry.

Why must the properties drawer appear before the entry's body?

John

Re: [O] Wrong results from R source block when returning a list

[Charles C. Berry]

On Tue, 3 Nov 2015, Rainer M Krug wrote:


Hi

The following code block returns a wrong table / list:


#+begin_src R :results value list
list(1:10, 1:5)
#+end_src

#+RESULTS:
- (1 1)
- (2 2)
- (3 3)
- (4 4)
- (5 5)
- (6 1)
- (7 2)
- (8 3)
- (9 4)
- (10 5)

The result is actually in R:



In particular in `org-babel-R-write-object-command' which uses 
write.table() which uses as.data.frame() which dispatches to 
as.data.frame.list() which calls data.frame() where the recycling occurs.


[snip]


I have no idea if this is a bug or wrong result due to incompatible
types (R list and org table)?


If you can't coerce a non-atomic R object to a data.frame and get a 
pleasing result, you need to craft your own solution.




Is this mentioned in the manual?


Not that I know of. A comment in `Results Types' in ob-doc-R -

http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html#orgheadline6

- might be helpful.

Chuck

Re: [O] Favorite contrib/ packages?

[Rasmus]

Hi,

Kaushal Modi  writes:

> What are your favorite org contrib/ packages that you simply can't
> live without

ox-koma-letter.el seems to be the only contrib package I load in my init.
I have used org-drill.el in the past.

Rasmus


-- 
This is the kind of tedious nonsense up with which I will not put

[O] org-capture templates broken?

[Kaushal Modi]

Hi all,

I am on the following build of emacs:

Emacs version: GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+
Version 2.24.23)
 of 2015-11-02, built using commit 5401bb8645f955b6fde8c0a5e5c8cf5ec1cab626.

./configure options:
  --prefix=/home/kmodi/usr_local/apps/6/emacs/master
'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
-I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0'
'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib
-L/home/kmodi/usr_local/6/lib64 -ggdb3'

Features:
  XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF
GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS GTK2 X11


Org version: Org-mode version 8.3.2 (release_8.3.2-254-g061112 @
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/)

This is how I set my org capture template:

(setq org-capture-templates
  '(("j" "Journal" entry ; `org-capture' binding + j
 (file+datetree (expand-file-name "journal.org" org-directory))
 "\n* %?\n  Entered on %U")
("n" "Note" entry ; `org-capture' binding + n
 (file (expand-file-name "notes.org" org-directory))
 "\n* %?\n  Context:\n%i\n  Entered on %U")
("u" "UVM/System Verilog Notes" ; `org-capture' binding + u
 entry (file (expand-file-name "uvm.org" org-directory))
 "\n* %?\n  Context:\n%i\n  Entered on %U")))

I use org-capture almost every other day. So I can confirm that all
those file paths are valid. I udpated to the latest git version of
org-mode yesterday (and I updated to the latest today too). But today
is the first time I tried to use org-capture this week.

When I do M-x org-capture, I see the capture template selection buffer
fine. But when I hit any key to one of the templates (for example: 'j'
or 'n'), I get this error:

Debugger entered--Lisp error: (error "Capture abort: (file-error
Cannot open load file No such file or directory org-eldoc)")
  signal(error ("Capture abort: (file-error Cannot open load file No
such file or directory org-eldoc)"))
  error("Capture abort: %s" (file-error "Cannot open load file" "No
such file or directory" "org-eldoc"))
  org-capture(nil)
  funcall-interactively(org-capture nil)
  call-interactively(org-capture nil nil)
  command-execute(org-capture)


The backtrace is surprisingly short and I couldn't understand why it
fails. Also org-eldoc is in contrib and I don't include it in my
compilation. So I don't know what org-capture has to do with
org-eldoc.

Is org-capture template selection working fine for anyone on the
latest build as of today?


--
Kaushal Modi

Re: [O] org-capture templates broken?

[Kaushal Modi]

The issue got fixed when I changed the below in my local.mk file and
rebuilt org:

From

ORG_ADD_CONTRIB = org-mime org-eww

To

ORG_ADD_CONTRIB = org-eldoc org-mime org-eww

I figured out why I was seeing the problem:

I have org-plus-contrib installed too. So when `package-initialize`
was called, the below bare form in org-eldoc.el (installed via
org-plus-contrib) got evaluated too:

(add-hook 'org-mode-hook #'org-eldoc-load)


I like to have both stable and dev version installed so that I can
switch to the stable version in case of emergency. So I have this
snippet in my org setup:

;; If `org-load-version-dev' is non-nil, remove the stable version of org
;; from the `load-path'.
(when (bound-and-true-p org-load-version-dev)
  (when (version<= "25.0" emacs-version) ;
`directory-files-recursively' is not available in older emacsen
  (let ((org-stable-install-path (car (directory-files-recursively
   package-user-dir
   "org-plus-contrib-[0-9]+"
   :include-directories
(setq load-path (delete org-stable-install-path load-path)


That basically removes the org-plus-contrib dir from the load-path if
I choose to use the dev version of org-mode. But that still keeps
`org-eldoc-load' in the org-mode-hook.

@Lucas: I would propose to not update the org-mode-hook automatically;
that add-hook should not be bare in the org-eldoc.el. It should be
updated only via a function call.

--
Kaushal Modi

[O] insert aligned table using capture template

[Shankar Rao]

I'm trying to use to org-capture insert tables into a datetree that I use
to manage my finances. Below is the capture template I set up for it. Is
there a way to make the table be aligned after I finalize the capture?

Shankar

-

(setq org-capture-templates
   '(...
("f" "Add Tables" plain
(file+datetree+prompt "~/my-table-file.org")
 ,(concat "#+TBLNAME: accounts-%<%y%m%d>\n"
  "| Account | Initial | Final | Calculations |\n"
  "|-\n"
  "| Account A | | | |\n"
  "| Account B | | | |\n"
  "| Account C | | | |\n")
:immediate-finish t
:jump-to-captured t)
...))

Re: [O] bug in org-habits

[Nicolas Goaziou]

Hello,

John Wiegley  writes:

>> Nicolas Goaziou  writes:
>
>> This is not a bug. The order is HEADLINE (SCHEDULED PROPERTIES).
>
> Ah, I had misspoken. It's not SCHEDULE-before-PROPERTIES that has broken for
> me, it is the inability to have PROPERTIES at the very end of the entry.
>
> Why must the properties drawer appear before the entry's body?

IIRC, you already asked the question. 

It is for efficiency reasons. Properties are an important feature in
Org, letting them anywhere in a potentially long entry doesn't scale
well.


Regards,

-- 
Nicolas Goaziou

Re: [O] Adding new switch or header

[Eric S Fraga]

On Tuesday,  3 Nov 2015 at 15:54, Phillip Lord wrote:
> I am trying to implement a new backend based on the HTML export. I need
> to do some post-processing to the source blocks that needs to be
> optional. For some blocks I need to replace "[" with "\[" and for some I
> don't.
>
> I am not sure whether to use headers or switches.

What about neither?  Maybe something along #+ATTR_XXX: instead, where
XXX is the name of your derived backend, along the lines of ATTR_HTML
and ATTR_LATEX?

Others may tell us that my suggestion is worse but I think playing
around with the babel syntax is asking for trouble...
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] Favorite contrib/ packages?

[Jorge A. Alfaro-Murillo]

Kaushal Modi writes:

What are your favorite org contrib/ packages that you simply 
can't live without, and consider them to be a part of your 
org-mode core?


org-contacts and org-passwords, definitely. Sometimes I use 
org-checklist.


--
Jorge.

Re: [O] export breaks on org-id in maint

[Samuel Wales]

> Fixed. Thank you.

thanks.


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

Ramsay's disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

Re: [O] bug in org-habits

[Achim Gratz]

John Wiegley writes:
> Thanks for discussing this with me, Nicolas. I appreciate there may be
> technical complexities involved. Could we special-case allow PROPERTIES to be
> the *very last thing* in an entry? I don't need it to float anywhere else. I
> just like it to be at the end.

Well, that's precisely the thing that doesn't scale and that Nicolas
wanted to avoid.  Putting the properties at the beginning of an entry
makes the search pretty much constant time and if you find something
else at the start of the entry then you know there aren't any and can go
on (this is pretty important for making sure property inheritance works
correctly, among other things).  If you could put them _anywhere_ else,
you'd have to keep searching until you either find them or you've
exhausted the span of the entry.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [O] Adding new switch or header

[Phillip Lord]

Eric S Fraga  writes:

> On Tuesday,  3 Nov 2015 at 15:54, Phillip Lord wrote:
>> I am trying to implement a new backend based on the HTML export. I need
>> to do some post-processing to the source blocks that needs to be
>> optional. For some blocks I need to replace "[" with "\[" and for some I
>> don't.
>>
>> I am not sure whether to use headers or switches.
>
> What about neither?  Maybe something along #+ATTR_XXX: instead, where
> XXX is the name of your derived backend, along the lines of ATTR_HTML
> and ATTR_LATEX?
>
> Others may tell us that my suggestion is worse but I think playing
> around with the babel syntax is asking for trouble...

That's a good call, I think. The latex example is very clear, so I've
got that implemented now.

Are these form of attributes specific to the source block which they
precede? Or is it possible to do any kind of inheritance with them? For
my use case, all the code blocks inside a Header One block will behave
in the same way (either with \[ escaping or without).

Not a major problem if not, I can template it if not, but useful to
know.


Phil

Re: [O] bug in org-habits

[John Wiegley]

> Achim Gratz  writes:

> I don't think so. Search for end of entry can be complex in itself and you
> would never know if the properties you find by looking back aren't belonging
> to an entry one level down unless you scanned the whole span again. Also,
> properties can be any size and you have to search for the beginning of the
> drawer.

Good point.  Still, the option I'd still choose would be:

org-allow-floating-properties

  If set to `non-nil', the :PROPERTIES: drawer may begin anywhere within
  an entry. Note that this will slow down many operations due to the
  additional scan needed, and may lead to incorrect result if similar text
  is found elsewhere within an entry, which is the recommended and default
  value for this variable is nil.

John

[O] why does exporting look for org-id in the entire file even when subtree export?

[Samuel Wales]

i do not claim to understand the code but org-export-get-environment
is possibly calling org-id-find on entire buffer instead of subtree.

perhaps this explains why exporting a couple of lines without any
org-id link takes 15s to a minute or so.

it is always checking all of my files for org id even when i export to subtree.


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

Ramsay's disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

Re: [O] bug in org-habits

[John Wiegley]

> Jonathan Leech-Pepin  writes:

> Wouldn't last item in entry scale without issues? Find end of headline
> (start of next or end of buffer) and search backwards. If first element from
> end is a property drawer you have it, otherwise you still know there is
> none.

That sounds even better than what I mentioned about re-search-forward, and
O(1) time complexity as well.

John

[O] (no subject)

[Fritz Kunze]

i am running emacs on a chromebook namely  emacs 24.4.1 and org
8.3.1-87-g4ef2c0...) on
chromebrew(https://skycocker.github.io/chromebrew/) .  My question:How
to make emacs org-mode open links to sites in Google Chrome?How to
make emacs org-mode open links to sites in Google Chrome


thanks in advance,

fritz kunze (fku...@gmail.com)

i tried adding these lines to my init.el file (with no effect):

(setq browse-url-browser-function 'browse-url-generic

browse-url-generic-program "chromium-browser")

(setq browse-url-browser-function 'browse-url-generic

  browse-url-generic-program "google-chrome")

export BROWSER="google-chrome"

browse-url-generic-program

[O] [PATCH 7/9] org-notmuch: add date support to org-notmuch-store-link

[Jan Malakhovski]

* contrib/lisp/org-notmuch.el (org-notmuch-store-link): Add date support.
* doc/org.texi: Fix `org-capture-templates' documentation.
---
 contrib/lisp/org-notmuch.el | 7 ---
 doc/org.texi| 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/contrib/lisp/org-notmuch.el b/contrib/lisp/org-notmuch.el
index 712ec5a..265742e 100644
--- a/contrib/lisp/org-notmuch.el
+++ b/contrib/lisp/org-notmuch.el
@@ -71,15 +71,16 @@ Should accept a notmuch search string as the sole argument."
 (defun org-notmuch-store-link ()
   "Store a link to a notmuch search or message."
   (when (eq major-mode 'notmuch-show-mode)
-(let* ((message-id (notmuch-show-get-prop :id))
+(let* ((message-id (notmuch-show-get-message-id t))
   (subject (notmuch-show-get-subject))
   (to (notmuch-show-get-to))
   (from (notmuch-show-get-from))
+  (date (org-trim (notmuch-show-get-date)))
   desc link)
-  (org-store-link-props :type "notmuch" :from from :to to
+  (org-store-link-props :type "notmuch" :from from :to to :date date
:subject subject :message-id message-id)
   (setq desc (org-email-link-description))
-  (setq link (concat "notmuch:"  "id:" message-id))
+  (setq link (concat "notmuch:id:" message-id))
   (org-add-link-props :link link :description desc)
   link)))
 
diff --git a/doc/org.texi b/doc/org.texi
index 2bf2b24..106bdac 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -7315,7 +7315,7 @@ Link type|  Available keywords
 bbdb |  %:name %:company
 irc  |  %:server %:port %:nick
 vm, vm-imap, wl, mh, mew, rmail, |  %:type %:subject %:message-id
-gnus |  %:from %:fromname %:fromaddress
+gnus, notmuch|  %:from %:fromname %:fromaddress
  |  %:to   %:toname   %:toaddress
  |  %:date @r{(message date header field)}
  |  %:date-timestamp @r{(date as active 
timestamp)}
-- 
2.6.2

Re: [O] insert aligned table using capture template

[Shankar Rao]

Oops.

(set org-capture-templates '(...

should be

(set org-capture-templates `(...



On Tue, Nov 3, 2015 at 12:28 PM, Nick Dokos  wrote:

> Shankar Rao  writes:
>
> > I'm trying to use to org-capture insert tables into a datetree that I
> use to manage my finances. Below is the capture template I set up for it.
> Is there a way to make the table be aligned
> > after I finalize the capture?
> >
> > Shankar
> >
> > -
> >
> > (setq org-capture-templates
> >'(...
> > ("f" "Add Tables" plain
> > (file+datetree+prompt "~/my-table-file.org")
> >  ,(concat "#+TBLNAME: accounts-%<%y%m%d>\n"
> >   "| Account | Initial | Final | Calculations |\n"
> >   "|-\n"
> >   "| Account A | | | |\n"
> >   "| Account B | | | |\n"
> >   "| Account C | | | |\n")
> > :immediate-finish t
> > :jump-to-captured t)
> > ...))
>
> The ,(concat ...) stuff did not work for me: is is supposed to? I get
> "invalid capture template".
>
> Be that as it may, you can do this (maybe with more safeguards):
>
> --8<---cut here---start->8---
> (add-hook 'org-capture-prepare-finalize-hook (function
> my-capture-table-align))
>
> (defun my-capture-table-align ()
>   (forward-line 1) ;; skip the #+name line
>   (if (org-at-table-p 'any)
>   (org-table-align)))
> --8<---cut here---end--->8---
>
> --
> Nick
>
>
>

[O] [PATCH 8/9] ob-calc: add more API, documentation and examples so that it can be used in tables

[Jan Malakhovski]

* lisp/ob-calc.el (org-babel-calc-eval):
(org-babel-calc-set-env):
(org-babel-calc-reset-env):
(org-babel-calc-store-env):
(org-babel-calc-eval-string):
(org-babel-calc-eval-line): New funcion.
(org-babel-execute:calc): Rewrite to use new functions.

This also makes ob-calc useful for computing complicated stuff in org-tables. 
See
`org-babel-calc-eval` docstring for more info.
---
 lisp/ob-calc.el | 232 
 1 file changed, 183 insertions(+), 49 deletions(-)

diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index a8c50da..e8b43e7 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -1,4 +1,4 @@
-;;; ob-calc.el --- Babel Functions for Calc  -*- lexical-binding: t; 
-*-
+;;; ob-calc.el --- Babel Functions for Calc
 
 ;; Copyright (C) 2010-2015 Free Software Foundation, Inc.
 
@@ -23,7 +23,8 @@
 
 ;;; Commentary:
 
-;; Org-Babel support for evaluating calc code
+;; Org-Babel and Org-Table support for evaluating calc code.
+;; See `org-babel-calc-eval' for documentation.
 
 ;;; Code:
 (require 'ob)
@@ -42,67 +43,200 @@
 (defun org-babel-expand-body:calc (body _params)
   "Expand BODY according to PARAMS, return the expanded body." body)
 
-(defvar org--var-syms) ; Dynamically scoped from org-babel-execute:calc
-
 (defun org-babel-execute:calc (body params)
   "Execute a block of calc code with Babel."
+  (org-babel-calc-eval (org-babel-expand-body:calc body params)
+  (org-babel--get-vars params)))
+
+(defvar org--ob-calc-env-symbol nil) ; For org-babel-calc-eval
+(defvar org--ob-calc-var-names nil)
+
+(defun org-babel-calc-eval (text  environment env-symbol setup 
env-setup)
+  "Evaluate TEXT as set of calc expressions (one per line) and return the top 
of the stack.
+
+Optional argument ENVIRONMENT is a user-defined variables
+environment which is an alist of (SYMBOL . VALUE).
+
+Optional argument ENV-SYMBOL is a symbol of a user-defined
+variables environment which is an alist of (SYMBOL . VALUE).
+
+Setting your environment using either of ENVIRONMENT or
+ENV-SYMBOL has the same effect. The difference is that this
+function caches the value of ENV-SYMBOL internally between
+succesive evaluations with ENV-SYMBOL arguments of equal symbol
+names and reevaluates the value of ENV-SYMBOL only when the
+symbol name of ENV-SYMBOL changes.
+
+Additionally, setting ENV-SYMBOL to nil will forget any
+internal environment before applying ENVIRONMENT, i.e. with
+ENV-SYMBOL set to nil this function is pure.
+
+You can also use `org-babel-calc-set-env',
+`org-babel-calc-reset-env' and `org-babel-calc-store-env' to set,
+reset and update the internal environment between evaluations.
+
+Optional argument SETUP allows additional calc setup on every
+evaluation.
+
+Optional argument ENV-SETUP allows additional calc setup on every
+ENV-SYMBOL change.
+
+This function is useful if you want to evaluate complicated
+formulas in a table, e.g. after evaluating
+
+  (setq an-env '((foo . \"2 day\")
+ (bar . \"6 hr\")))
+
+you can use this in the following table
+
+  | Expr  | Result   |
+  |---+--|
+  | foo + bar | 2 day + 6 hr |
+  | foo - bar | 2 day - 6 hr |
+  |---+--|
+  #+TBLFM: $2='(org-babel-calc-eval $1 an-env)
+
+which would become slow to recompute with a lot of rows, but then
+you can change the TBLFM line to
+
+  #+TBLFM: $2='(org-babel-calc-eval $1 nil 'an-env)
+
+and it would become fast again.
+
+SETUP argument can be used like this:
+
+  | Expr  | Result   |
+  |---+--|
+  | foo + bar | 2.25 day |
+  | foo - bar | 1.75 day |
+  |---+--|
+  #+TBLFM: $2='(org-babel-calc-eval $1 nil 'an-env nil (lambda () 
(calc-units-simplify-mode t)))
+
+In case that is not fast or complicated enough, you can combine
+this with `org-babel-calc-store-env' to produce some clever stuff
+like, e.g. computing environment on the fly (an-env variable is
+not actually used here, it is being generated just in case you
+want to use it elsewhere):
+
+  (setq an-env nil)
+  (defun compute-and-remember (name expr)
+(let* ((v (org-babel-calc-eval expr nil 'an-env nil (lambda () 
(calc-units-simplify-mode t
+   (c `(,(intern name) . ,v)))
+(org-babel-calc-store-env (list c))
+(push c an-env)
+v))
+
+and then
+
+  | Name | Expr   | Value|
+  |--++--|
+  | foo  | 2 day  | 2 day|
+  | bar  | foo + 6 hr | 2.25 day |
+  |--++--|
+  #+TBLFM: $3='(compute-and-remember $1 $2)
+
+Note that you can set ENV-SYMBOL to 'nil to get ENV-SETUP
+without.
+
+The subsequent results might become somewhat surprising in case
+ENVIRONMENT overrides variables set with ENV-SYMBOL."
+  (org-babel-calc-init)
+  (cond
+((equal env-symbol nil) (org-babel-calc-reset-env))
+((not (equal (symbol-name env-symbol) org--ob-calc-env-symbol))
+   (org-babel-calc-set-env env-symbol)
+   

[O] [PATCH 9/9] ob-calc: don't leave garbage on the stack

[Jan Malakhovski]

* lisp/ob-calc.el (org-babel-calc-eval-string): Clean up the stack after 
expression
  evaluation.
---
 lisp/ob-calc.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index e8b43e7..2656f27 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -196,7 +196,9 @@ See `org-babel-calc-eval' for more info."
   (mapc #'org-babel-calc-eval-line (split-string text "[\n\r]"))
   (save-excursion
 (with-current-buffer (get-buffer "*Calculator*")
-  (calc-eval (calc-top 1)
+  (prog1
+(calc-eval (calc-top 1)
+(calc-pop 1))
 
 (defun org-babel-calc-eval-line (line)
   (let ((line (org-babel-trim line)))
-- 
2.6.2

Re: [O] bug in org-habits

[John Wiegley]

> Nicolas Goaziou  writes:

> I'd rather not have syntax too much customizable, for portability, ease of
> maintenance, too. There are already too many mistakes in that area.

Thanks for discussing this with me, Nicolas. I appreciate there may be
technical complexities involved. Could we special-case allow PROPERTIES to be
the *very last thing* in an entry? I don't need it to float anywhere else. I
just like it to be at the end.

> If you need to end your entry with a drawer, couldn't you put any of them
> there? You can even have one there named "PROPERTIES".

But it wouldn't be the true PROPERTIES, would it? Most of my entries look like
this (and I have many thousands of them):

** TODO Update auto insurance cards :Home:ATTACH:
SCHEDULED: <2016-03-11 Fri +6m>
- State "DONE"   from "TODO"   [2015-09-11 Fri 11:28]
- State "WAITING"from "TODO"   [2015-07-22 Wed 19:48]
- State "DONE"   from "STARTED"[2014-12-13 Sat 15:56]
- State "DONE"   from "TODO"   [2014-03-31 Mon 03:11]
- State "CANCELED"   from "TODO"   [2013-12-11 Wed 19:23]
- State "CANCELED"   from "TODO"   [2013-05-21 Tue 12:30]
- State "DONE"   from "TODO"   [2012-05-17 Thu 22:24]
- State "CANCELED"   from "TODO"   [2011-04-23 Sat 22:04]
- State "TODO"   from "DONE"   [2010-10-23 Sat 21:54]
- State "DONE"   from "TODO"   [2010-10-08 Fri 14:26]
:PROPERTIES:
:ID:   B1F3D3F6-9F39-4899-9AF8-93E019E7C6BB
:CREATED:  [2010-05-08 Sat 17:34]
:LAST_REPEAT: [2015-09-11 Fri 11:28]
:Attachments: AutoInsuranceIdCards.pdf
:END:

I suppose I've just become familiar with seeing :PROPERTIES: as the "period"
at the end of the entry, and I'll like to keep it there if we can devise a
technical answer that does not make life more difficult for you.

John

[O] [PATCH 1/9] org-clock: fix a typo

[Jan Malakhovski]

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

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 09f8391..ad423f1 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -2774,7 +2774,7 @@ following structure:
   (LEVEL HEADLINE TIMESTAMP TIME)
 
 LEVEL: The level of the headline, as an integer.  This will be
-   the reduced leve, so 1,2,3,... even if only odd levels
+   the reduced level, so 1,2,3,... even if only odd levels
are being used.
 HEADLINE:  The text of the headline.  Depending on PARAMS, this may
already be formatted like a link.
-- 
2.6.2

[O] [PATCH 5/9] rename `org-duration-string-to-minutes' to `org-clocksum-string-to-minutes' everywhere

[Jan Malakhovski]

* lisp/org-agenda.el:
* lisp/org-clock.el:
* lisp/org-colview.el:
* lisp/org.el:
* contrib/lisp/org-depend.el:
* contrib/lisp/ox-taskjuggler.el: Rename (org-duration-string-to-minutes)
  to (org-clocksum-string-to-minutes).
---
 contrib/lisp/org-depend.el |  2 +-
 contrib/lisp/ox-taskjuggler.el |  2 +-
 lisp/org-agenda.el |  2 +-
 lisp/org-clock.el  | 14 +++---
 lisp/org-colview.el|  2 +-
 lisp/org.el| 14 +-
 6 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/contrib/lisp/org-depend.el b/contrib/lisp/org-depend.el
index 1cd4130..7b263bc 100644
--- a/contrib/lisp/org-depend.el
+++ b/contrib/lisp/org-depend.el
@@ -270,7 +270,7 @@ This does two different kinds of triggers:
(effort (when (or effort-up effort-down)
  (let ((effort (get-text-property (point) 
'org-effort)))
(when effort
- (org-duration-string-to-minutes 
effort))
+ (org-clocksum-string-to-minutes 
effort))
(push (list (point) todo-kwd priority tags effort)
  items))
  (unless (org-goto-sibling)
diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 2bd47e6..b425b1b 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -861,7 +861,7 @@ a unique id will be associated to it."
  (and complete (format "  complete %s\n" complete))
  (and effort
   (format "  effort %s\n"
-  (let* ((minutes (org-duration-string-to-minutes effort))
+  (let* ((minutes (org-clocksum-string-to-minutes effort))
  (hours (/ minutes 60.0)))
 (format "%.1fh" hours
  (and priority (format "  priority %s\n" priority))
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 6313f52..ab4595b 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7665,7 +7665,7 @@ E looks like \"+<2:25\"."
   ((equal op ??) op)
   (t '=)))
 (list 'org-agenda-compare-effort (list 'quote op)
- (org-duration-string-to-minutes e
+ (org-clocksum-string-to-minutes e
 
 (defun org-agenda-compare-effort (op value)
   "Compare the effort of the current line with VALUE, using OP.
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 4563a8a..ab65d3b 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -668,7 +668,7 @@ If not, show simply the clocked time like 01:50."
   (let ((clocked-time (org-clock-get-clocked-time)))
 (if org-clock-effort
(let* ((effort-in-minutes
-   (org-duration-string-to-minutes org-clock-effort))
+   (org-clocksum-string-to-minutes org-clock-effort))
   (work-done-str
(org-propertize
 (org-minutes-to-clocksum-string clocked-time)
@@ -749,10 +749,10 @@ clocked item, and the value displayed in the mode line."
  ;; A string.  See if it is a delta
  (setq sign (string-to-char value))
  (if (member sign '(?- ?+))
- (setq current (org-duration-string-to-minutes current)
+ (setq current (org-clocksum-string-to-minutes current)
value (substring value 1))
(setq current 0))
- (setq value (org-duration-string-to-minutes value))
+ (setq value (org-clocksum-string-to-minutes value))
  (if (equal ?- sign)
  (setq value (- current value))
(if (equal ?+ sign) (setq value (+ current value)
@@ -770,7 +770,7 @@ clocked item, and the value displayed in the mode line."
   "Show notification if we spent more time than we estimated before.
 Notification is shown only once."
   (when (org-clocking-p)
-(let ((effort-in-minutes (org-duration-string-to-minutes org-clock-effort))
+(let ((effort-in-minutes (org-clocksum-string-to-minutes org-clock-effort))
  (clocked-time (org-clock-get-clocked-time)))
   (if (setq org-clock-task-overrun
(if (or (null effort-in-minutes) (zerop effort-in-minutes))
@@ -1193,7 +1193,7 @@ make this the default behavior.)"
   (setq org-clock-notification-was-shown nil)
   (org-refresh-properties
org-effort-property '((effort . identity)
-(effort-minutes . org-duration-string-to-minutes)))
+(effort-minutes . org-clocksum-string-to-minutes)))
   (catch 'abort
 (let ((interrupting (and (not org-clock-resolving-clocks-due-to-idleness)
 (org-clocking-p)))
@@ -2869,13 +2869,13 @@ TIME:  The sum of all time spend in this tree, in 
minutes.  This time
   "Compute a time fraction in percent.
 TOTAL s a total time string.
 STRINGS is a list of strings that should be checked for a 

[O] [PATCH 2/9] org-colview: add a FIXME

[Jan Malakhovski]

TINYCHANGE
---
 lisp/org-colview.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index b698801..d27abc3 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -1113,6 +1113,9 @@ display, or in the #+COLUMNS line of the current buffer."
((memq fmt '(checkbox checkbox-n-of-m checkbox-percent))
 (if (equal s "[X]") 1. 0.01))
((memq fmt '(estimate)) (org-string-to-estimate s))
+   ;; FIXME: does this duplicate org-clocksum-string-to-minutes in a most 
peculiar way?
+   ;; I can guess that long time ago this used org-hh:mm-string-to-minutes
+   ;; and all this ugliness derives from that
((string-match (concat "\\([0-9.]+\\) *\\("
  (regexp-opt (mapcar 'car org-effort-durations))
  "\\)") s)
-- 
2.6.2

[O] [PATCH 3/9] org-clock: fix `org-clock-time%'

[Jan Malakhovski]

* lisp/org-clock.el (org-clock-time%): Respect org-effort-durations.

This also fixes a bug with time percents looking pretty much random and adding
to a number that is less than 100% when a clock report has long intervals
(e.g. days).
---
 lisp/org-clock.el | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index ad423f1..4563a8a 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -2867,27 +2867,20 @@ TIME:  The sum of all time spend in this tree, in 
minutes.  This time
 
 (defun org-clock-time% (total  strings)
   "Compute a time fraction in percent.
-TOTAL s a time string like 10:21 specifying the total times.
+TOTAL s a total time string.
 STRINGS is a list of strings that should be checked for a time.
-The first string that does have a time will be used.
-This function is made for clock tables."
-  (let ((re "\\([0-9]+\\):\\([0-9]+\\)")
-   tot s)
-(save-match-data
+Strings are parsed using `org-duration-string-to-minutes`.
+The first string that does have a time will be used. This
+function is made for clock tables."
+  (save-match-data
+(let (tot s cur)
   (catch 'exit
-   (if (not (string-match re total))
-   (throw 'exit 0.)
- (setq tot (+ (string-to-number (match-string 2 total))
-  (* 60 (string-to-number (match-string 1 total)
- (if (= tot 0.) (throw 'exit 0.)))
+   (setq tot (org-duration-string-to-minutes total))
+   (if (= tot 0.) (throw 'exit 0.))
(while (setq s (pop strings))
- (if (string-match "\\([0-9]+\\):\\([0-9]+\\)" s)
- (throw 'exit
-(/ (* 100.0 (+ (string-to-number (match-string 2 s))
-   (* 60 (string-to-number
-  (match-string 1 s)
-   tot
-   0
+ (setq cur (org-clocksum-string-to-minutes s))
+ (if (not (equal cur nil)) (throw 'exit (/ (* 100.0 cur) tot
+   nil
 
 ;; Saving and loading the clock
 
-- 
2.6.2

[O] [PATCH v2 0/9] mail, clock and calc changes

[Jan Malakhovski]

Hello.

While my assignment is snail-mail delivered to and processed by FSF
I'd like to request comments on the following set of patches, which
contains all the patches I sent to this list before and some new ones.

I'm mainly worried by ChangeLog format and possibly unorthodox elisp
in ob-calc.

The first two are TINYCHANGE.

Cheers,
  Jan

Jan Malakhovski (9):
  org-clock: fix a typo
  org-colview: add a FIXME
  org-clock: fix `org-clock-time%'
  org: move `org-duration-string-to-minutes' to a better place
  rename `org-duration-string-to-minutes' to
`org-clocksum-string-to-minutes' everywhere
  factor out date-timestamp* calculations to org-store-link-props
  org-notmuch: add date support to org-notmuch-store-link
  ob-calc: add more API, documentation and examples so that it can be
used in tables
  ob-calc: don't leave garbage on the stack

 contrib/lisp/org-depend.el |   2 +-
 contrib/lisp/org-mew.el|  11 +-
 contrib/lisp/org-notmuch.el|   7 +-
 contrib/lisp/org-vm.el |  11 +-
 contrib/lisp/org-wl.el |  10 +-
 contrib/lisp/ox-taskjuggler.el |   2 +-
 doc/org.texi   |   4 +-
 lisp/ob-calc.el| 236 -
 lisp/org-agenda.el |   2 +-
 lisp/org-clock.el  |  41 +++
 lisp/org-colview.el|   5 +-
 lisp/org-gnus.el   |  15 +--
 lisp/org-mhe.el|  10 +-
 lisp/org-rmail.el  |  11 +-
 lisp/org.el|  67 +++-
 15 files changed, 263 insertions(+), 171 deletions(-)

-- 
2.6.2

[O] [PATCH 4/9] org: move `org-duration-string-to-minutes' to a better place

[Jan Malakhovski]

---
 lisp/org.el | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 6218a3a..a0fe644 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18328,6 +18328,26 @@ If no number is found, the return value is 0."
 (string-to-number (match-string 1 s)))
(t 0)))
 
+(defun org-duration-string-to-minutes (s  output-to-string)
+  "Convert a duration string S to minutes.
+
+A bare number is interpreted as minutes, modifiers can be set by
+customizing `org-effort-durations' (which see).
+
+Entries containing a colon are interpreted as H:MM by
+`org-hh:mm-string-to-minutes'."
+  (let ((result 0)
+   (re (concat "\\([0-9.]+\\) *\\("
+   (regexp-opt (mapcar 'car org-effort-durations))
+   "\\)")))
+(while (string-match re s)
+  (incf result (* (cdr (assoc (match-string 2 s) org-effort-durations))
+ (string-to-number (match-string 1 s
+  (setq s (replace-match "" nil t s)))
+(setq result (floor result))
+(incf result (org-hh:mm-string-to-minutes s))
+(if output-to-string (number-to-string result) result)))
+
 (defcustom org-image-actual-width t
   "Should we use the actual width of images when inlining them?
 
@@ -18386,26 +18406,6 @@ The value is a list, with zero or more of the symbols 
`effort', `appt',
   :package-version '(Org . "8.3")
   :group 'org-agenda)
 
-(defun org-duration-string-to-minutes (s  output-to-string)
-  "Convert a duration string S to minutes.
-
-A bare number is interpreted as minutes, modifiers can be set by
-customizing `org-effort-durations' (which see).
-
-Entries containing a colon are interpreted as H:MM by
-`org-hh:mm-string-to-minutes'."
-  (let ((result 0)
-   (re (concat "\\([0-9.]+\\) *\\("
-   (regexp-opt (mapcar 'car org-effort-durations))
-   "\\)")))
-(while (string-match re s)
-  (incf result (* (cdr (assoc (match-string 2 s) org-effort-durations))
- (string-to-number (match-string 1 s
-  (setq s (replace-match "" nil t s)))
-(setq result (floor result))
-(incf result (org-hh:mm-string-to-minutes s))
-(if output-to-string (number-to-string result) result)))
-
  Files
 
 (defun org-save-all-org-buffers ()
-- 
2.6.2

Re: [O] bug in org-habits

[John Wiegley]

> Nicolas Goaziou  writes:

> It is for efficiency reasons. Properties are an important feature in Org,
> letting them anywhere in a potentially long entry doesn't scale well.

Since it scales for my use case, can I please have a customization variable to
relax this restriction? I prefer PROPERTIES drawers at the end, and would
prefer not to trade something I want for something that doesn't affect me.

Thanks, John

[O] [PATCH 6/9] factor out date-timestamp* calculations to org-store-link-props

[Jan Malakhovski]

* lisp/org.el (org-store-link-props): Rewrite function to get date-timestamp*
  calculations.
* lisp/org-gnus.el:
* lisp/org-mhe.el:
* lisp/org-rmail.el:
* contrib/lisp/org-mew.el:
* contrib/lisp/org-vm.el:
* contrib/lisp/org-wl.el: Remove date-timestamp* copy-paste.
* doc/org.texi: Fix `org-capture-templates' documentation.
---
 contrib/lisp/org-mew.el | 11 +--
 contrib/lisp/org-vm.el  | 11 +--
 contrib/lisp/org-wl.el  | 10 +-
 doc/org.texi|  4 ++--
 lisp/org-gnus.el| 15 +--
 lisp/org-mhe.el | 10 +-
 lisp/org-rmail.el   | 11 +--
 lisp/org.el | 15 +--
 8 files changed, 21 insertions(+), 66 deletions(-)

diff --git a/contrib/lisp/org-mew.el b/contrib/lisp/org-mew.el
index eb0afc0..35fdd8b 100644
--- a/contrib/lisp/org-mew.el
+++ b/contrib/lisp/org-mew.el
@@ -167,19 +167,10 @@ with \"t\" key."
   (from (mew-header-get-value "From:"))
   (to (mew-header-get-value "To:"))
   (date (mew-header-get-value "Date:"))
-  (date-ts (and date (format-time-string
-  (org-time-stamp-format t)
-  (date-to-time date
-  (date-ts-ia (and date (format-time-string
- (org-time-stamp-format t t)
- (date-to-time date
   (subject (mew-header-get-value "Subject:"))
   desc link)
- (org-store-link-props :type "mew" :from from :to to
+ (org-store-link-props :type "mew" :from from :to to :date date
:subject subject :message-id message-id)
- (when date
-   (org-add-link-props :date date :date-timestamp date-ts
-   :date-timestamp-inactive date-ts-ia))
  (setq message-id (org-remove-angle-brackets message-id))
  (setq desc (org-email-link-description))
  (setq link (concat "mew:" folder-name "#" message-id))
diff --git a/contrib/lisp/org-vm.el b/contrib/lisp/org-vm.el
index 5d30f64..da242cb 100644
--- a/contrib/lisp/org-vm.el
+++ b/contrib/lisp/org-vm.el
@@ -77,12 +77,6 @@
  (message-id (vm-su-message-id message))
  (link-type (if (vm-imap-folder-p) "vm-imap" "vm"))
 (date (vm-get-header-contents message "Date"))
-(date-ts (and date (format-time-string
-(org-time-stamp-format t)
-(date-to-time date
-(date-ts-ia (and date (format-time-string
-   (org-time-stamp-format t t)
-   (date-to-time date
 folder desc link)
 (if (vm-imap-folder-p)
(let ((spec (vm-imap-find-spec-for-buffer (current-buffer
@@ -95,10 +89,7 @@
 (setq folder (replace-match "" t t folder)
 (setq message-id (org-remove-angle-brackets message-id))
(org-store-link-props :type link-type :from from :to to :subject subject
- :message-id message-id)
-   (when date
- (org-add-link-props :date date :date-timestamp date-ts
- :date-timestamp-inactive date-ts-ia))
+ :message-id message-id :date date)
(setq desc (org-email-link-description))
(setq link (concat (concat link-type ":") folder "#" message-id))
(org-add-link-props :link link :description desc)
diff --git a/contrib/lisp/org-wl.el b/contrib/lisp/org-wl.el
index 632c9e3..2cc333c 100644
--- a/contrib/lisp/org-wl.el
+++ b/contrib/lisp/org-wl.el
@@ -198,12 +198,6 @@ ENTITY is a message entity."
 (xref (org-wl-message-field 'xref wl-message-entity))
 (subject (org-wl-message-field 'subject wl-message-entity))
 (date (org-wl-message-field 'date wl-message-entity))
-(date-ts (and date (format-time-string
-(org-time-stamp-format t)
-(date-to-time date
-(date-ts-ia (and date (format-time-string
-   (org-time-stamp-format t t)
-   (date-to-time date
 desc link)
 
;; remove text properties of subject string to avoid possible bug
@@ -243,9 +237,7 @@ ENTITY is a message entity."
  (setq desc (org-email-link-description))
  (setq link (concat "wl:" folder-name "#" message-id-no-brackets))
  (org-add-link-props :link link :description desc)))
-   (when date
- (org-add-link-props :date date :date-timestamp date-ts
- :date-timestamp-inactive date-ts-ia))
+   (org-add-link-props :date date)
(or link xref)))
 
 (defun org-wl-open-nntp (path)
diff --git 

Re: [O] insert aligned table using capture template

[Nick Dokos]

Shankar Rao  writes:

> I'm trying to use to org-capture insert tables into a datetree that I use to 
> manage my finances. Below is the capture template I set up for it. Is there a 
> way to make the table be aligned
> after I finalize the capture?
>
> Shankar
>
> -
>
> (setq org-capture-templates
>        '(...
> ("f" "Add Tables" plain
> (file+datetree+prompt "~/my-table-file.org")
>  ,(concat "#+TBLNAME: accounts-%<%y%m%d>\n"
>                   "| Account | Initial | Final | Calculations |\n"
>                   "|-\n"
>                   "| Account A | | | |\n"
>                   "| Account B | | | |\n"
>                   "| Account C | | | |\n")
> :immediate-finish t
> :jump-to-captured t)
>         ...))

The ,(concat ...) stuff did not work for me: is is supposed to? I get
"invalid capture template".

Be that as it may, you can do this (maybe with more safeguards):

--8<---cut here---start->8---
(add-hook 'org-capture-prepare-finalize-hook (function my-capture-table-align))

(defun my-capture-table-align ()
  (forward-line 1) ;; skip the #+name line
  (if (org-at-table-p 'any)
  (org-table-align)))
--8<---cut here---end--->8---

--
Nick

Re: [O] bug in org-habits

[Nicolas Goaziou]

John Wiegley  writes:

> Since it scales for my use case, can I please have a customization variable to
> relax this restriction?

I'd rather not have syntax too much customizable, for portability, ease
of maintenance, too. There are already too many mistakes in that area.

Also, please note that previous behaviour didn't handle some
pathological cases (e.g., property drawer in a comment block, or past an
inlinetask). Fixing that properly, i.e. parsing the section all the way
down to the drawer, would probably have had an impact in your use case.

The current behaviour is technically much more reliable.

> I prefer PROPERTIES drawers at the end, and would prefer not to trade
> something I want for something that doesn't affect me.

If you need to end your entry with a drawer, couldn't you put any of
them there? You can even have one there named "PROPERTIES".

Regards,

[O] bug#21818: 24.5; org-set-tags-to indentation problems when called programmatically

[Eli Zaretskii]

> From: Emanuel Evans 
> Date: Tue, 03 Nov 2015 10:14:33 -0800
> 
> Eli Zaretskii  writes:
> 
> > Are you sure this isn't a problem with Org mode?  If not, can you tell
> > why you think so?
> 
> Oh, I think it could definitely be a problem with Org mode, I just
> thought this would be the right place to file a bug because it's a
> built-in package. Is there a better place to send a report?

Org mode has its own bug tracker, AFAIR.

> (I also think it's possible that it's a lower-level bug because
> `current-column' is changing behavior when using edebug, which seems
> like a bug either in `current-column' or edebug.)

If the Org developers say it's a core bug, please come back here (or
they should), with data that shows how to reproduce the problem,
ideally without Org at all.

Thanks.

P.S. Your email bounces, so sending me a private email is not very
wise...

Re: [O] bug in org-habits

[John Wiegley]

> Nicolas Goaziou  writes:

> As a matter of fact, going to the end of an entry is not negligible, because
> of inlinetasks. Also, it is not really O(1) since it depends on the size of
> the entry. To get an idea, on my computer, moving past a 500 lines entry
> takes around 0.001s. I can imagine slower computers, or larger entries,
> neither being unheard of, having a slightly noticeable delay.

I'm having a hard time buying the performance argument, since I've been using
Org-mode for many years, and never has this been a problem. You're making me
pay a cost (enforced structure), for a value only one of us perceives.

> Also, supporting both locations means that users will pay the full price in
> entries without a property drawer, even if they chose the fast path, i.e.,
> drawer at the beginning of the entry, in the first place. This kind of
> defeats some of the advantages of the current state.

It wouldn't be "users": it would be people intentionally opting to allow
floating properties. _I_ would be paying the price, and I will pay it happily
to keep 8.2 behavior.

John

Re: [O] bug in org-habits

[Nicolas Goaziou]

John Wiegley  writes:

> Thanks for discussing this with me, Nicolas. I appreciate there may be
> technical complexities involved. Could we special-case allow PROPERTIES to be
> the *very last thing* in an entry? I don't need it to float anywhere else. I
> just like it to be at the end.

I think it's a false good idea.

As a matter of fact, going to the end of an entry is not negligible,
because of inlinetasks. Also, it is not really O(1) since it depends on
the size of the entry. To get an idea, on my computer, moving past a 500
lines entry takes around 0.001s. I can imagine slower computers, or
larger entries, neither being unheard of, having a slightly noticeable
delay.

Also, supporting both locations means that users will pay the full price
in entries without a property drawer, even if they chose the fast path,
i.e., drawer at the beginning of the entry, in the first place. This
kind of defeats some of the advantages of the current state.

There is also a meaner problem. Unlike to beginning of entry, end of
entry is a moving target. Org sometimes automatically adds stuff there
(e.g., footnotes when `org-footnote-section' is nil). So do other parts
of Emacs (file local variables come to mind). Preventing insertions in
this area can be tedious, if possible at all. 

OTOH, the mechanism protecting the beginning of the entry, i.e,
`org-end-of-meta-data', is already implemented since planning lines
require it anyway.

Again, speed _was_ an issue, as testified by, e.g.,
org-use-property-inheritance's docstring. Current solution is both
robust and fast, and is well worth the high price of an incompatible
change, considering its central place in Org.

>> If you need to end your entry with a drawer, couldn't you put any of them
>> there? You can even have one there named "PROPERTIES".
>
> But it wouldn't be the true PROPERTIES, would it? Most of my entries look like
> this (and I have many thousands of them):

It wouldn't, of course. But at least you would get your "period" at the
end of the entry. It doesn't matter much if it is empty since its
contents are hidden anyway.

> ** TODO Update auto insurance cards :Home:ATTACH:
> SCHEDULED: <2016-03-11 Fri +6m>
> - State "DONE"   from "TODO"   [2015-09-11 Fri 11:28]
> - State "WAITING"from "TODO"   [2015-07-22 Wed 19:48]
> - State "DONE"   from "STARTED"[2014-12-13 Sat 15:56]
> - State "DONE"   from "TODO"   [2014-03-31 Mon 03:11]
> - State "CANCELED"   from "TODO"   [2013-12-11 Wed 19:23]
> - State "CANCELED"   from "TODO"   [2013-05-21 Tue 12:30]
> - State "DONE"   from "TODO"   [2012-05-17 Thu 22:24]
> - State "CANCELED"   from "TODO"   [2011-04-23 Sat 22:04]
> - State "TODO"   from "DONE"   [2010-10-23 Sat 21:54]
> - State "DONE"   from "TODO"   [2010-10-08 Fri 14:26]
> :PROPERTIES:
> :ID:   B1F3D3F6-9F39-4899-9AF8-93E019E7C6BB
> :CREATED:  [2010-05-08 Sat 17:34]
> :LAST_REPEAT: [2015-09-11 Fri 11:28]
> :Attachments: AutoInsuranceIdCards.pdf
> :END:

The following is not ugly either

  ** TODO Update auto insurance cards :Home:ATTACH:
  SCHEDULED: <2016-03-11 Fri +6m>
  :PROPERTIES:
  :ID:   B1F3D3F6-9F39-4899-9AF8-93E019E7C6BB
  :CREATED:  [2010-05-08 Sat 17:34]
  :LAST_REPEAT: [2015-09-11 Fri 11:28]
  :Attachments: AutoInsuranceIdCards.pdf
  :END:
  - State "DONE"   from "TODO"   [2015-09-11 Fri 11:28]
  - State "WAITING"from "TODO"   [2015-07-22 Wed 19:48]
  - State "DONE"   from "STARTED"[2014-12-13 Sat 15:56]
  - State "DONE"   from "TODO"   [2014-03-31 Mon 03:11]
  - State "CANCELED"   from "TODO"   [2013-12-11 Wed 19:23]
  - State "CANCELED"   from "TODO"   [2013-05-21 Tue 12:30]
  - State "DONE"   from "TODO"   [2012-05-17 Thu 22:24]
  - State "CANCELED"   from "TODO"   [2011-04-23 Sat 22:04]
  - State "TODO"   from "DONE"   [2010-10-23 Sat 21:54]
  - State "DONE"   from "TODO"   [2010-10-08 Fri 14:26]

even more so considering it really appears as 

  ** TODO Update auto insurance cards :Home:ATTACH:
  SCHEDULED: <2016-03-11 Fri +6m>
  :PROPERTIES:
  - State "DONE"   from "TODO"   [2015-09-11 Fri 11:28]
  - State "WAITING"from "TODO"   [2015-07-22 Wed 19:48]
  - State "DONE"   from "STARTED"[2014-12-13 Sat 15:56]
  - State "DONE"   from "TODO"   [2014-03-31 Mon 03:11]
  - State "CANCELED"   from "TODO"   [2013-12-11 Wed 19:23]
  - State "CANCELED"   from "TODO"   [2013-05-21 Tue 12:30]
  - State "DONE"   from "TODO"   [2012-05-17 Thu 22:24]
  - State "CANCELED"   from "TODO"   [2011-04-23 Sat 22:04]
  - State "TODO"   from "DONE"   [2010-10-23 Sat 21:54]
  - State "DONE"   from "TODO"   [2010-10-08 Fri 14:26]

and with a fake "THE-END" drawer

  ** TODO Update auto insurance cards :Home:ATTACH:
  SCHEDULED: 

Re: [O] bug in org-habits

[John Wiegley]

> Achim Gratz  writes:

> Well, that's precisely the thing that doesn't scale and that Nicolas wanted
> to avoid. Putting the properties at the beginning of an entry makes the
> search pretty much constant time and if you find something else at the start
> of the entry then you know there aren't any and can go on (this is pretty
> important for making sure property inheritance works correctly, among other
> things). If you could put them _anywhere_ else, you'd have to keep searching
> until you either find them or you've exhausted the span of the entry.

As a user, I'm willing to pay that cost. Also, I never have other property
drawers. If it were just doing (re-search-forward "^:PROPERTIES:$"
(end-of-entry)), then it wouldn't matter where the properties drawer was, so
long as it's understood that the search may be wrong if the user has such a
string appearing elsewhere.

John

Re: [O] bug in org-habits

[Jonathan Leech-Pepin]

On November 3, 2015 4:31:11 PM EST, Achim Gratz  wrote:
>John Wiegley writes:
>> Thanks for discussing this with me, Nicolas. I appreciate there may
>be
>> technical complexities involved. Could we special-case allow
>PROPERTIES to be
>> the *very last thing* in an entry? I don't need it to float anywhere
>else. I
>> just like it to be at the end.
>
>Well, that's precisely the thing that doesn't scale and that Nicolas
>wanted to avoid.  Putting the properties at the beginning of an entry
>makes the search pretty much constant time and if you find something
>else at the start of the entry then you know there aren't any and can
>go
>on (this is pretty important for making sure property inheritance works
>correctly, among other things).  If you could put them _anywhere_ else,
>you'd have to keep searching until you either find them or you've
>exhausted the span of the entry.

Wouldn't last item in entry scale without issues? Find end of headline (start 
of next or end of buffer) and search backwards. If first element from end is a 
property drawer you have it, otherwise you still know there is none.

Jon

>
>Regards,
>Achim.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [O] bug in org-habits

[Achim Gratz]

John Wiegley writes:
>> Jonathan Leech-Pepin  writes:
>> Wouldn't last item in entry scale without issues? Find end of headline
>> (start of next or end of buffer) and search backwards. If first element from
>> end is a property drawer you have it, otherwise you still know there is
>> none.
>
> That sounds even better than what I mentioned about re-search-forward, and
> O(1) time complexity as well.

I don't think so.  Search for end of entry can be complex in itself and
you would never know if the properties you find by looking back aren't
belonging to an entry one level down unless you scanned the whole span
again.  Also, properties can be any size and you have to search for the
beginning of the drawer.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] bug in org-habits

[Stelian Iancu]

On 03/11/15 14:46, Marco Wahl wrote:

John Wiegley  writes:


Puneeth Chaganti  writes:



Actually there has been introduced a constraint on the ordering planning
lines and property drawers in 8.3. See http://orgmode.org/Changes.html.>
This at least invalidates to use PROPERTIES before SCHEDULED afaics.



Yes, that is correct and you can use the `org-repair-property-drawers`
utility function provided to fix your org trees.


I would very much like to see this constraint removed from 8.3. I have always
preferred having SCHEDULED before PROPERTIES, as this is how all my Org files
are arranged.


Actually what you describe _is_ the expected order for the 8.3 files.


My issue is a bit different.

I have an org file with calendar appointments. I also have attachments 
to the appointments. The attachment appears in a PROPERTIES drawer.


Now if I have the timestamp (plain one) before the drawer, I cannot open 
the attachment. Pressing C-c C-a o just inserts another PROPERTIES 
drawer (with another ID) above the timestamp.


If, however, I move the timestamp after the PROPERTIES drawer, I can 
successfully open the attachment and the second drawer doesn't appear.


Also, when the second drawer appears, a new empty folder is created in 
the data directory of my org directory.


IMHO this is a bug, as at the moment I have to have the timestamp after 
the drawer.


Org version is Org-mode version 8.3.2 (release_8.3.2-253-g9b5757 @ 
/Users/si/elisp/org-mode/lisp/)

Re: [O] bug in org-habits

[Nicolas Goaziou]

Hello,

Stelian Iancu  writes:

> I have an org file with calendar appointments. I also have attachments
> to the appointments. The attachment appears in a PROPERTIES drawer.
>
> Now if I have the timestamp (plain one) before the drawer, I cannot
> open the attachment. Pressing C-c C-a o just inserts another
> PROPERTIES drawer (with another ID) above the timestamp.
>
> If, however, I move the timestamp after the PROPERTIES drawer, I can
> successfully open the attachment and the second drawer doesn't appear.
>
> Also, when the second drawer appears, a new empty folder is created in
> the data directory of my org directory.
>
> IMHO this is a bug, as at the moment I have to have the timestamp
> after the drawer.

This is not a bug. The order is HEADLINE (SCHEDULED PROPERTIES).

If you insert a timestamp between SCHEDULED and PROPERTIES, the latter
is no longer recognized as a PROPERTIES DRAWER (it becomes, in fact,
a regular drawer which happens to be named "PROPERTIES") and you lose
any information attached to it.

You can get this information back by putting the PROPERTIES drawer (the
special one) at its expected location.

Regards,

-- 
Nicolas Goaziou

Re: [O] bug in org-habits

[Marco Wahl]

John Wiegley  writes:

>> Puneeth Chaganti  writes:
>
>>> Actually there has been introduced a constraint on the ordering planning
>>> lines and property drawers in 8.3. See http://orgmode.org/Changes.html.>
>>> This at least invalidates to use PROPERTIES before SCHEDULED afaics.
>
>> Yes, that is correct and you can use the `org-repair-property-drawers`
>> utility function provided to fix your org trees.
>
> I would very much like to see this constraint removed from 8.3. I have always
> preferred having SCHEDULED before PROPERTIES, as this is how all my Org files
> are arranged.

Actually what you describe _is_ the expected order for the 8.3 files.

> In fact, this one aspect of 8.3 has kept me at 8.2. I do not understand the
> need for such an abitrary restriction.

So this constraint on the order should not hold you back to move on to
8.3.

I can report that in my personal org practice this constraint never got
in my way.  Further I can't imagine a use case when the user can benefit
of a SCHEDULE line below a property drawer, but this might be a bit
personal.

I can say nothing about the technical view of having that constraint.


Best regards,
-- 
Marco Wahl
GPG: 0x49010A040A3AE6F2

[O] Using link abbrevations for EXPORT_FILE_NAME ?

[AW]

Hi,

on orgmode 8.3.2 I've got a large org-file. Offen, I need to export a subtree 
like this:

-
* Subtree to be exported
:PROPERTIES:
:EXPORT_FILE_NAME: /PATH/TO/FOLDER/filename
:EXPORT_TITLE:
:END:

foo

-

I'd like to save the exported file in a project folder, as you can see in 
EXPORT_FILE_NAME .

It would be very helpful to use link abbrevations in EXPORT_FILE_NAME :

(setq org-link-abbrev-alist
   '(("anglisky" . "~/Path/whereever/%s")))

in .emacs and write:

-
* Subtree to be exported
:PROPERTIES:
:EXPORT_FILE_NAME: anglisky:filename
:EXPORT_TITLE:
:END:

foo

-

Possible? Feature Request?

Thank you!

Regards,

-- 
Alexander