Hi,
Agreed ... I believe the only problem will occur when one of a multiply
occurring event is edited / deleted on the cal side. I have nothing more
constructive to propose than just "don't do that" ... My use-case is just as a
way to push org changes to cal and nothing more, and for bidirectio
Vincent Beffara writes:
> In the meantime I also tweaked the way org-caldav manages UIDs to
> exploit the fact that multiply occurring events are now exported
> multiple times in ox-icalendar, everything works out well if only
> org->ical is used. One thing remaining, on ical->org sync, there is an
Hi,
Yes, I had the very same problem, I had to restart org-caldav from scratch a
few times (org-caldav-delete-everything, wait a bit for caches to empty, and
then eventually it worked).
In the meantime I also tweaked the way org-caldav manages UIDs to exploit the
fact that multiply occurring
Vincent Beffara writes:
> ... sorry for replying to myself like this - here is a patch that seems to
> work:
I'm still running into problems even with this patch, but I'm not very
sure where they lie. Basically I get some messages about duplicate
entries, no org-caldav-results buffer pops up
... sorry for replying to myself like this - here is a patch that seems to
work:
diff --git a/org-caldav.el b/org-caldav.el
index 0383366..14cca8f 100644
--- a/org-caldav.el
+++ b/org-caldav.el
@@ -786,7 +786,7 @@ is no UID to rewrite. Returns the UID."
((re-search-forward "^UID:\\(orgsexp-[0-9
> OTOH when I ran org-caldav, it removed everything from the online calendar,
> and it won't put anything back there ...
Mmmkay, something weird is happening. I create a headline with a date, and call
org-caldav. An UID is created, and the file looks like this:
*** Gayet, Damien : Une majoratio
It doesn't crash anymore, thanks!
OTOH when I ran org-caldav, it removed everything from the online calendar, and
it won't put anything back there ...
--
Vincent Beffara
On Thursday, March 7, 2013 at 13:56 , Nicolas Goaziou wrote:
> Vincent Beffara mailto:vbeff...@ens-lyon.fr)> writes:
>
>
Vincent Beffara writes:
> Here is an ECM.el file, run with emacs -Q triggers the crash:
>
> (custom-set-variables
> '(org-icalendar-store-UID t)
> )
> (setq-default debug-on-error t)
> (add-to-list 'load-path "~/.emacs.d/el-get/org-mode/lisp")
> (require 'ox-icalendar)
> (org-icalendar--combine-
Here is an ECM.el file, run with emacs -Q triggers the crash:
(custom-set-variables
'(org-icalendar-store-UID t)
)
(setq-default debug-on-error t)
(add-to-list 'load-path "~/.emacs.d/el-get/org-mode/lisp")
(require 'ox-icalendar)
(org-icalendar--combine-files nil "~/Desktop/ECM.org")
without or
Hello,
Vincent Beffara writes:
> Same here. But the error is not in org-caldav, because it is triggered like
> this:
>
> (org-icalendar--combine-files nil "~/Desktop/ECM.org")
>
> where ~/Desktop/ECM.org is a file with nothing but one headline.
I cannot reproduce it. Maybe a larger backtrace w
Hi,
Same here. But the error is not in org-caldav, because it is triggered like
this:
(org-icalendar--combine-files nil "~/Desktop/ECM.org")
where ~/Desktop/ECM.org is a file with nothing but one headline.
/v
--
Vincent Beffara
On Thursday, March 7, 2013 at 10:13 , Julien Cubizolles wrot
David Engster writes:
> Thanks. I've now pushed a further fix which should hopefully make things
> work with the new exporter. Julien, please let me know if it works.
Sorry, it doesn't.
I get the following when running org-caldav with the latest org-mode and
org-caldav from git.
--8<-
Nicolas Goaziou writes:
> David Engster writes:
>
>> After skimming through the new exporter, it also seems that
>> org-combined-agenda-icalendar-file was replaced with
>> org-icalendar-combined-agenda-file. Is that correct?
>>
>> I'm also using org-icalendar-timezone, org-icalendar-store-UID, and
David Engster writes:
> After skimming through the new exporter, it also seems that
> org-combined-agenda-icalendar-file was replaced with
> org-icalendar-combined-agenda-file. Is that correct?
>
> I'm also using org-icalendar-timezone, org-icalendar-store-UID, and
> org-icalendar-date-time-forma
Julien Cubizolles writes:
> David Engster writes:
>> No, it's not defined in ox-icalendar. I guess it must be generated by
>> the new exporter first, probably through some additional require.
>
> I have the following definition in ox-icalendar.el.
>
> (defgroup org-export-icalendar nil
> "Optio
Nicolas Goaziou writes:
> David Engster writes:
>
>>> What do you need from org-icalendar.el?
>>
>> Only org-export-icalendar. As long as that one is producing the same
>> output, everything should be fine.
>
> Unfortunately, there is no `org-export-icalendar' anymore.
>
> There is:
>
> (org-ica
David Engster writes:
> Julien Cubizolles writes:
>> David Engster writes:
>>> I just pushed a change which should fix this (if the new exporter is
>>> compatible;
>>
>> It doesn't seem to be, I get
>>
>> apply: Symbol's function definition is void: org-export-icalendar
>>
>> when running org-
David Engster writes:
>> What do you need from org-icalendar.el?
>
> Only org-export-icalendar. As long as that one is producing the same
> output, everything should be fine.
Unfortunately, there is no `org-export-icalendar' anymore.
There is:
(org-icalendar--combine-files nil FILES)
which
Julien Cubizolles writes:
> David Engster writes:
>> I just pushed a change which should fix this (if the new exporter is
>> compatible;
>
> It doesn't seem to be, I get
>
> apply: Symbol's function definition is void: org-export-icalendar
>
> when running org-caldav-sync, which is weird since o
David Engster writes:
> I just pushed a change which should fix this (if the new exporter is
> compatible;
It doesn't seem to be, I get
--8<---cut here---start->8---
apply: Symbol's function definition is void: org-export-icalendar
--8<---cut h
Nicolas Goaziou writes:
> Hello,
>
> David Engster writes:
>
>> Julien Cubizolles writes:
>>> Bastien writes:
>>>
Achim Gratz writes:
> I hope to put this together in the next week or
> so, then it will be possible to nuke all traces fr4om an old Org and
> then start from a
Hello,
David Engster writes:
> Julien Cubizolles writes:
>> Bastien writes:
>>
>>> Achim Gratz writes:
>>>
I hope to put this together in the next week or
so, then it will be possible to nuke all traces fr4om an old Org and
then start from a clean slate with a new Org installati
Julien Cubizolles writes:
> Bastien writes:
>
>> Achim Gratz writes:
>>
>>> I hope to put this together in the next week or
>>> so, then it will be possible to nuke all traces fr4om an old Org and
>>> then start from a clean slate with a new Org installation.
>>
>> Okay, thanks. Let us know how
Bastien writes:
> Achim Gratz writes:
>
>> I hope to put this together in the next week or
>> so, then it will be possible to nuke all traces fr4om an old Org and
>> then start from a clean slate with a new Org installation.
>
> Okay, thanks. Let us know how it goes,
What temporary (as in ever
Hi David,
Well it would be a temporary solution for two reasons.
1. New emacs releases would come with the new org-files.
2. All third-party code might by time move to the new files.
Thus, I thought this is a (maybe on a long perspective) temporary solution.
Other non-unix like OSes:
In that case
Torsten Wagner writes:
> I didn't follow this thread in detail. But shouldn't it be enough to symlink
> e.g. org-icalendar against ox-icalendar. As far as I understood emacs would
> prioritize those local symlinks over the system wide installation. This would
> be a temporary solution until a new e
Hi Bastien,
I didn't follow this thread in detail. But shouldn't it be enough to symlink
e.g. org-icalendar against ox-icalendar. As far as I understood emacs would
prioritize those local symlinks over the system wide installation. This would
be a temporary solution until a new emacs release
Achim Gratz writes:
> I hope to put this together in the next week or
> so, then it will be possible to nuke all traces fr4om an old Org and
> then start from a clean slate with a new Org installation.
Okay, thanks. Let us know how it goes,
--
Bastien
Bastien writes:
> It seems the ox- prefix is a bad idea, you're right.
> I'll think about it again.
Please, no. The prefix is good, you would just need to obsolete all
previously exported interfaces (autoloads and defcustoms) to this code
to either give a warning or silently "do the right thing"
Hi David,
David Engster writes:
> Did you actually try that? How should Emacs possibly know that the file
> ox-icalendar provides the feature org-icalendar? This will only work if
> ox-icalendar is already loaded.
Of course, you're right. I reverted the commit.
So the problems stay. For thir
Bastien writes:
> Hi David,
>
> David Engster writes:
>
>> (eval-after-load "org-icalendar"
>> '(error "The old org-icalendar exporter is deprecated; use
>> ox-icalendar instead."))
>
> I'm not sure about this one: where are you suggesting to add this?
> In org.el?
Your call. Anywhere where it'
Bastien writes:
> Hi David,
>
> David Engster writes:
>
>> The most serious issue is that things will often seem to work because
>> old exporters are pulled in from Emacs, possibly *very* old
>> exporters.
>
> I've added (provide 'org-icalendar) to ox-icalendar.el so that
> a user will load the co
Hi David,
David Engster writes:
> (eval-after-load "org-icalendar"
> '(error "The old org-icalendar exporter is deprecated; use ox-icalendar
> instead."))
I'm not sure about this one: where are you suggesting to add this?
In org.el? Will the users get the warning if org-icalendar.el has
bee
Hi David,
David Engster writes:
> The most serious issue is that things will often seem to work because
> old exporters are pulled in from Emacs, possibly *very* old
> exporters.
I've added (provide 'org-icalendar) to ox-icalendar.el so that
a user will load the correct file instead of the old
David Engster writes:
> You mean this cus-load thingie? CEDET is actually excluded from that, so
> we don't have to deal with it. But wouldn't it be enough to remove all
> properties beginning with 'org-' from custom-loads?
First you have to find all symbols, then remove the property and then
ther
Achim Gratz writes:
> David Engster writes:
>> An alternative would be to remove the bundled Org from load-path when a
>> newer version is loaded. We do that with CEDET, but it is difficult to
>> do right (because of autoloading, for instance), so I think the
>> eval-after-load hack is better.
>
>
David Engster writes:
> An alternative would be to remove the bundled Org from load-path when a
> newer version is loaded. We do that with CEDET, but it is difficult to
> do right (because of autoloading, for instance), so I think the
> eval-after-load hack is better.
That part is actually relativ
Bastien writes:
> David Engster writes:
>
>> Of course I can fix this. But I hope you realize that any third-party
>> code out there that requires an exporter will load the old one from
>> Emacs proper.
>
> Yes, I'm well aware of this. The change now lives in the master
> branch, and will happen
Hi David,
David Engster writes:
> Of course I can fix this. But I hope you realize that any third-party
> code out there that requires an exporter will load the old one from
> Emacs proper.
Yes, I'm well aware of this. The change now lives in the master
branch, and will happen when we release
Bastien writes:
> Hi David,
>
> David Engster writes:
>
>> org-caldav does not call this function. It however requires
>> org-icalendar, and that was renamed to ox-icalendar in org git. So I
>> guess it pulls org-icalendar from the Org that is included with Emacs,
>> which calls the obsoleted func
Hi David,
David Engster writes:
> org-caldav does not call this function. It however requires
> org-icalendar, and that was renamed to ox-icalendar in org git. So I
> guess it pulls org-icalendar from the Org that is included with Emacs,
> which calls the obsoleted function.
Can you fix this by
Bastien writes:
> Hi Julien,
>
> Julien Cubizolles writes:
>
>> As of today, org-cadav-syn fails with
>>
>> org-export-icalendar: Symbol's function definition is void:
>> org-prepare-agenda-buffers
>>
>> Actually, I can't find this function but org-agenda-prepare-buffers
>> exist. Are there two di
Hi Julien,
Julien Cubizolles writes:
> As of today, org-cadav-syn fails with
>
> org-export-icalendar: Symbol's function definition is void:
> org-prepare-agenda-buffers
>
> Actually, I can't find this function but org-agenda-prepare-buffers
> exist. Are there two different functions or is ther
As of today, org-cadav-syn fails with
--8<---cut here---start->8---
org-export-icalendar: Symbol's function definition is void:
org-prepare-agenda-buffers
--8<---cut here---end--->8---
Actually, I can't find this function bu
44 matches
Mail list logo
