Tim Cross <theophil...@gmail.com> writes: > I don't disagree with this objective. My objection is to changing the > emphasis or priority of org mode as an Emacs mode to a general technical > specification for a small part of what is org-mode, the markup (I will > outline the concerns I have in doing this below).
I think I was not clear enough in my topic-starter when I framed it as "From the narrow perspective of this mailing list". I do not suggest to change emphasis of the whole Org mode project. Instead, I am trying to suggest a set of improvements to orgmode.org aiming to lure broader auditory to _Org mode for Emacs_ and a change to Org test suite that would allow easier contribution to _Org mode for Emacs_ from third-party developers > ... The other point of > course is that if you make it easier to implement org markdown in other > editors, you don't have control over whether they are implemented in > free or non-free solutions. To be clear, writing Org syntax spec has been decided long time ago. See https://list.orgmode.org/87r1qt9cf0....@gnu.org/ and https://orgmode.org/worg/dev/org-syntax.html (started long before that thread). I just suggested to link it to orgmode.org >> The fact is that e.g. Github already provides support for Org markup. >> They do it for their own profit and we cannot stop them. If we have a >> controlled criteria about quality of third-party Org mode support, there >> will be means to interfere with non-free software attempting to makes >> profits out of Org mode. For example, if Github do not integrate our >> recommended test suite (with all the legal consequences defined in >> GPLv3), we will be able to have a list of third-party tools and, among >> free alternatives, mention that Github support for Org is not verified >> and most likely not consistent with other _free_ tools. We cannot do it >> now. >> > > There is a fatal flaw in this argument. The GPL licenses code, not the > underlying idea (which is essentially what patents are about). We can > define all the quality criteria we like for 3rd party implementations, > but we cannot enforce them unless they are also using the GPL'd code. As > this code is elisp, it is extremely unlikely any 3rd party > implementation will be using it. In short, defining clear specifications > and minimal quality criteria will only have baring on code added to org > mode - it would, for example, have no effect on what github has/is > implementing. It is indeed unlikely and not using our tests will degrade its quality if they just use the existing https://orgmode.org/worg/dev/org-syntax.html So, I only see tests as an improvement. > Consider this contrived scenario. As I tried to stress above, I do not suggest to change Org mode project emphasis. Anyway, some of my replies to your statements below might be of interest. > 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. Best, Ihor
