Follow

" is an example of how development went astray." Richard :orgmode:
lists.gnu.org/archive/html/ema
Interesting thread 👍

Btw, I absolutely disagree: re-implementing basic Org functionality within every module would be a very bad idea IMHO.

· · Web · 2 · 4 · 4

@publicvoit Actually, yes, it is not too late to try to untangle some of Org's functionalities - but it most not be done against the core value of Org for most users.

Btw, when I said "Org is to Emacs was Emacs is to your operating system", I was well aware this could be used as an argument *against* Org-mode: bloated and doing too much.

@bzg Maybe I don't understand the basic technical issues here since I'm not an Org code contributor.
However, I do think that the main "core" of org needs to implement basic/common functionality that should never be "copied" somewhere else. The feature-set of Org is overwhelming, yes. I don't think that this is an issue because what you don't use does not get in your way. Furthermore, the modular Org concept is a very good strategy so that you are able to decide what to install and what not.

@publicvoit @bzg Code reuse vs. specific reimplementation is a trade-off more than principle. Yes some things Org does can be decupled and genericised, but there's not much pragmatic value in that. Org big and messy, but that's to be expected: it's pragmatic, extensible and comprehensive.

The time this'd take would be better spent revamping Org APIs, IMHO. A new, consistent set of functions under a new ns like orgv2-, bit like github.com/Fuco1/orgba

Or getting rid of Gnus' homegrown OOP 😜

@publicvoit From a technical viewpoint I actually think he’s right at that.

But from a practical he’s wrong: Org mode is an example of development based on the wishes of users.

One point I miss in the thread, though, is that the next logical would be to implement the node-querying functionality of org-mode for other modes. Basically implement org-map-entries for other modes.

A usage example: hg.sr.ht/~arnebab/kanban.el/br
dd11d722b20a#L199

@publicvoit What I think RMS missed is that org-mode provides a general hierarchical data-format with an API.

Implementing that API in other modes would be the first step towards generalizing org-mode facilities.

Org-mode as a killer application pushed Emacs forward a lot. Now other parts of Emacs can follow where that’s beneficial.

For example programming-modes could provide access to classes and functions as nodes, mapping the org-mode API to their functionality.

@ArneBab While I can follow your rationale in some point, I'm convinced that org would have died a rapid dev death when they initially would have tried to "on-board" other modes before having a working version that get used and tested in the wild.
Another variant of "you can't be everybody's darling" IMHO.

@publicvoit I think that, too. First org had to be made really good by itself — that is how killer applications are made.

I do think that some parts of org-mode can be made more general, but looking deeper, many simply are specific integration that’s not very complex by itself. For example gnus also has quite a bit of linking-stuff.

The great deed I see in org-mode is that it shows how to tie all of Emacs together.

Sign in to participate in the conversation
graz.social

Mastodon: ein nachhaltiges und dezentrales soziales Netzwerk mit Fokus auf den Grazer Raum und Österreich.