Open
Conversation
Idorobots
commented
Feb 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is in reference to #11 and #76
I wanted to be able to modify parsed nodes and dump them to a file for a project I'm building. This code was written with AI (Codex 5.2 thinking primarily) but I was in the loop for every change made.
Here's how this works:
LineItemis added that represents a parsed line of an org nodes text. There are subclasses for each supported Org function (dates, properties, headline etc).TextLinesto preserve the 1-to-1 representation when using__str__.LineItem. If one wasn't present for a specific property (node.scheduled = datewhen there was no previous scheduled date parsed from file) one is inserted._line_itemsinstead. That's how the edits are made possible.The_lineswith the original file contents are still available, as a performance optimization, for the usual use-case of just parsing the nodes without making any modifications to them.I also considered creating
_line_itemslazily, on first write, as another optimization, but didn't do that in the end - seems to be performant enough, my 37k task archiveloadsin 2.32s on current master and in 3.71s on this branch. Let me know if this is acceptable.I mostly added unit tests for the new functionality as the current functionality is mostly left unchanged.
The
bodyediting is pretty awkward as it requires a line index since bodies can be not contiguous and can contain timestamps etc.Similarly, edge cases such as duplicated
logbookdrawers are equally awkward.This PR also permits
childrenmodification, so essentially adding subtrees and moving them around the file (but only within the sameOrgEnv.)I reorganized the code a little bit and reexported the relevant functions back from the
nodemodule, to keep the API stable.Technically, these newLineItemscould replace the old attributes like_headingetc, entirely, but I opted to keep the old attributes in, at least until I get some comments on the general approach here - with richer representation it'll be easier to add support for links, etc, as part of the heading for instance.I went ahead and made the "new" representation the only available one (without changing the public API).. That uncovered a few issues, but these were fixed and now my archive loads and looks correct. It also sped things up a bit - archive now loads in 2.68s.