From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: Buffer local alias? Date: Wed, 15 Jan 2014 09:41:08 +0100 Message-ID: <87ob3dy6vv.fsf@med.uni-goettingen.de> References: <87a9ey5p50.fsf@alphaville.bos.redhat.com> <87zjmyic0v.fsf@bzg.ath.cx> <87wqi2xmhh.fsf@med.uni-goettingen.de> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3M2S-0004Zu-8b for emacs-orgmode@gnu.org; Wed, 15 Jan 2014 03:41:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3M2M-0004AE-Sg for emacs-orgmode@gnu.org; Wed, 15 Jan 2014 03:41:28 -0500 Received: from plane.gmane.org ([80.91.229.3]:37902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3M2M-0004A6-MQ for emacs-orgmode@gnu.org; Wed, 15 Jan 2014 03:41:22 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W3M2K-0001g4-QK for emacs-orgmode@gnu.org; Wed, 15 Jan 2014 09:41:20 +0100 Received: from genepi110.genepi.med.uni-goettingen.de ([134.76.140.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Jan 2014 09:41:20 +0100 Received: from andreas.leha by genepi110.genepi.med.uni-goettingen.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Jan 2014 09:41:20 +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: emacs-orgmode@gnu.org Hi Tom, tsd@tsdye.com (Thomas S. Dye) writes: > Aloha Andreas, > > Andreas Leha writes: > >> I am not as organized as Tom is. So the chances to use my up-to-date >> orgmode and successfully export any of my org documents from a year ago >> (they are almost all 'Literate Programming' documents and, thus, maybe >> more fragile?) are slim. I do not have numbers, but it seems like I'll >> need to adapt such documents all the time. >> >> I know that this problem is a problem of balancing backward >> compatibility with new features, better design, etc and cannot be >> solved. And I see the win in (most of) the breaking changes. >> >> But let me just express my vote for even more awareness of people like >> me, who do not read all release notes, forget most of the messages from >> the mailing list and as a result need 2 hours to export some document >> from last year again today. >> >> A change like this one (renaming sbe to org-sbe) is a small change and >> will only be an annoyance in one years time. The drop of the implicit >> naming of call lines, for example, was (and still will be for some of my >> files) a bigger issue. > > I fully agree that it is challenging to prepare an Org mode file that > can be "moth-balled" for a while, then resuscitated to full > functionality without a lot of work. > > Perhaps one way to deal with this is to have the Org mode literate > programming (reproducible research) file choose which version of > Org-mode to use. Due to my difficulties in reproducing my own document from a year ago, I stopped calling my Org-mode documents 'reproducible research' ;-) > Something like the following? > > #+name: org-mode-version > #+begin_src sh > cd path/to/org-mode-git-repo > git checkout rev > #+end_src > > # Local Variables: > # eval: (and (fboundp 'org-sbe) (not (fboundp 'sbe)) (fset 'sbe 'org-sbe)) > # eval: (sbe "org-mode-version") > # eval: (org-reload t) > # End: > > I haven't the faintest idea if this is a "good idea" or a snake pit of > potential problems. Is the idea worth experimenting with? IIRC, org-reload is not too well supported and might even vanish one day. I could not find that discussion on a quick search, though. So, this approach might be potentially problematic, indeed. Regards, Andreas