Hacker News new | past | comments | ask | show | jobs | submit login

I have experienced the same thing at least twice in the last 5 years ... automated scripts for compiling and uploading >50 .org files for a course website, suddenly fails. Spend 3 days chasing down why. Small naming change in an org function.

Now again?

It's very frustrating.




In that case, do not update. Emacs and Org-mode are showing gear signs that the development is active, the software is constantly improving, and bugs are constantly getting squashed.

It is in your hands if you want to keep using the same version of org-mode and Emacs, or update to the latest and greatest and fix few necessary backward incompatible changes.

The ORG-NEWS also provide elisp snippets that help quickly make those fixes for you. So if you choose to update, give some time to read through ORG-NEWS.


yes I hadn't seen that but they do provide some elisp code snippets to automate some of those code changes. thanks!


Happens with every piece of software that is actively developed past initial release. In other words, c'est la vie.


Hmmmm wait. I don't see how "every piece of software" is like that.

Opening an old Excel or Word file does not randomly fail (last time I checked).

Or, if you pick some circa-2005 Java library, it still works.

So it is not clear why org-mode gets a free pass here. At least they could prompt you that "your stuff will not work" if you upgrade.


Excel or Word will randomly fail if the file is old enough. But ok, so Word/Excel can upconvert files if needed. Fair. But does a new document opened in the current Office program look the same? And I mean precisely the same, with fonts and sizes and indentation saved? And what about UI? Don't features appear/disappear?

As for Java - it's mostly compatibile in source and in bytecode:

http://www.oracle.com/technetwork/java/javase/compatibility-...

like with org-mode, the compatibility is broken in some weird cases.

Consider also the file formats. Both Office formats and Java bytecode are binary formats not meant to be read by humans[0]. They can afford backward-compatibility measures. Nobody will bat an eye when new updated version of an opcode will get called CALL2, CALL3, CALL_FIXED, etc. Nor will they care if version flags start showing up in document formatting tags.

Org-mode, on the other hand, is a thin layer of visual formatting over a plain text file. Except in few cases (links, folding), it doesn't change the visible contents of the file compared to opening it as unformatted text! In org-mode, your text file is your UI. It is meant to be edited by hand. So you can't clutter the file with backward-compatibility measures.

Now org-mode provides some elisp scripts to upconvert older documents. They probably don't cover every case, but that's kind of normal - you can't cover everything, and e.g. the cases discussed here today are some pretty advanced / rare ones. Still, it's cheap to manually fix org-mode files - you can just open it and take a look! Try that with Java bytecode or Office formats. You can't - hence the additional effort in ensuring compatibility between versions.

--

[0] - Yes, I know new Office format is zipped XML; it's still not meant to be read or modified manually.


Then don't upgrade. If they are notes from five years, you probably don't need the latest version.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: