Fixing headline functions and defining a "headline" about org-clones

[legalnonsense]

I've made it so that any progress cookie in a headline is automatically moved to the end of the headline, and excluded from the headline functions (goto-headline-end) (get-headline-string). This seems to solve the problem, though it means users have to live with only having progress cookies at the end of the headline.

[yantar92]

Also note that other location-sensitive auto-text can be generated by org-babel inline code blocks.

[legalnonsense]

I think that given the number of possible ways a heading could be altered, it is best to address the big ones but otherwise focus on a good conflict check/resolution system? That said, can you give me a quick org-babel example? I appreciate the feedback very much already.

[yantar92]

That said, can you give me a quick org-babel example?

See below. You can press C-c C-c to generate the results block.
The results block may also be generated automatically on export when org-export-use-babel is set to t.

Note that I do not personally use inline code blocks in my workflows, but anything may happen in the wild.

* test src_elisp{(org-entry-get (point) "ASD")} {{{results(=122=)}}}
:PROPERTIES:
:ASD:      122
:ID:       c39ce8ba-d96b-49eb-9642-20e2ee9ad045
:END:

I think that given the number of possible ways a heading could be altered, it is best to address the big ones but otherwise focus on a good conflict check/resolution system?

Probably the easiest way would be introducing a "master" heading that has prevalence over other copies. If a change happens in "slave" headings and that change was not handled by org-clones, the "master" text can be copied over.

Indeed, a proper git-like interactive conflict resolution would be superior.

I appreciate the feedback very much already.

I am interested in this project very much. In fact, my mirror-text package is the initial step towards transclusion in org-mode. I planned to implement what you are already doing as a followup (+ transclusion of source blocks).

Having clones of headlines will be a solution to the common issue with hierarchical data management when the same data may belong to multiple categories.

Similar thing is achieved by org-roam, but cloning may play nicely with refile mechanisms (org-refile with some prefix arg may be a logical way to clone a heading).

[legalnonsense]

Note that I do not personally use inline code blocks in my workflows, but anything may happen in the wild.

• test src_elisp{(org-entry-get (point) "ASD")} {{{results(=122=)}}}
  :PROPERTIES:
  :ASD: 122
  :ID: c39ce8ba-d96b-49eb-9642-20e2ee9ad045
  :END:

Yes I have never even considered using an inline code block like this. Seems the best solution would be to exclude the {{{results}}} section from a headline? I am not sure what the syntax is generally, but can figure that out.

I need to look at how your transclusion package works, but if we could get clones working reliably that would be a great feature. I am operating under the assumption that work done on my "hacky" solution will still serve a purpose since defining headlines, bodies, etc., will be a problem that still needs to be solved.

[legalnonsense]

I've done a lot of work on getting headline functions working better. It will skip TODOs, COMMENTs, inline babel results (these are assumed to be at the end of the headline), progress cookies (these are relocated automatically to the back of a headline when the headline is synced), and priority cookies.

I like the org-refile idea and will make a separate issue for that. Should not be hard to write. Will also open a separate issue for dealing with conflicts.

I also write an ERT test (this is the first time I've really done so, so not sure of best practices) for testing the headline functions.

Would like to keep this open for discussion of headline issues. If you notice anything else please let me know and I will fix.

[legalnonsense]

Should probably replace the headline functions with a regexp similar to the org-complex-heading-regexp....?

[yantar92]

I've done a lot of work on getting headline functions working better. It will skip TODOs, COMMENTs, inline babel results (these are assumed to be at the end of the headline), progress cookies (these are relocated automatically to the back of a headline when the headline is synced), and priority cookies.

I feel it is getting too complex at this point to make separate code for each case. Probably, a better aproach would writing a "transformation function" - the idea used in https://github.com/vspinu/lentic. Basically, it generalises syncing to chunks of text into transformations. When text is changed in one place, it is not copied to the synced place as is, but first passed through a "transformation function" (this function does not even have to be symmetric). Then, simple copy will correspond to #'identity transformation. For the headlines, we may pass a text through a number of [configurable] transformations, including removing/moving the cookies or source block results.

As a further improvement, the transformed text that is being copied, can be merged using configurable algorithm (probably also involving interactive conflict resolution).

Example:

first chunk being changed

TODO Some example headline containing [5/14] and some text after and we added more text

second chunk

WAIT Some example headline containing [4/1055] and some text after

The transformation function can clear up the cookie and transform the changed text into "Some example headline containing [/] and some text after and we added more text".

Later, merge function will merge the "[/]" with "[4/1055]" in the target headline.

P.S. To be frank, it sounds more like a right functionality for the mirror-text (if you decide to use it) with proper transformation/merge functions configured for the headline chunks on the org-clones side. However, mirror-text should be first better tested on simpler cases before adding any functionality.

[legalnonsense]

Lentic is beyond my ability at the moment.

I see what you are saying with regard to transforming the text. For now I am going to stick with the strategy of normalizing the headline order so that it is easy to extract the headline string, and I'm going to regard progress cookies as items that are not synced and can be added to any cloned headline independently. This way, any progress cookie remains solely with a specific headline and can be updated automatically. I think your example assumes that the user wants the progress cookie to appear in every headline, but that may not be the case.

I agree that having separate functions to go find each element of a headline is messy and will change it later, but for now it is helpful for me to figure things out. I am not great at programming and it is a hobby only so I am probably doing things in less than ideal ways.