You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pandoc is considering adapting its types to be polymorphic over Inline and Block (jgm/pandoc-types#99, jgm/pandoc-types#98). This is very interesting as it may allow other libraries to extend the Pandoc AST. It would be nice if org-parser could drop part of its AST and use an extended version of Pandoc. That would contribute to a more unified package ecosystem and facilitate conversion between the libraries.
Unfortunately, I think most types & constructors in Org.Types would have to remain anyway, or be turned into patterns, else we lose the "org-element alikeness and expressivity".
One interesting example is uniorg in the context of unified. I will have a look at how uniorg reuses the types of unified, but JS is much more flexible in this aspect.
The text was updated successfully, but these errors were encountered:
Pandoc is considering adapting its types to be polymorphic over Inline and Block (jgm/pandoc-types#99, jgm/pandoc-types#98). This is very interesting as it may allow other libraries to extend the Pandoc AST. It would be nice if org-parser could drop part of its AST and use an extended version of
Pandoc
. That would contribute to a more unified package ecosystem and facilitate conversion between the libraries.Unfortunately, I think most types & constructors in
Org.Types
would have to remain anyway, or be turned into patterns, else we lose the "org-element alikeness and expressivity".One interesting example is uniorg in the context of unified. I will have a look at how uniorg reuses the types of unified, but JS is much more flexible in this aspect.
The text was updated successfully, but these errors were encountered: