Torsten Wagner | 1 Feb 01:54 2011
Picon

Re: Status google calendar sync


> So would it be possible to build a native emacs for android?

I checked this a while ago and unfortunately emacs comes with a relatively large pack of dependencies. Android on the other side does not deliver many standard libraries. Xorg libc and afaik dbus are a few dependencies which are not (natively) available on Android.
I tried Emacs in a debian chroot on my keyboard less device. It wasn't really usable and I doubt that keyboard based smartphones are much better since they most likely miss alt ctrl and other important keys.

Ideally we have something like Mobileorg and a emacs dameon running. Mobileorg could send emacs elisp code to execute and access all org-mode functions natively. This would allow to "reduce" mobileorgs task to touchfriendly input and result representation.

If I manage to port a very basic version of emacs to android I will let you know.

Greetings
Totti

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Eric S Fraga | 1 Feb 10:12 2011
X-Face
Picon
Picon

Re: Status google calendar sync

Torsten Wagner <torsten.wagner <at> gmail.com> writes:

[...]

> Ideally we have something like Mobileorg and a emacs dameon running.
> Mobileorg could send emacs elisp code to execute and access all org-mode
> functions natively. This would allow to "reduce" mobileorgs task to
> touchfriendly input and result representation.

This is actually a very appealing idea.  These devices are potentially
always connected to the network so why duplicate content?  If you have
all your org files somewhere *you* can access, a small app on the phone
which sends elisp commands (e.g., via =ssh host emacsclient elisp=) to
that remote server would be a good solution: less processing on a low
power device, less, more focused, data transfer, no issues with
synchronisation, etc.

> If I manage to port a very basic version of emacs to android I will let you
> know.

Yes, please!

--

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.4 (release_7.4.276.gada3f)

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Sven Bretfeld | 1 Feb 23:44 2011
Face
Picon
Picon

Re: Status google calendar sync

Torsten Wagner <torsten.wagner <at> gmail.com> writes:

>> So would it be possible to build a native emacs for android?
>
> I checked this a while ago and unfortunately emacs comes with a relatively large
> pack of dependencies. Android on the other side does not deliver many standard
> libraries. Xorg libc and afaik dbus are a few dependencies which are not
> (natively) available on Android.
> I tried Emacs in a debian chroot on my keyboard less device. It wasn't really
> usable and I doubt that keyboard based smartphones are much better since they
> most likely miss alt ctrl and other important keys.

There is yet another possibility. Use ConnectBot to connect to a PC
running Emacs (daemon). I use MobileOrg for task planning, todo lists
etc. But when I write a longer text, I use ConnectBot started with the
option 'emacsclient -t --eval "(ibuffer)"'. It is like having a native
Emacs on the phone. Press the icon, and Emacs is there after 3 seconds.
If you use Swype as input-method, you can even write long texts very
fast. Meta and Ctrl are available (press trackball once [CTRL] or twice
[Meta], press trackball followed by i for TAB).

Greetings,

Sven

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Torsten Wagner | 2 Feb 06:15 2011
Picon

Re: Status google calendar sync

> There is yet another possibility. Use ConnectBot to connect to a PC
> running Emacs (daemon). I use MobileOrg for task planning, todo lists
> etc. But when I write a longer text, I use ConnectBot started with the
> option 'emacsclient -t --eval "(ibuffer)"'. It is like having a native
> Emacs on the phone. Press the icon, and Emacs is there after 3 seconds.
> If you use Swype as input-method, you can even write long texts very
> fast. Meta and Ctrl are available (press trackball once [CTRL] or twice
> [Meta], press trackball followed by i for TAB).

Hi Sven,

thanks for reminding me. Yes, this is indeed a nice option I used for 
some time. At the moment, I try to get a Bluetooth Keyboard working with 
my HTC Desire and put it together with the phone into a small leather 
case which allows me to use the phone as display and the keyboard in 
front of it. The total size will be approximately the size the phone 
only the thickness is doubled. It would be something like my 
computer-on-the-go-reduced-to-the-essential-part unit. Perfect for 
business trips, checking/writing mails, writing or doing extensive 
org-mode stuff on the go.

