From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Engster Subject: Re: org-caldav can't find org-prepare-agenda-buffers Date: Thu, 28 Feb 2013 17:17:05 +0100 Message-ID: <874ngw2z26.fsf@engster.org> References: <87k3puyri0.fsf@free.fr> <871uc1sv4s.fsf@bzg.ath.cx> <87vc9d36qp.fsf@engster.org> <87lia9o0e9.fsf@bzg.ath.cx> <878v692ae0.fsf@engster.org> <87621cj3bc.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:56638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UB6AT-0006vz-Nv for emacs-orgmode@gnu.org; Thu, 28 Feb 2013 11:17:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UB6AP-0004Qq-OY for emacs-orgmode@gnu.org; Thu, 28 Feb 2013 11:17:13 -0500 Received: from randomsample.de ([83.169.19.17]:44980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UB6AP-0004Pm-8Q for emacs-orgmode@gnu.org; Thu, 28 Feb 2013 11:17:09 -0500 In-Reply-To: <87621cj3bc.fsf@bzg.ath.cx> (Bastien's message of "Thu, 28 Feb 2013 08:38:31 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: emacs-orgmode@gnu.org, Julien Cubizolles 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 when we release 8.0, hopefully in a not so > distant future. > > We will document all incompatible changes in the release notes, as we > usually do. I expect third-party maintainers to read these notes. Well, I don't expect it. >> I'm wondering why you felt the need to rename them. If the >> new exporters are compatible with the old ones, why not keep the names? >> This would also avoid that the provided feature differs from the used >> name prefix (ox-icalendar != org-icalendar). > > There are several good reasons for this: > > 1) conflicting library names: we now have org-man.el (for links to man > pages) and ox-man.el (for exporting); > > 2) using the dedicated prefix ox- makes it clear that the library is > an export backend, the same way that the ob- prefix makes it clear > it is to support a language for Org Babel. > > In general, the change is incompatible for third-part libraries by is > clearly useful for future maintainance, so the trade-off was in favor > of making it, and 8.0 is a good time for it. I'm afraid I remain unconvinced. 1) is just one name clash, so just rename one of it. Also, like all the other ox-* packages now, ox-man uses 'org-man' as a prefix for its names; what will 'org-man' use, then? 2) is nice, but IMO not a good enough reason to break compatibility in such a major way. Anyway, you've made a decision and did the rename. Let's just agree to disagree here. The most serious issue is that things will often seem to work because old exporters are pulled in from Emacs, possibly *very* old exporters. They might work, or they might fail for various reasons, making it difficult for users and developers to see what went wrong. Just look at the other bug report by Karl Voit from yesterday; I guess it's the same issue. So if you change your API in an incompatible way (and packages names are part of that), you should at least throw a clear error when the old API is used, and tell the user what happened and how it can be fixed. Hence I would suggest to use something like (eval-after-load "org-icalendar" '(error "The old org-icalendar exporter is deprecated; use ox-icalendar instead.")) 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