On Mon, Dec 06, 2021 at 09:59:42AM -0800, Tom Gillespie wrote: > I think it is a major strategic mistake to exclude discussions > about interoperability from this list.
I don't think discussion on the list (or irc) is a problem. It's all on topic if it's related to Org-mode. As you said, users and developers share the mailing list. Just understand as an Emacs mode, it's Emacs oriented and Emacs is the priority. The truth is Org doesn't work outside Emacs. The issue is when non-Emacs enhancements or feature requests are made to the maintainers and coders. I don't think anyone is hostile to interoperability, but hostile to additional workload. I've watched Org since shortly after it's creation snowball features nonstop until it burned out coders. I feel like every power user with a new edge case feature wants it added to the Org core, and that's just not sustainable. That's why I'm very cautious about advocating for new features, or potential burdens external interoperability may place on our volunteers. > I follow this list, I keep the community up to date with my work, > I have no idea where to look for other Org related dicussions, IRC. #org-mode on Libera. > Whether a certain portion of the Org community likes it or not, > there is another portion for whom Org syntax already has a life > beyond Org mode (e.g. academic papers and computation notebook > style workflows). Ideally written with Emacs, and the source blocks processed by Emacs. I can't imagine any of the data science source blocks working in any environment outside Emacs today. If other programs try to replicate Org's features that's fine in the spirit of open source, but what support do we owe their implementations? At what point does their project impose a maintenance burden on our volunteers? That's what we need to be careful of. Perhaps it's worth noting the clear distinction between Org's plain text format and the Org experience inside Emacs. I think that the plain text format in it's simplest forms may be interpreted by external tools (ie: README.org on Github is HTML formatted). I don't expect any tools outside of Emacs to provide the Org editing experience. > The plain text nature of Org syntax and the freedom that it enables > also means freedom from Emacs. Empowering users to own and control > their own data to use with their own tools is the whole point. The > fact that this means that it works outside Emacs is a critical > feature for many data preservation use cases. Certainly Org is future proof because it's plain text. There's a big difference between future proofed and openly legible versus programming two way interoperability between Emacs and an external tool. Just ask any synchronization tool. ;] In summary, don't assume hostility to interoperability. Please respect the limited time of our coders and maintainers, and the additional burdens on them that may be implied by supporting external programs. ------------------------------------------------------------------ Russell Adams rlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
