Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Ihor Radchenko <yantar92@gmail.com>]

Tim Cross <theophilusx@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.fsf@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