emacs-devel
[Top][All Lists]
Advanced

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

Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode


From: Thorsten Jolitz
Subject: Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode
Date: Wed, 16 Sep 2020 11:23:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

William Rankin via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

Hello,

> At the request of Bastien I'm sending on these ideas regarding the
> future of Org Mode development. I'm also copying emacs-devel since
> they might be interested too.
>
> Org Mode and Emacs would benefit greatly from the codebase being
> broken apart, not unlike how an antitrust suit breaks apart a big
> company for the good of society!

[...]

I do have some hands-on experience with this, although quite some time
ago. When writing the "outshine-suite" (outshine.el, outorg.el
navi-mode.el), it was all about bringing org-mode functionality to
programming modes, or any other major mode that is not org-mode, but
with the org-mode magic acting on outshine headings (outcommented org
headings).

I had to port a lot of org-mode functionality to outshine then (based on
existing outline extensions like outline-magic), and had quite a few
user requests like "I want org-mode feature xyz in outshine too".

I quickly realized that this was an uphill battle and came up with a
'outshine-use-outorg' function, that simply first converts the outshine
buffer to org-mode, executes the requested org command, then converts
the buffer back to outshine. I created a skeleton file with skeletons
for all org-mode commands at that time, and implemented a few, leaving
the others to any contributors that feel a need for the feature. 

Here is what I remember about that process of porting org-mode
functionality to outshine:

1. org-mode is clearly not written in "library-style". 
2. many org commands don't expose their parameters in a function
signature, but rather ask the user for them with some interactive prompt
3. some org commands are "stateful", like clocking e.g., and it might be
hard to preserve the state without having the related org buffer around 
4. many org commands don't do just one thing, they are smart in a way
that makes the user happy, but the programmer who wants to reuse them
unhappy. 

I remember that some functionality was straight forward to port (like
org speed commands), and other not so much (although org-mode had some
enhanced outline functions, there were reasons that I used and improved
the outline-magic versions iirc).

This project could be quite a lot of work (adressing points 2-4 above)
imo, but sounds very nice. 
 
Just my 2 cents ...

-- 
cheers,
Thorsten




reply via email to

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