On the other hand, I would prefer to take only the phone for daily usage 
at places where a PC is easy available (e.g., in the office). In that 
case I would prefer to use a GUI like mobileorg which allows me to 
perform very quick org-mode tasks (adding a new appointment, check my 
schedule for the next 7 days, add a todo, etc.)
Basically, mobileorg tries to do that but all the parsing, sorting and 
data manipulation stuff is done on the android phone in native Java. 
Therefore, Matthew (the main developer) is busy (I guess) by 
reimplementing org-mode functions in Java which runs perfectly fine in 
elisp already.
Thus, I wonder if an approach "in the middle" might be the best.
Using a GUI like mobileorg. Every command (button-press) is actually 
translated in a org-mode elisp call send via ssh to an emacs daemon on a 
server machine. The emacs daemon processes the request and sends the 
result back. Result get catched by the GUI and displayed in a nice easy 
understandable way specifically customized to the small screen of mobile 
phones.

This approach would have several benefits:
* Changes in org-mode would directly work on the mobile version (at 
least in a kind of raw-mode which simply shows the answer of the daemon 
as text).
* Whenever we can make emacs run locally on the phone itself it would 
only require to replace the server address by "localhost" resulting in 
an offline version.
* People could work on different machines if they need.
* Depending on the power consumption of 3G/Wifi and the data 
transmission speed, it might be less power hungry to use a server 
approach compared to a standalone version (I'm totally unsure about 
that, but often wifi is on for other reasons, in that case sending and 
receiving data to an emacs dameon would not cost additional battery at all.)

The interface to org-mode for a mobileorg-client could be created in an 
additional layer in a similar form like org-babel. Simply providing 
commands to extract or inject certain data and send/receive them in a 
way both sides can understand easily. It would not disturb the main 
development of org-mode and might even result in a general org-mode API 
for many other possible integrations with org-mode (e.g., interfacing to 
Thunderbird, Firefox, Openoffice, shell, etc.).
In some way, since we had this already mentioned during this discussion 
it would be like the Google Calendar API.

All the best

Totti

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Konrad Hinsen | 2 Feb 09:30 2011
Picon

Re: Status google calendar sync

On 2 Feb 2011, at 06:15, Torsten Wagner wrote:

> Basically, mobileorg tries to do that but all the parsing, sorting  
> and data manipulation stuff is done on the android phone in native  
> Java. Therefore, Matthew (the main developer) is busy (I guess) by  
> reimplementing org-mode functions in Java which runs perfectly fine  
> in elisp already.
> Thus, I wonder if an approach "in the middle" might be the best.
> Using a GUI like mobileorg. Every command (button-press) is actually  
> translated in a org-mode elisp call send via ssh to an emacs daemon  
> on a server machine. The emacs daemon processes the request and  
> sends the result back. Result get catched by the GUI and displayed  
> in a nice easy understandable way specifically customized to the  
> small screen of mobile phones.

How about implementing emacs-lisp for Android? More precisely, Emacs  
minus all the display stuff. Just what it takes to run Emacs in batch  
mode. Since Emacs already has very different display modes (GUI,  
terminal), it is perhaps not so difficult to extract a display-less  
version from the source code. Maybe this is just naive thinking, I  
never looked at the Emacs source code!

Konrad

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Marcelo de Moraes Serpa | 14 Feb 22:39 2011
Picon

Re: Status google calendar sync

This would be awesome, and I think this is the path the emacs
developers should take -- separating emacs into two, the GUI and the
core elisp interpreter. I'm sure this wouldn't be easy, but imagine
having emacs both as an IDE and also as a full-fledged elisp
interpreter/compiler and framework, not necessarily tied to the editor
itself, but with a framework suitable to build other kind of
IDEs/editors if needed (extracted from all those years of emacsen!).

