Aloha Andreas, Andreas Leha <andreas.l...@med.uni-goettingen.de> 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. 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? Pleased to appear well-organized, Tom -- Thomas S. Dye http://www.tsdye.com