* Timestamps in properties not exported by icalendar exporter
@ 2014-02-21 18:37 David Engster
2014-02-22 9:44 ` Nicolas Goaziou
0 siblings, 1 reply; 10+ messages in thread
From: David Engster @ 2014-02-21 18:37 UTC (permalink / raw)
To: emacs-orgmode
I have the problem that a certain kind Org entries is not exported by
the icalendar exporter, namely those created by the gnus-icalendar
package.
This package creates Org entries from calendar invites in the following
way (I've omitted some of the properties, but you get the idea);
** Some appointment (location)
:PROPERTIES:
:ICAL_EVENT: t
:ID: 040000008200E00074C5B7101A82E00800
:DT: <2013-12-09 Mon 13:00-13:30>
:END:
Body text
These entries show up in the agenda just fine, but the icalendar
exporter does not export it because the timestamp is in the properties
(the gnus-icalendar package puts it there so that you can easily change
it if the organizer decides to change the event and sends a change
request).
The exporter could of course simply take the first timestamp it finds in
the properties, but it could be the wrong one; for instance, there could
be a LOGBOOK timestamp before the one in DT. Hence I think it would be
nice if you could tell the exporter which property to use as timestamp
during export.
-David
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Timestamps in properties not exported by icalendar exporter
2014-02-21 18:37 Timestamps in properties not exported by icalendar exporter David Engster
@ 2014-02-22 9:44 ` Nicolas Goaziou
2014-02-22 10:38 ` David Engster
0 siblings, 1 reply; 10+ messages in thread
From: Nicolas Goaziou @ 2014-02-22 9:44 UTC (permalink / raw)
To: emacs-orgmode
Hello,
David Engster <deng@randomsample.de> writes:
> I have the problem that a certain kind Org entries is not exported by
> the icalendar exporter, namely those created by the gnus-icalendar
> package.
>
> This package creates Org entries from calendar invites in the following
> way (I've omitted some of the properties, but you get the idea);
>
> ** Some appointment (location)
> :PROPERTIES:
> :ICAL_EVENT: t
> :ID: 040000008200E00074C5B7101A82E00800
> :DT: <2013-12-09 Mon 13:00-13:30>
> :END:
>
> Body text
>
>
> These entries show up in the agenda just fine, but the icalendar
> exporter does not export it because the timestamp is in the properties
> (the gnus-icalendar package puts it there so that you can easily change
> it if the organizer decides to change the event and sends a change
> request).
>
> The exporter could of course simply take the first timestamp it finds in
> the properties, but it could be the wrong one; for instance, there could
> be a LOGBOOK timestamp before the one in DT. Hence I think it would be
> nice if you could tell the exporter which property to use as timestamp
> during export.
Can't you just walk the buffer and turn such properties into plain
time-stamps (or scheduled, deadline...), in a hook?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Timestamps in properties not exported by icalendar exporter
2014-02-22 9:44 ` Nicolas Goaziou
@ 2014-02-22 10:38 ` David Engster
2014-02-22 11:41 ` Nicolas Goaziou
0 siblings, 1 reply; 10+ messages in thread
From: David Engster @ 2014-02-22 10:38 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
Nicolas Goaziou writes:
> David Engster <deng@randomsample.de> writes:
>> These entries show up in the agenda just fine, but the icalendar
>> exporter does not export it because the timestamp is in the properties
>> (the gnus-icalendar package puts it there so that you can easily change
>> it if the organizer decides to change the event and sends a change
>> request).
>>
>> The exporter could of course simply take the first timestamp it finds in
>> the properties, but it could be the wrong one; for instance, there could
>> be a LOGBOOK timestamp before the one in DT. Hence I think it would be
>> nice if you could tell the exporter which property to use as timestamp
>> during export.
>
> Can't you just walk the buffer and turn such properties into plain
> time-stamps (or scheduled, deadline...), in a hook?
Yes, I could do that for my specific setup. But it would be nice if this
stuff could "just work", so that things like Outlook calendar invites
can be directly exported to .ics.
I mean, those entries show up in the agenda, so I found it rather
surprising that they are completely ignored by the exporter. I think it
would make sense if the exporter also looked for time-stamps in the
properties. Maybe it could just take the first one it finds (which I
guess is what the agenda does?), and also give the user the ability to
configure which properties to look at (or maybe an exclude option).
-David
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Timestamps in properties not exported by icalendar exporter
2014-02-22 10:38 ` David Engster
@ 2014-02-22 11:41 ` Nicolas Goaziou
2014-02-22 13:19 ` David Engster
2014-02-22 13:47 ` Nick Dokos
0 siblings, 2 replies; 10+ messages in thread
From: Nicolas Goaziou @ 2014-02-22 11:41 UTC (permalink / raw)
To: emacs-orgmode
David Engster <deng@randomsample.de> writes:
> Yes, I could do that for my specific setup. But it would be nice if this
> stuff could "just work", so that things like Outlook calendar invites
> can be directly exported to .ics.
AFAIU, we're talking about a third-party package which implements its
own UI. We cannot support every UI in the wild.
> I mean, those entries show up in the agenda, so I found it rather
> surprising that they are completely ignored by the exporter.
This is an agenda bug, which probably use a regexp to find timestamps.
But timestamps in properties are not valid Org timestamps, per Org
syntax.
> I think it would make sense if the exporter also looked for
> time-stamps in the properties.
There are already plenty of locations to use timestamps. We have
scheduled, deadline, plain timestamps... I don't think we need more of
them.
Also, a hook is easy enough to implement in this situation.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Timestamps in properties not exported by icalendar exporter
2014-02-22 11:41 ` Nicolas Goaziou
@ 2014-02-22 13:19 ` David Engster
2014-02-22 13:44 ` Nicolas Goaziou
2014-02-22 13:47 ` Nick Dokos
1 sibling, 1 reply; 10+ messages in thread
From: David Engster @ 2014-02-22 13:19 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
Nicolas Goaziou writes:
> David Engster <deng@randomsample.de> writes:
>> I mean, those entries show up in the agenda, so I found it rather
>> surprising that they are completely ignored by the exporter.
>
> This is an agenda bug, which probably use a regexp to find timestamps.
> But timestamps in properties are not valid Org timestamps, per Org
> syntax.
OK.
>> I think it would make sense if the exporter also looked for
>> time-stamps in the properties.
>
> There are already plenty of locations to use timestamps. We have
> scheduled, deadline, plain timestamps... I don't think we need more of
> them.
It's these multitude of timestamp locations which makes changing the
timestamp of an existing entry through Elisp so tedious (I had to deal
with that in org-caldav), so using a property for it seemed like a good
idea. Anyway, I understand your reasoning, and I guess we should change
how gnus-icalendar generates its Org entries.
-David
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Timestamps in properties not exported by icalendar exporter
2014-02-22 13:19 ` David Engster
@ 2014-02-22 13:44 ` Nicolas Goaziou
2014-02-22 16:12 ` David Engster
0 siblings, 1 reply; 10+ messages in thread
From: Nicolas Goaziou @ 2014-02-22 13:44 UTC (permalink / raw)
To: emacs-orgmode
David Engster <deng@randomsample.de> writes:
> It's these multitude of timestamp locations which makes changing the
> timestamp of an existing entry through Elisp so tedious (I had to deal
> with that in org-caldav)
The number of locations may be daunting but all of them make sense
actually. Also, I don't think it is really difficult to change
a timestamp through Elisp, due to specialized functions (e.g.
`org-schedule').
Anyway, if you think this area can be improved, feel free to make
suggestions.
> so using a property for it seemed like a good idea.
This has been discussed a few times on this ML already.
Carsten's argument is that new users shouldn't have to deal with hidden
data, like property drawers, for such basic features.
IMO, it also have an advantage from an implementation POV: important
timestamps are located right below the headline, whereas a property
drawer can be found anywhere in the whole section.
> Anyway, I understand your reasoning, and I guess we should change how
> gnus-icalendar generates its Org entries.
I think so, too.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Timestamps in properties not exported by icalendar exporter
2014-02-22 11:41 ` Nicolas Goaziou
2014-02-22 13:19 ` David Engster
@ 2014-02-22 13:47 ` Nick Dokos
1 sibling, 0 replies; 10+ messages in thread
From: Nick Dokos @ 2014-02-22 13:47 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> David Engster <deng@randomsample.de> writes:
>
>> Yes, I could do that for my specific setup. But it would be nice if this
>> stuff could "just work", so that things like Outlook calendar invites
>> can be directly exported to .ics.
>
> AFAIU, we're talking about a third-party package which implements its
> own UI. We cannot support every UI in the wild.
>
I was confused at first because David has (had?) his own gnus-icalendar
package, but I believe he means the gnus-icalendar that is part of
gnus. That's probably a bit more official than a third-party package in
the wild, but I appreciate Nicolas's desire to control the chaos.
It might make more sense to advertise an API/convention/whatever that
such packages can use and provide a patch to modify gnus-icalendar
accordingly. After all, I presume gnus-icalendar can only be used with
gnus, so other mailers will have to have their own icalendar->org. If
each picks its own convention, chaos reigns.
We just need to come up with the "standard" and advertise it
appropriately. Maybe something like this:
"provide the starting time/duration information as a scheduled
timestamp, and optionally provide everything in properties.
The names of the properties should be the names that gnus-icalendar
currently uses (explicitly listed out, of course)."
>> I mean, those entries show up in the agenda, so I found it rather
>> surprising that they are completely ignored by the exporter.
>
> This is an agenda bug, which probably use a regexp to find timestamps.
> But timestamps in properties are not valid Org timestamps, per Org
> syntax.
>
If gnus-icalendar is modified as above, then when the agenda is
rewritten using org-element, things are not going to break.
>> I think it would make sense if the exporter also looked for
>> time-stamps in the properties.
>
> There are already plenty of locations to use timestamps. We have
> scheduled, deadline, plain timestamps... I don't think we need more of
> them.
>
> Also, a hook is easy enough to implement in this situation.
>
--
Nick
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Timestamps in properties not exported by icalendar exporter
2014-02-22 13:44 ` Nicolas Goaziou
@ 2014-02-22 16:12 ` David Engster
2014-02-22 17:42 ` Nicolas Goaziou
0 siblings, 1 reply; 10+ messages in thread
From: David Engster @ 2014-02-22 16:12 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
Nicolas Goaziou writes:
> David Engster <deng@randomsample.de> writes:
>
>> It's these multitude of timestamp locations which makes changing the
>> timestamp of an existing entry through Elisp so tedious (I had to deal
>> with that in org-caldav)
>
> The number of locations may be daunting but all of them make sense
> actually. Also, I don't think it is really difficult to change
> a timestamp through Elisp, due to specialized functions (e.g.
> `org-schedule').
Not difficult, but tedious. The problem is that an entry might have
several timestamps, and you have to find the correct one to change.
> Anyway, if you think this area can be improved, feel free to make
> suggestions.
I'm actually not sure what org-element is capable of nowadays. What I'd
like to have is a way to parse entries into a structure which lets me
access certain elements of the entry, like headline, timestamps,
properties, body text, etc., and also a way to convert this structure
*back* to a plain Org entry. This way, I could change certain elements
of the entry in a robust way. It might be that the *appearance* of the
entry changes a bit during this procedure, but its elements should be
preserved.
(BTW: This is similar to what we have in CEDET, where the Semantic
parser generates 'tags' which describes things like variable or function
declarations, and you can define SRecode templates which can generate
textual output from these tags in pretty much any way you like.)
For example, in org-caldav I had to write a function which changes the
headline of an entry, but preserves any timestamps which might be in
it. Again: not difficult to do, especially since there is
org-complex-heading-regexp, but it's still tedious since Org entries are
so flexible in their appearance.
>> so using a property for it seemed like a good idea.
>
> This has been discussed a few times on this ML already.
>
> Carsten's argument is that new users shouldn't have to deal with hidden
> data, like property drawers, for such basic features.
Oh no, the user shouldn't have to do this, I agree
completely. Properties are nice for *code*, since they can be easily
parsed.
-David
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Timestamps in properties not exported by icalendar exporter
2014-02-22 16:12 ` David Engster
@ 2014-02-22 17:42 ` Nicolas Goaziou
2014-02-22 17:52 ` David Engster
0 siblings, 1 reply; 10+ messages in thread
From: Nicolas Goaziou @ 2014-02-22 17:42 UTC (permalink / raw)
To: emacs-orgmode
David Engster <deng@randomsample.de> writes:
> I'm actually not sure what org-element is capable of nowadays. What I'd
> like to have is a way to parse entries into a structure
See `org-element-parse-buffer'.
> which lets me access certain elements of the entry, like headline,
> timestamps, properties, body text, etc.,
See `org-element-map'.
> and also a way to convert this structure *back* to a plain Org entry.
See `org-element-interpret-data'.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Timestamps in properties not exported by icalendar exporter
2014-02-22 17:42 ` Nicolas Goaziou
@ 2014-02-22 17:52 ` David Engster
0 siblings, 0 replies; 10+ messages in thread
From: David Engster @ 2014-02-22 17:52 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
Nicolas Goaziou writes:
> David Engster <deng@randomsample.de> writes:
>
>> I'm actually not sure what org-element is capable of nowadays. What I'd
>> like to have is a way to parse entries into a structure
>
> See `org-element-parse-buffer'.
>
>> which lets me access certain elements of the entry, like headline,
>> timestamps, properties, body text, etc.,
>
> See `org-element-map'.
>
>> and also a way to convert this structure *back* to a plain Org entry.
>
> See `org-element-interpret-data'.
I had a hunch you already implemented all this. :-)
I'll look into it.
Thanks,
-David
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-02-22 17:52 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-21 18:37 Timestamps in properties not exported by icalendar exporter David Engster
2014-02-22 9:44 ` Nicolas Goaziou
2014-02-22 10:38 ` David Engster
2014-02-22 11:41 ` Nicolas Goaziou
2014-02-22 13:19 ` David Engster
2014-02-22 13:44 ` Nicolas Goaziou
2014-02-22 16:12 ` David Engster
2014-02-22 17:42 ` Nicolas Goaziou
2014-02-22 17:52 ` David Engster
2014-02-22 13:47 ` Nick Dokos
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).