[EMAIL PROTECTED] writes:
> Bastien <[EMAIL PROTECTED]> writes:
>
>> which might be added to Org[1] so that an .org file can be exported in
>> .ics and so that this .ics resource can be useful as a shared resource
>> for collaboration. You can already use it like this (i do), but maybe
>> some ot
Bastien <[EMAIL PROTECTED]> writes:
> which might be added to Org[1] so that an .org file can be exported in
> .ics and so that this .ics resource can be useful as a shared resource
> for collaboration. You can already use it like this (i do), but maybe
> some other keywords (like the two above)
[EMAIL PROTECTED] writes:
> Hmmm this idea just hit me : How about using ICS files ?
Yes, you can digg its specs here:
http://www.ietf.org/rfc/rfc2445.txt
Then you'll see things like:
ORGANIZER:MAILTO:[EMAIL PROTECTED]
ATTENDEE:MAILTO:[EMAIL PROTECTED]
which might be added to Org[1] so
Bastien <[EMAIL PROTECTED]> writes:
>
> Before we go further into this discussion, let me raise again a concern
> that many in this list expressed before me: Org should stick to the Unix
> coding principle, i.e. « do one thing and do it well. » Org-mode handles
> to-do lists, and it does it well.
[EMAIL PROTECTED] writes:
> I think this what I had in mind, so an emacs addict like me can work
> with other people without them having to learn emacs/org. So a web
> interface to this would ROCK !
I think the easiest way would be to have a database standing between the
Org file(s) and the web i
Bastien <[EMAIL PROTECTED]> writes:
> 3. The third idea is to let a web interface directly operate changes on
>underlying Org files. I think this is achievable: Org files are text,
>but with a reasonable set of conventions to format them we could edit
>them through another tool.
>