This would allow things such as org to become more of a platform with
a server and a client. The default client would be emacs, but one
could for example run org on a server and build a web layer above it,
communicating with org using CLI/http/dbus/whatever or if one is brave
enough, write the whole thing in elisp (the web part too).

I think this would be akin to what the Eclipse platform is currently.

Food for thought...

Marcelo.

On Wed, Feb 2, 2011 at 2:30 AM, Konrad Hinsen
<konrad.hinsen <at> fastmail.net> wrote:
> On 2 Feb 2011, at 06:15, Torsten Wagner wrote:
>
>> Basically, mobileorg tries to do that but all the parsing, sorting and
>> data manipulation stuff is done on the android phone in native Java.
>> Therefore, Matthew (the main developer) is busy (I guess) by reimplementing
>> org-mode functions in Java which runs perfectly fine in elisp already.
>> Thus, I wonder if an approach "in the middle" might be the best.
>> Using a GUI like mobileorg. Every command (button-press) is actually
>> translated in a org-mode elisp call send via ssh to an emacs daemon on a
>> server machine. The emacs daemon processes the request and sends the result
>> back. Result get catched by the GUI and displayed in a nice easy
>> understandable way specifically customized to the small screen of mobile
>> phones.
>
> How about implementing emacs-lisp for Android? More precisely, Emacs minus
> all the display stuff. Just what it takes to run Emacs in batch mode. Since
> Emacs already has very different display modes (GUI, terminal), it is
> perhaps not so difficult to extract a display-less version from the source
> code. Maybe this is just naive thinking, I never looked at the Emacs source
> code!
>
> Konrad
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode <at> gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Konrad Hinsen | 15 Feb 08:18 2011
Picon

Re: Status google calendar sync

On 14 Feb 2011, at 22:39, Marcelo de Moraes Serpa wrote:

> This would be awesome, and I think this is the path the emacs
> developers should take -- separating emacs into two, the GUI and the
> core elisp interpreter. I'm sure this wouldn't be easy, but imagine

Emacs already has a batch mode, and very different GUI layers  
(terminal, X11, Mac, Windows), so I'd suspect that a "no GUI" version  
that can be compiled anywhere would not be so difficult. It may be  
more difficult to make a separate GUI layer, but that wouldn't be very  
important either from a practical point of view.

BTW, another Emacs GUI I'd like to see is a Web-based one. Imagine  
connecting to your home machine from a Web browser and getting access  
to a copy of Emacs running there!

Konrad.

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Marcelo de Moraes Serpa | 15 Feb 17:37 2011
Picon

Re: Status google calendar sync

I had just that very idea yesterday but thought it would be too crazy;
A new startup? :D

Marcelo.

On Tue, Feb 15, 2011 at 1:18 AM, Konrad Hinsen
<konrad.hinsen <at> fastmail.net> wrote:
> On 14 Feb 2011, at 22:39, Marcelo de Moraes Serpa wrote:
>
>> This would be awesome, and I think this is the path the emacs
>> developers should take -- separating emacs into two, the GUI and the
>> core elisp interpreter. I'm sure this wouldn't be easy, but imagine
>
> Emacs already has a batch mode, and very different GUI layers (terminal,
> X11, Mac, Windows), so I'd suspect that a "no GUI" version that can be
> compiled anywhere would not be so difficult. It may be more difficult to
> make a separate GUI layer, but that wouldn't be very important either from a
> practical point of view.
>
> BTW, another Emacs GUI I'd like to see is a Web-based one. Imagine
> connecting to your home machine from a Web browser and getting access to a
> copy of Emacs running there!
>
> Konrad.
>

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Marcelo de Moraes Serpa | 15 Feb 17:43 2011
Picon

Re: Status google calendar sync

