Re: [O] Sexp aganda entries broken?
Simon Thum writes: > Sure. I'd appreciate if the new icalendar exporter would handle these > entries (in particular org-contacts ones) - I didn't yet get it to > export agendas. Is it possible to do that? There's support for it (see `org-e-icalendar-include-sexps'). Internally it uses the function `org-diary-to-ical-string', but, last time I tried, this function wasn't able to return anything but the empty string. YMMV. Regards, -- Nicolas Goaziou
Re: [O] Sexp aganda entries broken?
On 11/12/2012 09:31 PM, Nicolas Goaziou wrote: Simon Thum writes: I see, it just seemed to me that org-contacts uses it for (seemingly) good reasons and there is no replacement or deprecation. Is there missing consensus on this syntax? I don't think so. AFAIU this syntax was created to include diary entries without the overhead of generating the diary first. There are not meant to be used as a replacement for timestamps. Sure. I'd appreciate if the new icalendar exporter would handle these entries (in particular org-contacts ones) - I didn't yet get it to export agendas. Is it possible to do that? Cheers, Simon Regards,
Re: [O] Sexp aganda entries broken?
Simon Thum writes: > I see, it just seemed to me that org-contacts uses it for (seemingly) > good reasons and there is no replacement or deprecation. Is there > missing consensus on this syntax? I don't think so. AFAIU this syntax was created to include diary entries without the overhead of generating the diary first. There are not meant to be used as a replacement for timestamps. Regards, -- Nicolas Goaziou
Re: [O] Sexp aganda entries broken?
On 11/10/2012 05:24 PM, Nicolas Goaziou wrote: Simon Thum writes: I know that, but I deemed it useful to document it as a related but separate mechanism on its own merit. Perhaps there could be a link to 10.3.1 to make it clear that the notations differ in important ways? Since %%(...) syntax isn't a timestamp /per se/, there is no reason to refer to it in the timestamps part of the manual. Also, despite its own merit, it's an antiquated[fn:1] and irregular syntax, which doesn't deserve much publicity. It won't disappear, but it's better to circumvent its uses. I see, it just seemed to me that org-contacts uses it for (seemingly) good reasons and there is no replacement or deprecation. Is there missing consensus on this syntax? Cheers, Simon Regards, [fn:1] Even the example given in "Calendar/Diary integration" section is outdated, as it relies on CATEGORY keyword to change category on the fly within the same section (see footnote in 10.4.1).
Re: [O] Sexp aganda entries broken?
Simon Thum writes: > I know that, but I deemed it useful to document it as a related but > separate mechanism on its own merit. Perhaps there could be a link to > 10.3.1 to make it clear that the notations differ in important ways? Since %%(...) syntax isn't a timestamp /per se/, there is no reason to refer to it in the timestamps part of the manual. Also, despite its own merit, it's an antiquated[fn:1] and irregular syntax, which doesn't deserve much publicity. It won't disappear, but it's better to circumvent its uses. Regards, [fn:1] Even the example given in "Calendar/Diary integration" section is outdated, as it relies on CATEGORY keyword to change category on the fly within the same section (see footnote in 10.4.1). -- Nicolas Goaziou
Re: [O] Sexp aganda entries broken?
On 11/10/2012 11:31 AM, Nicolas Goaziou wrote: Hello, Simon Thum writes: To prevent further breakage, I am attaching a doc fix. I hope it is useable? This is already documented in section 10.3.1 (Calendar/Diary integration) of the manual. I don't think it's useful to drop another note there. I know that, but I deemed it useful to document it as a related but separate mechanism on its own merit. Perhaps there could be a link to 10.3.1 to make it clear that the notations differ in important ways? Cheers, Simon Thanks for your patch, though. Regards,
Re: [O] Sexp aganda entries broken?
Hello, Simon Thum writes: > To prevent further breakage, I am attaching a doc fix. I hope it is > useable? This is already documented in section 10.3.1 (Calendar/Diary integration) of the manual. I don't think it's useful to drop another note there. Thanks for your patch, though. Regards, -- Nicolas Goaziou
Re: [O] Sexp aganda entries broken?
Sorry, I was being dumb. All fine. To prevent further breakage, I am attaching a doc fix. I hope it is useable? Cheers, Simon On 11/06/2012 11:21 PM, Simon Thum wrote: Dear all, I have a sexp entry that somehow works "less good" now. It's ** 11:00 Monthly PTB Telco %%(org-float t 2 3) (some more stuff) The agenda reads "SEXP entry returned empty string", whereas previously I got the headline. Putting something behind the sexp get me that, but the time is not recovered. I think this matches the example in the manual quite closely, so probably it's a bug. Any ideas? I'm on the current git but I don't update too regularly and it was broken before. Cheers, Simon >From 247c3fdde300be13d20e591ca5f217ad0385de49 Mon Sep 17 00:00:00 2001 From: Simon Thum Date: Sun, 26 Aug 2012 19:37:44 +0200 Subject: [PATCH] document another sexp timestamp syntax TINYCHANGE --- doc/org.texi |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/doc/org.texi b/doc/org.texi index bf67876..30c1ce4 100644 --- a/doc/org.texi +++ b/doc/org.texi @@ -5571,6 +5571,15 @@ example with optional time <%%(org-float t 4 2)> @end example +A similar syntax that is different in terms of agenda results is + +@example +* Wife +%%(org-anniversary 2001 05 07) Wedding day (%d Years) +@end example + +Here, ``Wedding day (n Years)'' will show up in the agenda (if the headline matches). It is important that there is no leading space. + @item Time/Date range @cindex timerange @cindex date range -- 1.7.8.6
[O] Sexp aganda entries broken?
Dear all, I have a sexp entry that somehow works "less good" now. It's ** 11:00 Monthly PTB Telco %%(org-float t 2 3) (some more stuff) The agenda reads "SEXP entry returned empty string", whereas previously I got the headline. Putting something behind the sexp get me that, but the time is not recovered. I think this matches the example in the manual quite closely, so probably it's a bug. Any ideas? I'm on the current git but I don't update too regularly and it was broken before. Cheers, Simon