emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concrete suggestions to improve Org mode third-party integration ::


From: Timothy
Subject: Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
Date: Mon, 06 Dec 2021 02:54:34 +0800
User-agent: mu4e 1.6.9; emacs 28.0.50

Hi Ihor,

Thank you for your email. I have little to add to you analysis and suggestions
other than my strong agreement. However, I will give some of my thoughts that
lead me to this position.

Ultimately, we have a choice. Do we wish to be hostile, or welcoming to interest
in Org outside org-mode? Under the “hostile” or “isolationist” option, we might:
⁃ Talk of Org not as a general format, but the /exclusive/ format of org-mode
⁃ Ignore any and all attempts to support .org files outside Emacs
Under the “welcoming” option, we might:
⁃ Treat OrgMode as a “brand name” for the Org file format, with org-mode as the
  reference implementation
⁃ Take reasonable steps (such as those Ihor suggests) to make Org seem
  relevant/interesting/usable (if inferior) without Emacs
⁃ Encourage efforts to support the format outside Emacs’ org-mode

To me, the choice is clear. I think we loose nothing by choosing by welcoming
interest in Org outside org-mode, but potentially gain much. As Emacs users, we
can think of ourselves as living in a little Emacs bubble (of around 2% of
developers if StackOverflow’s developer survey is to be believed). Like Karl
Voit, I believe Org holds a lot of value as a markup format in and of itself.
The other 98% + some non-developers have good reason in my mind to be curious
about Org. I imagine many of us regularly interact with such people. We see this
interest manifested not only in extensions for various other editors ([neovim],
[atom], [vs code], [sublime], etc.), but also parsers and tools that work with 
Org
like Hugo, Pandoc, and LogSeq. We do not live in a bubble. We all benefit from
such efforts.

*The more people use Org, in some form, the greater the chance that someone
making a new tool will think to support it.*

Whatever we may make of it, there is clear interest in Org (to some extent)
separately from Emacs. By ignoring that, we only do ourselves and potential
future Org / Emacs org-mode users a disservice.

People are currently making editor extensions and tools for Emacs outside
org-mode. I don’t think this is suddenly going to stop. We might as well help
such efforts. Good tools that work with Org are good for Org / org-mode. By
providing good clear documentation, and a well-defined grammar, we reduce the
risk of different implementations of the syntax and functionality defined by
org-mode. We could even provide some for of “implementation roadmap” (linked to
the syntax specification) to help developers understand what is required to
implement certain functionality (both markup/syntax, and editing features —
more on this idea I’ve had in a future email). Karl Voit’s idea of “levels” of
Org helps make the task less daunting.

Yes, it will take a bit of effort to do this, and in particular to do this well.
I feel it would likely be worth it though. From the efforts we’ve seen so far,
we have nothing to loose and much we could gain.

All the best,
Timothy

p.s. I see some concerns have been raised about freedom and Org outside Emacs.
While the FSF/GNU project are champions of the FOSS movement, there are many
other FOSS projects and FOSS editors. To decry helping non-GNU/FSF
projects/editors because there are non-free projects/editors seems a bit much.
If improving our documentation and being friendlier to non-Emacs users looking
at the project website is anti-freedom/breaks FSF rules, what’s making an Emacs
build for Windows?


[neovim] <https://github.com/nvim-orgmode/orgmode>

[atom] <https://atom.io/packages/org-mode>

[vs code] <https://github.com/vscode-org-mode/vscode-org-mode>

[sublime] <https://packagecontrol.io/packages/OrgExtended>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]