Anyway, I'd like to see the development of org go towards decoupling
it from the emacs GUI and allowing the core logic to be used from
other languages; I'd say the easiest way would be to provide a
JSON-like HTTP protocol; not sure how easy/hard would it be to develop
a HTTP server and run it from the headless emacs as a daemon.

Marcelo.

On Tue, Feb 15, 2011 at 10:37 AM, Marcelo de Moraes Serpa
<celoserpa <at> gmail.com> wrote:
> I had just that very idea yesterday but thought it would be too crazy;
> A new startup? :D
>
> Marcelo.
>
>
>
> On Tue, Feb 15, 2011 at 1:18 AM, Konrad Hinsen
> <konrad.hinsen <at> fastmail.net> wrote:
>> On 14 Feb 2011, at 22:39, Marcelo de Moraes Serpa wrote:
>>
>>> This would be awesome, and I think this is the path the emacs
>>> developers should take -- separating emacs into two, the GUI and the
>>> core elisp interpreter. I'm sure this wouldn't be easy, but imagine
>>
>> Emacs already has a batch mode, and very different GUI layers (terminal,
>> X11, Mac, Windows), so I'd suspect that a "no GUI" version that can be
>> compiled anywhere would not be so difficult. It may be more difficult to
>> make a separate GUI layer, but that wouldn't be very important either from a
>> practical point of view.
>>
>> BTW, another Emacs GUI I'd like to see is a Web-based one. Imagine
>> connecting to your home machine from a Web browser and getting access to a
>> copy of Emacs running there!
>>
>> Konrad.
>>
>

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Bastien | 15 Feb 17:55 2011
Picon

Re: Status google calendar sync

Hi Marcelo,

Marcelo de Moraes Serpa <celoserpa <at> gmail.com> writes:

> Anyway, I'd like to see the development of org go towards decoupling
> it from the emacs GUI and allowing the core logic to be used from
> other languages

The "core logic" of Org is the .org format, with its own syntax.

You're free to use org files anywhere, it's not bound to Emacs.

But using Emacs is certainly the best way so far to make the best 
of this format: after all, Emacs is a text editor and org files are 
just plain text!

--

-- 
 Bastien

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode <at> gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Stephen Eglen | 10 Jun 18:58 2011
Picon
Picon

Re: Status google calendar sync

Was there any update regarding this interesting topic?  I'm keen to get
something working - what is current best practice for getting
.ics files made by org put onto google calendar, so that I can view them
on android?

Thanks, Stephen

Konrad Hinsen <konrad.hinsen <at> fastmail.net> writes:

> On 14 Feb 2011, at 22:39, Marcelo de Moraes Serpa wrote:
>
>> This would be awesome, and I think this is the path the emacs
>> developers should take -- separating emacs into two, the GUI and the
>> core elisp interpreter. I'm sure this wouldn't be easy, but imagine
>
> Emacs already has a batch mode, and very different GUI layers
> (terminal, X11, Mac, Windows), so I'd suspect that a "no GUI" version
> that can be compiled anywhere would not be so difficult. It may be
> more difficult to make a separate GUI layer, but that wouldn't be very
> important either from a practical point of view.
>
> BTW, another Emacs GUI I'd like to see is a Web-based one. Imagine
> connecting to your home machine from a Web browser and getting access
> to a copy of Emacs running there!
>
> Konrad.
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode <at> gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Arun Persaud | 10 Jun 19:04 2011

Re: Status google calendar sync

Hi

On 06/10/2011 09:58 AM, Stephen Eglen wrote:
> Was there any update regarding this interesting topic?  I'm keen to get
> something working - what is current best practice for getting
> .ics files made by org put onto google calendar, so that I can view them
> on android?
> 
> Thanks, Stephen

Have a look at:

http://orgmode.org/worg/org-tutorials/org-google-sync.html

The above works well for me, so I haven't changed anything on it
recently, but let us know in case something doesn't work for you and we
can see if we can fix it.

Arun

Stephen Eglen | 10 Jun 20:34 2011
Picon
Picon

Re: Status google calendar sync

