Edward John Steere writes:
> - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then
>released; CEDET is at
> - we update a registry somewhere indicating that Emacs 22.0 works with
> and 22.1 works with
>
> - When we make updates to CEDET we mark 22.1 as working with
Edward John Steere writes:
>> It's not like packages communicate with Emacs over a well
>> defined RESTful interface. In other words: CEDET and Gnus are not
>> loosely coupled, quite the opposite: they are extremely dependend on
>> many obscure Emacs internals (not sure about Org).
>
> Shouldn't we
John Wiegley writes:
> Many software projects have package ecosystems surrounding them that deal with
> similar issues, and I can't, off-hand, think of cases where the answer was
> "let's move some of those packages into core development to ease
> ___".
Just from the software I worked with over th
John Wiegley writes:
>>>>>> "DE" == David Engster writes:
>
> DE> So if you don't get convinced, we'll just move again, right? No big deal.
>
> I suppose I'm asking that of you, yes.
Sorry, but I rather wait.
> DE> You are insinua
Eli Zaretskii writes:
>> From: David Engster
>> Cc: Lars Ingebrigtsen , b...@gnu.org,
>> emacs-de...@gnu.org, phillip.l...@russet.org.uk,
>
>> which implies that they are not supposed to be present at a "normal"
>> checkout.
>
> I don't s
Eli Zaretskii writes:
>> From: Lars Ingebrigtsen
>> Date: Thu, 02 Feb 2017 13:10:07 +0100
>> Cc: Bastien Guerry , Emacs developers ,
>
>> Phillip Lord ,
>> emacs-org list ,
>> Kaushal Modi
>>
>> If Django had traditionally always been distributed along with Python,
>> and maintain
John Wiegley writes:
>>>>>> "DE" == David Engster writes:
>
> DE> Also, I currently have no idea how to continue with CEDET, as the future
> DE> where development should happen is unclear, and I get the feeling we're
> DE> just waisting o
John Wiegley writes:
>>>>>> "DE" == David Engster writes:
>
> DE> It is a mistake because you are creating more moving targets and bring
> DE> them together very late in the release process. This reduces the amount of
> DE> testing that is done
Lars Ingebrigtsen writes:
> The question is: What is the most effective way for Emacs developers to
> spend their time? I can't really see that anybody has made the case
> that shifting stuff from Emacs core to ELPA will mean less work for...
> well, anybody.
>
> (Except perhaps CEDET. There seem
John Wiegley writes:
>>>>>> "DE" == David Engster writes:
>
> DE> This is a misunderstanding. I said I wanted to move support for certain
> DE> languages and project types into ELPA, not CEDET core. I'm still of the
> DE> opinion that moving
John Wiegley writes:
>> "KM" == Kaushal Modi writes:
>
> KM> If we are able the release the new packaging method in emacs 26.x, then we
> KM> can remove org from emacs master completely, but if not, then at least as
> KM> backup we have a newer org version to go out with that release.
>
> For
FYI:
I've updated the emacs-git master on the Buildbot and now
'test-ob/process-params-no-duplicates' is failing:
http://randomsample.de/org-buildbot
I've also added a new builder 'emacs-25.1' which is the current emacs-25
branch.
-David
Bastien writes:
> Emacs 23 and XEmacs support will be officially dropped as of Org 9.0.
Support for XEmacs should be dropped right away; it would just state a
fact, as Org didn't even compile with XEmacs for quite some time now
(and nobody complained).
> I recognize having the manpower to watch a
Nick Dokos writes:
> Rasmus writes:
>
>> Nick Dokos writes:
>>
>>> I just updated to release_8.3beta-1286-g20795fd.
>>>
>>> ``make test'' shows a failure on test 226:
>>>FAILED 226/592 test-org-clock/clocktable-until-now
>>>
>>>
>>> The backtrace was edited to get rid of a NUL that gnus com
Peter Davis writes:
> On 5/25/15 10:44 AM, David Engster wrote:
>> Peter Davis writes:
>>> #+BEGIN_SRC Javascript
>> Don't capitalize, use 'javascript'.
> Thanks, David.
>
> That doesn't appear to make any difference. Neither does "js"
Peter Davis writes:
> #+BEGIN_SRC Javascript
Don't capitalize, use 'javascript'.
-David
Detlef Steuer writes:
> Am Sun, 16 Nov 2014 22:53:11 +0100
> schrieb David Engster :
>
>> Detlef Steuer writes:
>> > org-check-agenda-file: Wrong type argument: stringp, nil
>>
>> Do M-x toggle-debug-on-error before the sync and you should get a
>> backtr
Detlef Steuer writes:
> org-check-agenda-file: Wrong type argument: stringp, nil
Do M-x toggle-debug-on-error before the sync and you should get a
backtrace for the error. Just post that here and we might be able to see
what's going on.
-David
Marvin M. Doyley writes:
> Is there a way to sync org-agenda with google calendar so that I can
> exploit googles calendar reminder.
org-caldav[1] works with Google Calendar on the old, deprecated CalDAV
endpoint (https://www.google.com/calendar/dav). I hear that the endpoint
is still working for
Eric S. Fraga writes:
> On Tuesday, 3 Jun 2014 at 21:54, David Engster wrote:
>
> [...]
>
>> Well, that took a bit longer, but I pushed it now...
>>
>> -David
>
> Well, the good news is that you have indeed fixed the problem I noted
> about IDs on more
David Engster writes:
> Nicolas Goaziou writes:
>> Eric S Fraga writes:
>>> I have tracked this down to org-icalendar outputing wrapped lines even
>>> for UID entries:
>>>
>>> ,
>>> | BEGIN:VEVENT
>>> | DTSTAMP:20140507T114443Z
Nicolas Goaziou writes:
> Hello,
>
> Eric S Fraga writes:
>
>> I have tracked this down to org-icalendar outputing wrapped lines even
>> for UID entries:
>>
>> ,
>> | BEGIN:VEVENT
>> | DTSTAMP:20140507T114443Z
>> | UID:0400[...]00
>> | 00[...]6
>> | DTSTART;TZID=Europe/London:20120403T06
Nicolas Goaziou writes:
> David Engster 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 acc
Nicolas Goaziou writes:
> David Engster 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
Nicolas Goaziou writes:
> David Engster 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 timestam
Nicolas Goaziou writes:
> David Engster 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
>>
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 appoin
Jambunathan K. writes:
> David Engster writes:
>
>> This is not a playground for your ego trips.
>
> Or Eli Zaretskii's. That's precisely my point.
Nobody cares for your "points" if you're pulling stunts like closing all
bugs you've opened. I for one am done talking to you.
-David
Jambunathan K. writes:
> It was rude of you to close the bug of which you nothing about.
It was rude of you to close all your existing bugs. Did it cross your
mind that maybe people already started working on those? This is not
a playground for your ego trips.
-David
Jason Riedy writes:
> Google has deprecated the URL in org-caldav, and that old URL
> does not work for me. The new one is documented at
>
> https://developers.google.com/google-apps/calendar/caldav/v2/guide#new_endpoint
>
> Fiddling with the regexp in org-caldav-events-url triggers an
> error
Suvayu Ali writes:
> That said, I think you might be right. Possibly it could be resolved by
> just changing the algorithm, I don't know why I never tried that though.
You might want to try setting diff.algorithm to 'patience' and maybe
also raise diff.context to something like 6 or so if that do
Suvayu Ali writes:
> I have noticed that git *always* conflicts with TODO state changes. It
> seems changes to a headline is not easy to resolve.
You mean you change state in a file and git fails to merge this on the
other side, although you didn't change the same line there? I've never
seen such
Achim Gratz writes:
> Peter Münster writes:
>>> cl-lib was just introduced in Emacs 24.3.
>>
>> Does that mean, that the trunk should be modified later?
>
> It means you should implement a solution that doesn't make Org
> non-functional for Emacs 23 users.
The easiest solution is to simply do noth
Peter Münster writes:
> * contrib/lisp/org-notify.el (org-notify-make-todo)
> (org-notify-process, org-notify-on-action-button)
> (org-notify-action-email, org-notify-action-window): Replace `flet'
> and `macrolet' by `cl-flet' and `cl-macrolet'.
cl-lib was just introduced in Emacs 24.3.
-David
David Engster writes:
> Google has announced today that they will shut down their CalDAV API in
> September, since hey, everybody's using their own protocol anyway.
Well, Google has suddenly realized that not only is CalDAV an open
standard, but it's actually used outside the
Vincent Beffara writes:
> I am using o-blog for that, it is pretty great.
Thanks, that looks pretty nice. I'll take a look.
>> Thing of a typical HTML5 template having a , , ,
>> and . I'd like Org to include the different exported files into
>> the section, and the rest to remain the same. The
I'd like to use Org as a static site generator. I know quite a few
people use Org to manage their sites, so I'd like to know what's already
available and what I'd need to add to make this working properly.
I know of course how to export a bunch of Org files to HTML through the
publishing features.
Eric S. Fraga writes:
> Bastien writes:
>
>> Eric S Fraga writes:
>>
>>> Given that I no longer use my old syncing approach, described on that
>>> page, and instead use org-caldav, I would be happy to have the reference
>>> to org-caldav moved to the top!
>>
>> It's a wiki, be *bold* :)
>
> Actua
Vincent Beffara writes:
> But it _can_ list my calendars, meaning that it can authenticate and
> have some sort of interaction with google's servers. Maybe interfacing
> with that would not be too hard?
Supporting the Google Calendar API in org-caldav wouldn't be hard. It's
actually a very clean,
'rasmus' writes:
> For now I'm using fluux, but I haven't managed to get org-CalDAV to
> sync yet.
What is that? I'm afraid I cannot find it.
> I'm also looking to sync bbdb via CardDAV, although I would be
> willing to switch to org-contacts if a solution emerged here before.
CardDAV shouldn't
Jambunathan K. writes:
> David Engster writes:
>
>> Jambunathan K. writes:
>>> I know that.
>>>
>>> But that doesn't answer the question why Carsten will appear in the To
>>> header of a mail that I reply to a mail I receive from Eric S Fr
Jambunathan K. writes:
> I know that.
>
> But that doesn't answer the question why Carsten will appear in the To
> header of a mail that I reply to a mail I receive from Eric S Fraga.
Because Carsten started the thread and did not set MFT.
-David
Jambunathan K. writes:
> Still you haven't answered my "Fudging the mail reply headers" question
> to my satisfaction.
http://www.gnu.org/software/emacs/manual/html_node/message/Mailing-Lists.html
"A mailing list poster can use MFT to express that responses should be
sent to just the list, and no
Bastien writes:
> David Engster writes:
>> I won't work on supporting the Google calendaring API until there's a
>> free server implementation for it, which can be self-hosted. If
>> someone else would like to work on that, please create a fork under a
>>
Google has announced today that they will shut down their CalDAV API in
September, since hey, everybody's using their own protocol anyway.
org-caldav will then cease to work with Google calendar. I won't work on
supporting the Google calendaring API until there's a free server
implementation for it
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
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-ic
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.
>
> (d
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-icale
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 ru
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
>>>>>
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
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
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 y
Torsten Wagner writes:
> Now I make a tiny change e.g. change the length of the appointment from within
> SOGo and sync back I get
>
> TODO TODO Neuer Termin mit Foo und Bar r<2013-03-06 Wed 10:00-11:00>
> :PROPERTIES:
> :ID: 8a9651c0-faee-4416-afa6-979e328a3d15
> :END:
>
> As you
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
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
>> eva
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 liv
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
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
Michael Albinus writes:
> David Engster writes:
>
>> Is it OK to report bugs for upstream/development versions through
>> `report-emacs-bugs', though? I always thought this should only be used
>> for stuff that's actually bundled with Emacs (what about bu
Michael Albinus writes:
> Andreas Röhler writes:
>> What about using some of the tools around?
>>
>> Mirroring the stuff at github would provide a tracker just by the way...
>
> Or you use debbugs.gnu.org, which hosts the Emacs bugtracker. Some of
> the org bugs will arrive there anyway, from peop
Julien Cubizolles writes:
> David Engster writes:
>
>> Julien Cubizolles writes:
>>> Since a few days (maybe an emacs update) I get this error message
>>> whenever I run org-caldav-sync.
>>>
>>> Debugger entered--Lisp error: (void-function url-http
Julien Cubizolles writes:
> Since a few days (maybe an emacs update) I get this error message
> whenever I run org-caldav-sync.
>
> Debugger entered--Lisp error: (void-function url-http-options)
>
> I've been digging around a bit and url-http-options is defined in
> url-http.el which is present on
Eric S. Fraga writes:
> David Engster writes:
>> OK, I took a shot at dealing with sexp entries. It's a complicated
>> issue, since s-expressions can be in Org entries or by themselves. I
>> updated the Readme with a section on how they are handled now. Please
>>
Torsten Wagner writes:
> Tested and you are right. Adding a timestamp in the body doesn't get
> lost during sync. Actually, I guess the problem is a combination of
> export and import to org-mode. During the export, the timestamp gets
> read in correctly, however, it get stripped from the Summary
David Engster writes:
> 'giles' writes:
>> David Engster writes:
>>> Could you please do M-x toggle-debug-on-error before running the sync
>>> and post the resulting backtrace here?
>
>>
>> Slightly different behaviour this time: first seven
Eric S. Fraga writes:
> David Engster writes:
>
>> Sven Bretfeld writes:
>>> Hi David and all
>>>
>>
>>> I've got it. By try and error I found out that entries like these in an
>>> org-file cause the problem:
>>>
>>>
'giles' writes:
> David Engster writes:
>> Could you please do M-x toggle-debug-on-error before running the sync
>> and post the resulting backtrace here?
>
> Slightly different behaviour this time: first seven events synced fine,
> number 8 blew up the same way
'giles' writes:
> Contacting host: www.google.com:443
> Getting event 1 of 28
> icalendar--read-element: Search failed: ";\\([A-Za-z0-9-]+\\)="
Could you please do M-x toggle-debug-on-error before running the sync
and post the resulting backtrace here?
-David
Sven Bretfeld writes:
> Hi David and all
>
> I've got it. By try and error I found out that entries like these in an
> org-file cause the problem:
>
> %%(diary-anniversary 6 8 1969) Christian is %d years old
Ah OK. Thanks for looking into this. Those entries apparently produce
events during expor
Sven Bretfeld writes:
> - progn: Could not find UID emacs207403667799062360.
I'm currently struck with a nasty cold, so I have trouble thinking. But
this means that it tries to find this ID in your Org files, and it does
not seem to be there. You can try to go there by calling
M-x org-id-goto
an
Sven Bretfeld writes:
> (setq org-caldav-files "/home/sven/Dropbox/myconf/testlocalcal.org")
No, that's wrong. It has to be a list of files:
(setq org-caldav-files '("/home/sven/Dropbox/myconf/testlocalcal.org"))
-David
Eric S. Fraga writes:
> I've had to clear out the org-caldav-xxx.el file in .emacs.d a couple
> of times but that's typically due to my doing things on the same entry
> in both calendar systems (org and Google).
If you change an item in Org as well as in the Calendar, the calendar
entry should sim
Torsten Wagner writes:
> I see the problem that you might changed the text in the summary field in the
> caldav calendar, which potentially mess up the header (where to place the old
> timestamp within the context of the new text?!) but for now, I would suggest
> to simply search for a timestamp w
Torsten Wagner writes:
> If I understood David right, the "UTC" option is just an addition to the
> already present options.
> Thus, if you used e.g. "Europe/Berlin" before, you do not need to change
> anything and in fact, you shouldn't see a difference.
Yes, exactly.
-David
Torsten Wagner writes:
> I did not had time to play with the different parameters. For now I simply
> added all of them.
> I guess it has to do either with the timezone or with the daylight settings.
> Maybe you want to add this to a "How-to install for SOGo" as a workaround.
I think I found a bet
Torsten Wagner writes:
> You might can try
>
> http://sogo-demo.inverse.ca/SOGo/dav/sogo1/Calendar/personal/
>
> which is the demo account of the Sogo.
Thanks. That'll work.
After a bit of fiddling it seems that SOGo really really wants a
timezone definition. I have no idea how those can be g
Torsten Wagner writes:
> I also noticed the files org-caldav-2094e16.el and org-caldav-backup.org.
> However, they are stored in my .emacs.d folder. Would it make sens to have an
> option to save them relatively to the org-file? E.g. relative to the path set
> in org-caldav-files? That would help t
Torsten Wagner writes:
> Hey David,
> could you please help me and steer me in the right direction to find the
> cuprit
> which makes the caldav calendar lagging an hour compared to the timestamps in
> org-mode.
It's difficult. I will need to add some (optional) excessive debugging
output for see
Torsten Wagner writes:
> we just tried org-caldav and it seems to work very nice.
> We use Sogo http://www.sogo.nu/ and hence David might like to ad Sogo on the
> list of possible caldav servers.
Thanks, that's good news. I'm actually pretty surprised that it works
right out of the box.
> Any pl
Vincent Beffara writes:
> Works great for me, thanks! One thing that changed (but it was kind of
> a glitch anyway, even if a nice one to have): events with several
> timestamps now appear only once rather than one per timestamp. Not
> sure if this is due to org-caldav or to recent evolutions in th
Eric S. Fraga writes:
> I've tracked down the root of the various problems I have encountered
> with the synchronisation. It all comes down to character sets. I
> have some entries that have UTF-8 characters that are not present in
> ASCII, specifically accented characters and similar (latin1,
>
Detlef Steuer writes:
> So it seems all events get deleted immediately after loading them up.
> Indeed my calendars show up empty again in owncloud :-)
>
> Any hints?
Could you post the contents of the *org-caldav-debug* buffer when this
happens?
-David
I just pushed a pretty big update to org-caldav. Get it at
https://github.com/dengste/org-caldav
The short story: org-caldav now does proper two-way syncing. It's pretty
much a rewrite, actually. If you're already using org-caldav, you will
have to start from scratch after updating.
Please read
Stelian Iancu writes:
> Well it seems that it didn't hang at all. What happens is that the
> buffer which contains the org file doesn't seem to accept any keyboard
> input anymore.
This bug is currently being discussed on emacs-devel:
http://thread.gmane.org/gmane.emacs.devel/156120
Jan has alre
When exporting an Org file as iCalendar and org-icalendar-timezone is
set to e.g. "Europe/Berlin", it gets inserted as "EUROPE/BERLIN" during
export (and some CalDAV servers don't like that).
This is because "%Z" gets replaced with org-icalendar-timezone, and the
FIXEDCASE parameter isn't set in t
Detlef Steuer writes:
> What I'm trying to figure out at the moment, is how to setup a batch so, that
> say work.org goes into calendar "work", family.org into calendar "family"
> etc.,
> without asking for user/password combinations.
That's not implemented. I guess you can workaround the probl
Matt Price writes:
> (1) do you know if it's possible to get the speedbar buffer in a
> window instead of a frame?
I initially thought that would be easy. Turns out it isn't. ECB uses all
kinds of 'defadvice' to achieve that.
There's a package sr-speedbar at
http://www.emacswiki.org/SrSpeedbar
Rainer M. Krug writes:
> On 06/12/12 09:36, Jambunathan K wrote:
>> On the left is the navbar. - You can quickly navigate to any
>> heading, a table or a captioned
>> figure.
>
> Couldn't the navbar from emacs be used for that? I haven't used it in
> a long time, but in ecb
> (Emacs Code Browswer)
Suvayu Ali writes:
> On Mon, Dec 03, 2012 at 08:50:35PM +0100, David Engster wrote:
>> I'm at a loss why this happens, and I could not reproduce it with my
>> account. This problem really has nothing to do with org-caldav, since it
>> is delegating this part to the ur
Stephen Eglen writes:
>> I think it is a problem somewhere with my local setup; if I add the
>> following to .authinfo (chmod 600) then it uses the right username:
>>
>> Machine www.google.com login my-gmail-login
>>
>> I'm now about to see how to setup .authinfo.gpg so that I can also
>> include m
Stephen Eglen writes:
> David Engster randomsample.de> writes:
>> Bastien writes:
>> > David Engster randomsample.de> writes:
>> >> That is very strange. It should first
>> >> ask: "Username [for Google CalDAV]:". If it does not do tha
Bastien writes:
> David Engster writes:
>> That is very strange. It should first
>> ask: "Username [for Google CalDAV]:". If it does not do that, maybe you
>> have that information in your .authinfo?
>
> I have this:
>
> machine smtp.gmail.com login bas
Bastien writes:
> I use Emacs from after your patch to url-dav (>7/26/2012)
Then I guess you patched org-caldav-sync to not test for
`url-dav-patched-version'? Anyway, I've now added support for the
Emacs-bzr version of url-dav.
> and I use this simple configuration:
>
> (setq org-caldav-calendar
Torsten Wagner writes:
> Sync went ok however, I notice I have to log-out from the ownCloud
> webmask... again maybe a ownCloud server setting
Yes, Owncloud can be a bit finicky here. From my experience, you should
not be fooled by its 4.x version number; it often behaves more like a
0.4.
> The l
David Engster writes:
> Robert Eckl writes:
>> Acutally, an appointment must not have any text outside the Properties
>
> [...]
>
> I think there's a bug in org-icalendar with regards to handling
> tags. I'm getting an icalendar
Robert Eckl writes:
> Acutally, an appointment must not have any text outside the Properties
[...]
I think there's a bug in org-icalendar with regards to handling
tags. I'm getting an icalendar event like this:
BEGIN:VEVENT
UID:f90ec513423879f1e09c7c10fc0e15a9-orgmodecaldav
DTSTART:20120728T2000
Torsten Wagner writes:
> Guess many are interested actually, this was on the mailing list
> several times already.
> Any chance to merge with mobileOrg? Would be good to have both ways
> and you might save some time doing redundant stuff in both projects.
Well, there's really no redundancy since m
David Engster writes:
> I have written a package 'org-caldav' which can sync items to a remote
> calendar server using the CalDAV protocol. The main purpose of this
> package is to make better use of Org in combination with Android-based
> mobile devices (yes, there is
1 - 100 of 106 matches
Mail list logo
