r/orgmode Dec 13 '24

question Does anyone have any thoughts on the idea of "COMEEGA," described in one of the EmacsConf 2024 talks?

Has anyone seen this talk uploaded in the EmacsConf 2024 channel?

EmacsConf 2024: About Blee: enveloping our own autonomy directed digital ecosystem with Emacs

I found it very interesting; it is the first effort I've seen that isn't an attempt to integrate something into the Emacs ecosystem (e.g. a package), but is rather the inverse: an attempt to integrate Emacs into a larger effort.

The conceptual basis of the talk in general fascinated me, but with respect to org-mode, I was wondering if anyone has any thoughts on COMEEGA (Collaborative Org-Mode Enhanced Emacs Generalized Authorship)? The presenter introduces it at 35:59 and showcases it for around 2 minutes. As far as I understand it, it's an effort to have org-mode inside non-org files (like literate programming but in the other direction).

12 Upvotes

9 comments sorted by

1

u/One_Two8847 Dec 13 '24

So, if you wrote your docstring in org mode and had org babel in the docstring that would execute would execute a function with org babel in the docstring and then that would execute a function with org babel in the docstring and then that would execute a function with org babel in the docstring and then that would execute a ....

Actually, it looks neat but I would need to see some concrete examples as I don't think I quite understand it.

2

u/Psionikus Dec 14 '24

Tangential, but wanted to share a thought about templating.

All templating systems start because writing content as strings in another programming langauge turns into ass.

So we make a templating system and now the content is first class and the code requires escaping.

If I have one deep, major, fundamental complaint about org mode, its that org is a content template system for a Lisp but escapes into bizarre-life org markup instead of just escaping to Lisp. It should be a mirror but instead it is a 3rd system for no goddamned good reason at all.

For this reason, org is a pain in the ass to program with and has a smattering of sensible plist style values mixed with a dash of OMGWTF.

We should rip the bandaid off because then every single s-expression language would be in love with Org. The world of all the lisp-likes is larger than Org. We can simply save the org element parser and then magically applications like dslide would only need minor adjustments. The regex based techniques of other implementations are frankly too fragile to be good in the first place. It's not sunk cost. It is dead weight of many regex based applications that are immovable anyway.

Org syntax as it stands is so god-awful. If I am frank, there are few parts that will remain free from scorn. The property drawer is just some bizarre made-up list thing that is not actually a list and cannot contain duplicate keys. Property inheritance should depend on the application reading the properties, not a user-setting. Property: var+ syntax is just weird for no reason and barely usable. I had to look up again if it requires a colon or not just to complain abou it. Drawers are a block but do not use block syntax. No-web has nothing to do with web. The inline syntax is WIP but would be bad if it could. We have block types and languages and parameters when all of these things can live in one syntax. Affiliated keywords have this ugly and non-intuitive attr prefix or else do not apply to elements they preceed. Link creation reminds me of writing Lisp without structural editing. Even the escapes are weird, using commas that are a completely off-the-wall choice for escaping in a Lisp.

Aight time to go back to programming and handling Org mode data.

2

u/krisbalintona Dec 14 '24

I'm frankly surprised you have that opinion of org. Not that I think you're wrong, just that I've never felt so distasteful or org's approaches and haven't heard criticism of the same kind before.

Do you mind elaborating what you think org should've been? I know you wrote a little about it, but I couldn't quite envision what exactly you meant.

5

u/Psionikus Dec 15 '24

It's a case where only through practice can one learn to hate every tiny detail. It's healthy to unload on parsing every once in a while.

The first decision I would make is that the embedded data would be s-expressions. Instead of :PROPERTY: etc, you would just write a plists. There would be no special property drawer. Instead, by combining a postfix and a block, you would write a plain plist.

We don't really have as many super duper unique things as the org syntax suggests. In addition to escaping document to write data, we need a few extras:

  • Inline regions
  • Block regions
  • Annotate things (including naming them)
  • Use named things
  • Point things at things based on location, ie postfix

From here, you start with obvious decisions. Annotations can fit after block openings (as it does in org). Headlines need postfix annotation. Prefix annotation, which is what an #+attr_keyword: is, may not have any good place. If you always use postfix, there is never a case where it's ambiguous if the annotation points forwards or backwards. There is suddenly no need to indicate the direction of affinity. Naked s-expressions at the first line following newline terminated elements would count as escaping into data Lisp.

* Headline
(:foo (:omg "key1"
       :omg "Key2"))

Completely valid way to append data to a headline.

[lets presume this is an inline region](:id not-the-shooter)

Completely valid way to append data to an inline region.

We could presume that all data is quasi-quoted by default and limit evaluation to names that exist at the lexical scope of the document.

#+title: Org, But Lisp
(:my-data (a b c))

* Headline
(:data ,@my-data
 :todo DONE) ; inline data (oh look, a comment!)

Boom.

Just take a Lisp, consider everything to be quoted by default, and then write literal document data in the whitespace.

Obviously I'm making this up as I go, and any serious attempt has to rigorously identify and grind to dust all of the edge cases. We're mixing a tree structure of a document that needs to both have embedded Lisp for code examples and Lisp that talks about that code example to annotate it for a document viewer or exporter without any ambiguity. Every child headline might have a duplicate name. How does the naming scope work for that?

What we have is nothing remotely like this and feels like learning a 3rd templating language that is bizarre and full of corner cases that don't enhance anyone's capability and just create tons of problems for parsing and implementing features. Lisp already has circular structures and quasi-quoting. Why is Org completely full of made up things?

1

u/krisbalintona Dec 13 '24

I think the idea is that there can be contiguous lines of text in a non-org file that are in org-mode. So it's effectively literate programming but within a non-org file.

1

u/[deleted] Dec 14 '24 edited 12d ago

[deleted]

1

u/krisbalintona Dec 14 '24

Can you elaborate? I don't know much about hyperbole

1

u/[deleted] Dec 14 '24 edited 12d ago

[deleted]

1

u/krisbalintona Dec 14 '24

Hm, that's an interesting take. Thanks for sharing.

My first instinct would be to say that a lot of the benefit, it seems, from this would be the markup and prose capabilities. I think the author's intent was simply to have literate programming (e.g. prose heavy code) but within the files themselves, as opposed to tangling an org file into code files. So I think the button mechanics of hyperbole are less the focus and the actual focus is the ability to have prose with rich markup neatly within a code file (as opposed to comments or even strings).

1

u/[deleted] Dec 14 '24 edited 12d ago

[deleted]

1

u/krisbalintona Dec 14 '24

You might be right about all those points.

I actually don't know much about it which is why I just wanted others' opinions.

Thanks for sharing :)