Thank you very much Arun, this page looks great:

> http://orgmode.org/worg/org-tutorials/org-google-sync.html>

When going from org -> google, do I need to do anything about using
org-icalendar-store-UID?  I'd rather not have to populate my org files
with :ID: entries.

Stephen

Arun Persaud | 10 Jun 21:09 2011

Re: Status google calendar sync

Hi

> When going from org -> google, do I need to do anything about using
> org-icalendar-store-UID?  I'd rather not have to populate my org files
> with :ID: entries.

I don't... however, I have to admit that I don't really know that much
about .ics files and the use of UID. The setup at the moment just works
for me and the appointments I want show up in google calendar (only ones
with a start and end time). One issue I still have is that they only
show up in an extra calendar and I have to copy them by hand into my
main calendar (so that other people can see them too)... this is ok for
me, since I don't have too many entries that go from org->google, mostly
I use the other direction google->org.

So there is still lots of room for improvement ;)

Anyway, here is the relevant part from my .emacs file just in case

;;; org -> google export via .ics
(setq org-icalendar-use-UTC-date-time nil)
(setq org-icalendar-timezone "America/Los_Angeles")

(defun org-mycal-export-limit ()
  "Limit the export to items that have a date, time and a range. Also
exclude certain categories."
  (setq org-tst-regexp "<\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ...
[0-9]\\{2\\}:[0-9]\\{2\\}[^\r\n>]*?\\)>")
  (setq org-tstr-regexp (concat org-tst-regexp "--?-?" org-tst-regexp))
  (save-excursion
    ; get categories
    (setq mycategory (org-get-category))
    ; get start and end of tree
    (org-back-to-heading t)
    (setq mystart    (point))
    (org-end-of-subtree)
    (setq myend      (point))
    (goto-char mystart)
    ; search for timerange
    (setq myresult (re-search-forward org-tstr-regexp myend t))
    ; search for categories to exclude
    (setq mycatp (member mycategory org-export-exclude-category))
    ; return t if ok, nil when not ok
    (if (and myresult (not mycatp)) t nil)))

