Implement tree interface

[subthedubdub]

Right now, there is no way to easily traverse the org-mode syntax tree. I recommend a function be implemented to query the child elements of an OrgComponent in a generic way, e.g.

children(o::OrgComponent) = OrgComponent[]
children(o::FootnoteReference) = begin
    isnothing(o.definition) && return OrgComponent[]
    o.definition
end
# ,,,

Such an interface would allow one to do a DFS of the syntax tree. If bringin in dependencies is acceptable, implementing the AbstractTrees.jl traits would be convenient.

Some type definitions may need to be adjusted, e.g. from

mutable struct CitationReference <: Object
    prefix::Vector{Object}
    key::AbstractString
    suffix::Vector{Object}
end

to

mutable struct CitationReference <: Object
    prefix::CitationReferencePrefix
    key::AbstractString
    suffix::CitationReferenceSuffix
end

struct CitationReferencePrefix <: Object
    contents::Vector{Object}
end

struct CitationReferenceSuffix <: Object
    contents::Vector{Object}
end

children(o::CitationReference) = [o.prefix, o.suffix]
children(o::CitrationReferencePrefix) = o.contents
children(o::CitrationReferencePrefix) = o.contents

[tecosaur]

Interesting. I do quite like that this is currently 0-dependency, but I can see the value in this.

For what it's worth, you can currently iterate through an Org type, and there are the wrapper types OrgIterator and OrgElementIterator.

[hewhocannotbetamed]

I am also interested in seeing something like this come about. I have a few ideas in terms of use case, with the most concrete being the use of org-syntax to build & maintain knowledge graphs rendered with GraphMakie + GLMakie. These packages offer the ability to make incredibly attractive interactive graphs with unique interactivity patterns. To make the idea more concrete, I currently have a properties and memo system that is amenable to the generation of a "Task graph". Think org-roam-ui, but generalized, far more performant, and far more flexible.

[tecosaur]

With the advent of weak deps / package extensions with Julia 1.9, I'm much more willing to consider some optional dependencies like AbstractTrees.