Ihor Radchenko <yanta...@gmail.com> writes:
> Tim Cross <theophil...@gmail.com> writes: > >> Meanwhile, Emacs development continues and new features/capabilities >> continue to be added. In particular, a new feature is added which is >> extremely powerful and would be a huge benefit for Emacs org-mode users. >> However, there is a problem. In order to take advantage of this new >> feature, significant changes are required for the specification. This >> will result in implementations requiring considerable work in order to >> update them to the new specification. > > I disagree. We already need to care about back-compatibility of Org > syntax (think of org documents written years ago). Major changes to > syntax are very unlikely even without considering third-party software. > And, by the way, remember the existing "third party" Elisp packages > (think of Org roam, for example). We do not want to break them. > Backwards compatibility is important and changes should never be done lightly. However, that doesn't mean they don't occur (we have already had breaking changes, so old org files are likely to have issues already). Backwards compatibility can also become a burden and sometimes, needs to be sacrificed to maintain the viability or maintainability of the system. So while I totally agree we should work very hard not to break compatibility or adversely affect other projects which are built on top of org mode, like org-roam, we also don't want to find ourselves in a position where we cannot improve/enhance org mode because of the impact it has on other projects. The priority should always be org-mode as an Emacs mode. When there is a need for a breaking change, that needs to be managed in a way which provides other dependent libraries and projects a reasonable time to adapt. Having thought about this whole thread and other recent posts, I still feel any concern or reference to third party libraries etc is misguided or at the least, irrelevant. Most of the suggestions are fine and would be beneficial to org mode (such as clearly defined, consistent and documented syntax). The fact 3rd party libraries would also benefit from this is a bonus, but largely irrelevant. I'm not convinced that the perceived lack of such documentation or specification is actually the impediment to a 3rd party org mode. I think the real problem and the real reason you are unlikely to get a version of org-mode which is popular for non-Emacs users (and would facilitate collaboration with non-Emacs users) is because what makes org-mode so great has little to do with the markup. The org-mode markup is no better or worse than other 'markdown' dialects. What makes org-mode such a great system is intrinsically interwoven with Emacs and the facilities Emacs provides. The amount of work which would be required in another editor to get even close to the experience and benefits of org mode is simply too high. The best you can hope for is some baic rendering and syntax highlighting/font-locking, which is unlikely to be sufficient to make people switch from the existing markdown they already use. I think a far more likely scenario is that we will see some/many of the ideas found in org-mode adapted and implemented in other editors, but without concern for compatibility. This has little to do with Emacs org-mode's documentation or org-modes specification, but rather is about how the ideas which are encapsulated in org-mode can be implemented in other systems and within the limitations of those systems. I'm actually surprised there hasn't been more org-mode clones already, but that could be a reflection of the amount of work it would take to create something which wasn't just another markdown module that renders a reasonable HTML/PDF version of it's contents. .