(defun org-mycal-export ()
  (let ((org-icalendar-verify-function 'org-mycal-export-limit))
    (org-export-icalendar-combine-agenda-files)))

and I export via a cron script doing

emacs --batch -l ~/.emacs  --eval '(defun ask-user-about-lock (file opp)
nil)' -f org-mycal-export

cheers
	ARUN

Philipp Haselwarter | 11 Jun 15:25 2011
Picon
Picon

Re: Status google calendar sync

Unfortunately, both the awk script and the org-export-icalendar seem to
have quite a hard time with repeating entries.
ical2org does not honor RRULE at all, the export has some very basic and
very fragile support, but anything like
<%%(org-diary-class 16 02 2011 18 05 2011 3)>
or
SCHEDULED: <2011-02-20 Sun +1w -2d>
already fails it.

I think this is an important topic, especially wrt mobile devices.
Better interoperability with other calendering systems would greatly
benefit the org user experience.

--

-- 
Philipp Haselwarter

Nick Dokos | 11 Jun 20:38 2011
Picon

Re: Status google calendar sync

Philipp Haselwarter <philipp.haselwarter <at> gmx.de> wrote:

> Unfortunately, both the awk script and the org-export-icalendar seem to
> have quite a hard time with repeating entries.
> ical2org does not honor RRULE at all, the export has some very basic and
> very fragile support, but anything like
> <%%(org-diary-class 16 02 2011 18 05 2011 3)>
> or
> SCHEDULED: <2011-02-20 Sun +1w -2d>
> already fails it.
> 
> I think this is an important topic, especially wrt mobile devices.
> Better interoperability with other calendering systems would greatly
> benefit the org user experience.
> 

I agree - I have been thinking (unfortunately mostly only thinking)
about it and it seems to me that many of the pieces are there, but there
is a non-trivial amount of work to do this and do it right:

o icalendar.el should be the basis of this, but unfortunately, it is too
  closely tied to the diary (and is incomplete or buggy in various ways).

o It should be refactored to convert between an iCalendar file and a
  generic in-memory representation of a calendar: basically an
  attributed tree where the root is the VCALENDAR element, with VEVENTs,
  VTODOs, VALARMs etc. i.e. all the other elements underneath, each
  decorated with the various parameters that apply to it. The
  representation should make it easy to do the next step.

o Converters between the generic in-memory representation and various
  other formats (diary, org) are then needed.

o The refactoring of the original icalendar.el will essentially do this
  for a diary representation.  An org converter along these lines can
  then be fairly easily written I think.

o These converters are ripe for what Kernighan and Plauger call a
  "left-corner" development approach: just bite the smallest useful
  subset and add features as needed, deliberately and carefully. Both
  the current implementation of org-icalendar and Eric F.'s awk script
  would be useful in this respect: they basically cover the basic
  functionality needed (but perhaps not completely, as Philipp points
  out).

I've been working on this along these lines, but time constraints have
made progress almost imperceptibly slow.

BTW, the reason I've become interested in this is that recently I
started being bombarded with meeting invitations generated from (what
else?) M$ Outlook. My former method of adding the invitations to my Org
appointment book by hand is just not sufficient any longer. So I have
mercilessly hacked icalendar.el to invoke an org-capture with the
details, so I can just look it over and file it quickly. At the other
end, I modify the mh-e show hook to scan the message for text/calendar
attachments and kick off the icalendar stuff. But it's not working very
well yet, the hacked icalendar implementation is ugly (think Medusa-
turns-you-to-stone-if-you-look-at-it-ugly) and there are bugs (the most
serious of which is the icalendar timezone stuff that I referred to in a
recent thread). I'm trying to fixg the bugs and am working on the
back-end usability stuff in order to survive the onslaught - but the
icalendar stuff in the middle is likely to remain unspeakably ugly in
the foreseeable future - I just have no time for it.

So if anybody is interested, I hope this is useful as a starting point.

Nick

Eric S Fraga | 15 Jun 21:00 2011
X-Face
Picon
Picon

Re: Status google calendar sync

Nick Dokos <nicholas.dokos <at> hp.com> writes:
> Philipp Haselwarter <philipp.haselwarter <at> gmx.de> wrote:

Nick & Philipp,

>> Unfortunately, both the awk script and the org-export-icalendar seem to
>> have quite a hard time with repeating entries.

Yes.  I have extended my awk script to cater for ical events that span
days which does appear to work (to some degree).  See updated version
attached.  This does not handle generic repeated events unfortunately,
but mostly because I'm not sure what the ical format for these might be
(and have been too lazy to look into it).  If you have a good example
(or set of examples) of ical calendar entries that describe repeated
events, I'm happy to work on the awk script further.

Attachment (ical2org.awk): application/x-awk, 9 KiB

[...]

> I agree - I have been thinking (unfortunately mostly only thinking)
> about it and it seems to me that many of the pieces are there, but there
> is a non-trivial amount of work to do this and do it right:
>
> o icalendar.el should be the basis of this, but unfortunately, it is too
>   closely tied to the diary (and is incomplete or buggy in various
> ways).

it would indeed be nice to have an Emacs solution to the google -> org
step.

[...]

> o These converters are ripe for what Kernighan and Plauger call a
>   "left-corner" development approach: just bite the smallest useful
>   subset and add features as needed, deliberately and carefully. Both
>   the current implementation of org-icalendar and Eric F.'s awk script
>   would be useful in this respect: they basically cover the basic
>   functionality needed (but perhaps not completely, as Philipp points
>   out).

In some sense, this is indeed my modus operandum but it's not
necessarily the best approach after a while...

> BTW, the reason I've become interested in this is that recently I
> started being bombarded with meeting invitations generated from (what
> else?) M$ Outlook. My former method of adding the invitations to my
> Org

yes, I am seeing the same thing; I would love to have an automated or
semi-automated procedure to take these things in gnus and create a
capture event.  I look forward to seeing what you have been up to in
this respect!

[...]

> turns-you-to-stone-if-you-look-at-it-ugly) and there are bugs (the most
> serious of which is the icalendar timezone stuff that I referred to in a
> recent thread). I'm trying to fixg the bugs and am working on the
> back-end usability stuff in order to survive the onslaught - but the
> icalendar stuff in the middle is likely to remain unspeakably ugly in
> the foreseeable future - I just have no time for it.

