lucasvreis / org-mode-hs Goto Github PK

It's not clear to me what the behavior should be, given that Org mode itself seems confusing when exporting cross references to HTML.

For instance, Org will substitute links to internal references with a counter for most elements, but with \eqref for equations. We shouldn't do that since it's dependent on export. The Id of InternalTarget should be used for \eqref or something else on export. Still proper numbering for equations is too complicated. For other elements you can reference anything with #+name but this counter is only updated in the presence of #+caption. I will have to figure out how numbering for <<targets>> works.

Use https://github.com/EmaApps/ema + the ema-org https://github.com/lucasvreis/organon library for a simple "live preview" command.

https://github.com/lucasvreis/org-parser/blob/master/SPEC.org#export-snippets

The described problem should be resolved in https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=96529e933b445dce52e4e904695f1d538c3e0e7f

The provided example is not an @html export snippet because snippet is an object and cannot span over multiple paragraph elements.

With #6, this is becoming more than just a parser. org-mode and orgmode and already taken in Hackage. Some ideas:

• org-hs
• Just org?
• Leave it as it is :(

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.

Annotate the character position of elements and objects in the AST (like Org does). I'm constantly reminded of this since I think this would be extremely useful. Some applications:

• Paragraph-accurate "synctex" in organon (perhaps even split AST into words like pandoc does)
• Support for org-remark (marginalia) annotations via the templates
• Support for Org line-number links (not a priority, I don't like this sort of link)

It should be fairly simple to parse Org export blocks as templates to be interpreted by Ondim.

To separate them from ordinary blocks they could use custom languages like ondim-html and ondim-pandoc, this way they won't interfere with emacs' org exporters either.

Edit: perhaps it's better to use source blocks with :exports none attribute, with the advantage that org-mode would do syntax highlighting by default and we could use custom attributes.

Hi! I'm trying to build the library by following the instructions in the README.

Version information:

➤ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.7

➤ cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.2.0 of the Cabal library

Installed via ghcup on Arch Linux. These are the errors I get:

Errors

When first compiling, an error appears in org-exporter/src/Org/Exporters/Pandoc.hs. To try to resolve this I just commented out the line.

src/Org/Exporters/Pandoc.hs:30:16: error:
    Not in scope: data constructor ‘P.Null’
    Perhaps you meant ‘P.Cell’ (imported from Text.Pandoc.Definition)
    Module ‘Text.Pandoc.Definition’ does not export ‘Null’.
   |
30 |       nullEl = P.Null
   |                ^^^^^^
Error: cabal: Failed to build org-exporters-0.1 (which is required by exe:horg

then after commenting out the offending line, the issue seems to be taken care of, but another error appears in org-cli:

app/org-cli.hs:81:40: error:
    • Couldn't match expected type ‘Text.Pandoc.Format.FlavoredFormat’
                  with actual type ‘Text’
    • In the first argument of ‘TP.getWriter’, namely ‘fmt’
      In a stmt of a 'do' block: (w, ext) <- TP.getWriter fmt
      In the first argument of ‘TP.runIOorExplode’, namely
        ‘do (w, ext) <- TP.getWriter fmt
            tpl <- TP.compileDefaultTemplate fmt
            utpl <- case tplo of
                      Nothing -> pure Nothing
                      Just tfp -> do ...
            let tpl' = fromMaybe tpl utpl
                wopt = ...
            ....’
   |
81 |               (w, ext) <- TP.getWriter fmt
   |                                        ^^^

The problem seems to be related to pandoc in both cases. If there's any other information you need then please let me know!

Move them to a new module, Transforms, and keep them modular. What can be done outside the parser should be detached.

The list includes:

• #11
• orgStateMacros
• orgStateInternalTargets
• orgStateKnownAnchors
• processSpecialStrings
• documentFootnotes, orgStateFootnotes: remove the field from OrgDocument
• orgStateKeywords, documentKeywords: remove the field too
• orgStateExcludeTags, orgStateExcludeTagsChanged
• orgStateSrcLineNumber

Basically do this:
https://orgmode.org/manual/Property-Syntax.html