emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
Date: Thu, 09 Dec 2021 01:39:57 +1100	[thread overview]
Message-ID: <87tufjt8r1.fsf@gmail.com> (raw)
In-Reply-To: <87k0gf5hud.fsf@localhost>


Ihor Radchenko <yantar92@gmail.com> writes:

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


  reply	other threads:[~2021-12-08 15:31 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-05  7:35 Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal Ihor Radchenko
2021-12-05  9:16 ` Juan Manuel Macías
2021-12-05 10:24   ` Ihor Radchenko
2021-12-05 11:08     ` Juan Manuel Macías
2021-12-05 11:54       ` Heinz Tuechler
2021-12-05 12:08       ` Ihor Radchenko
2021-12-05 13:32         ` Tim Cross
2021-12-05 13:52           ` Bruce D'Arcus
2021-12-05 22:20             ` Tim Cross
2021-12-05 14:30           ` Ihor Radchenko
2021-12-05 22:39             ` Tim Cross
2021-12-08 13:47               ` Ihor Radchenko
2021-12-08 14:39                 ` Tim Cross [this message]
2021-12-08 16:16                   ` Dr. Arne Babenhauserheide
2021-12-08 17:07                     ` Russell Adams
2021-12-08 19:22                       ` Dr. Arne Babenhauserheide
2021-12-08 20:14                         ` Russell Adams
2021-12-08 21:50                           ` Tim Cross
2021-12-09  8:12                             ` Dr. Arne Babenhauserheide
2021-12-08 21:25                         ` Tim Cross
2021-12-09  8:07                           ` Dr. Arne Babenhauserheide
2021-12-09  8:36                             ` Timothy
2021-12-09  9:18                               ` Ihor Radchenko
2021-12-09 10:46                     ` Eric S Fraga
2021-12-09 15:21                       ` Russell Adams
2021-12-09 16:25                         ` Eric S Fraga
2021-12-09 21:15                           ` Samuel Wales
2021-12-09 23:27                         ` Dr. Arne Babenhauserheide
2021-12-10  2:42                           ` Tim Cross
2021-12-10  6:08                             ` Dr. Arne Babenhauserheide
2021-12-11 10:03                   ` Ihor Radchenko
2021-12-11 21:19                     ` Tim Cross
2021-12-06 19:41             ` Karl Voit
2021-12-05 18:59         ` Juan Manuel Macías
2021-12-05 23:24           ` Russell Adams
2021-12-06  5:57             ` Juan Manuel Macías
2021-12-06  6:02               ` Timothy
2021-12-06  7:24                 ` Juan Manuel Macías
2021-12-06 10:04                   ` Greg Minshall
2021-12-06 14:59                     ` Juan Manuel Macías
2021-12-06 17:59                       ` Tom Gillespie
2021-12-06 18:25                         ` M. ‘quintus’ Gülker
2021-12-06 18:42                           ` Russell Adams
2021-12-06 18:47                             ` Timothy
2021-12-06 19:28                               ` Russell Adams
2021-12-06 19:34                                 ` Timothy
2021-12-06 18:30                         ` Russell Adams
2021-12-06 19:10                         ` Gerry Agbobada
2021-12-08 12:56                           ` Ihor Radchenko
2021-12-06 10:08         ` Greg Minshall
2021-12-06 19:45         ` Karl Voit
2021-12-07 11:08           ` Vincent Breton
2021-12-08 13:13             ` Ihor Radchenko
2021-12-08 13:30           ` Ihor Radchenko
2021-12-05 13:06   ` Tim Cross
2021-12-05 14:55     ` Ihor Radchenko
2021-12-05 18:54 ` Timothy
2021-12-06 11:08 ` Max Nikulin
2021-12-06 18:43 ` Russell Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tufjt8r1.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).