How are the id properties affected for items:
- When a line is split?
- When a line is merged with another line (via delete/backspace)?
- When lines are inserted/deleted via other means (undo/redo, paste, select->edit)?
- When the file is closed and opened again?
I’m guessing the Taskpaper Mac app manages id’s in the most “natural” way expected… but maybe not? Are item id’s not guaranteed to be “attached” to their contents after a multi-line edit? I’m trying to apply a change event from a text editor back to the birch-outline model, but it’s not so simple!
So if item id’s are aligned with their contents after multi-line edits, how does TaskPaper do it? (And Taskpaper saves to a custom XML format instead of plain text now, right?)
There are some edge cases, but generally when you press Return a new item (with new id) is created for the item text that followed the caret, and the text that proceeds the caret keeps the original id.
When a line is merged the first item (that’s being merged into) retains it’s id, while the second item is deleted.
Undo/Redo should restore the outline to it’s original state, including ids.
When you open/close a TaskPaper (plain text) file ids are lost, not preserved. There is a XML serialization (available in the framework) format that does preserve ids, but it’s not well tested yet.
I think it does, at least that’s my intention
I’m curious, is there any backstory to the “birch” name? I always picture birch trees, but I don’t see any logical correlation with TaskPaper.
Yup, it’s birch trees The project is all about outlines, tree data structures. And birch tree’s are black and white, seemed like a nice match for my plain text goals.