time zones are a nightmare, especially with respect to Google.

> So if anybody is interested, I hope this is useful as a starting
> point.

Very interested and happy to contribute as much as I can!

--

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.391.gfaccb.dirty)
Niels Giesen | 11 Jun 19:32 2011
Picon

Re: Status google calendar sync

> When going from org -> google, do I need to do anything about using
> org-icalendar-store-UID?  I'd rather not have to populate my org files
> with :ID: entries.

You do not strictly need to, but this is the only way you do not
create double events when exporting an org file to .ics and importing
it into google calendar. If you do use them, a change in a date in
org-mode will be reflected as such in google calendar.

Note that if you /do/ want to store uids for the reason I just wrote,
/and/ if you use diary sexps, you'll need an up-to-date Emacs (from
bazaar) and below patch to org-icalendar.el (this has not been applied
yet to org-mode, alas). Otherwise icalendar.el creates a new uid every
time you export anyway.

--- a/lisp/org-icalendar.el
+++ b/lisp/org-icalendar.el
 <at>  <at>  -412,7 +412,10  <at>  <at>  When COMBINE is non nil, add the category to each line."
 	  (if scheduledp (setq summary (concat "S: " summary)))
 	  (if (string-match "\\`<%%" ts)
 	      (with-current-buffer sexp-buffer
-		(insert (substring ts 1 -1) " " summary "\n"))
+		(let ((entry (substring ts 1 -1)))
+		  (put-text-property 0 1 'uid
+				     (concat " " prefix uid) entry)
+		  (insert entry " " summary "\n")))
 	    (princ (format "BEGIN:VEVENT
 UID: %s
 %s

--

-- 
http://pft.github.com

Bastien | 30 Jun 18:14 2011

Re: Status google calendar sync

Niels Giesen <niels.giesen <at> gmail.com> writes:

> --- a/lisp/org-icalendar.el
> +++ b/lisp/org-icalendar.el
>  <at>  <at>  -412,7 +412,10  <at>  <at>  When COMBINE is non nil, add the category to each line."
>  	  (if scheduledp (setq summary (concat "S: " summary)))
>  	  (if (string-match "\\`<%%" ts)
>  	      (with-current-buffer sexp-buffer
> -		(insert (substring ts 1 -1) " " summary "\n"))
> +		(let ((entry (substring ts 1 -1)))
> +		  (put-text-property 0 1 'uid
> +				     (concat " " prefix uid) entry)
> +		  (insert entry " " summary "\n")))
>  	    (princ (format "BEGIN:VEVENT
>  UID: %s
>  %s

(Note that this has been applied.)

--

-- 
 Bastien

Eric S Fraga | 15 Jun 20:45 2011
X-Face
Picon
Picon

Re: Status google calendar sync

Stephen Eglen <S.J.Eglen <at> damtp.cam.ac.uk> writes:

> Thank you very much Arun, this page looks great:
>
>> http://orgmode.org/worg/org-tutorials/org-google-sync.html>
>
> When going from org -> google, do I need to do anything about using
> org-icalendar-store-UID?  I'd rather not have to populate my org files
> with :ID: entries.
>
> Stephen

The UID entries are necessary if you intend to upload a file that
contains entries that you previously uploaded.  Without these, any
pre-existing entry will be duplicated in google's calendar.
--

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.391.gfaccb.dirty)


Gmane